Назад | Перейти на главную страницу

Оптимизация производительности веб-приложений SQL / IIS (классический ASP)

У нас есть классическое веб-приложение ASP, которое мы размещаем у стороннего хостинг-провайдера (Rackspace). У нас есть ~ 100 баз данных на SQL-сервере и примерно столько же веб-сайтов на веб-сервере (IIS). Есть ли у кого-нибудь советы по оптимизации производительности. Иногда в течение дня мы наблюдаем всплески памяти и процессора. Мы настроены с помощью простой пары SQL-сервера и веб-сервера.

Что касается SQL, было бы неплохо использовать SQL Profiler для идентификации любых ваших запросов или хранимых процедур, выполнение которых занимает много времени. Если вы сможете определить здесь какие-либо реальные проблемы, это поможет ускорить ваше приложение.

Имейте в виду, что инструмент Profiler часто требует большой фильтрации для получения правильной информации. Приятно то, что вы можете записывать время начала выполняемых запросов и пытаться сопоставить их с временем всплеска вашего процессора.

Это непростой вопрос, и на него нет простого ответа. Об оптимизации производительности написаны целые книги.

Может быть, попробуйте начать с этих статей, в которых (в первой части) рассматриваются проблемы с производительностью. http://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-1/

http://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-2/

Могу также предложить книгу. Грант Фритчи и Саджал Дам: «Оптимизация производительности SQL 2008».

Если вы можете найти наихудшие из запросов, опубликуйте их здесь или на хорошем форуме SQL, и кто-нибудь обязательно вам поможет. На самом деле вопрос слишком широк, чтобы на него можно было дать простой ответ.

Я подозреваю, что вам понадобится профилирование. На общем уровне вам необходимо знать, где находятся узкие места, поэтому применяются типичные рекомендации по мониторингу производительности Windows. Диаграмма общей производительности ЦП (% использования,% пользовательского режима по сравнению с режимом ядра, переключение контекста), диска (длина очереди,% дискового времени) и памяти (количество ошибок страниц в секунду, размеры рабочего набора). Вы захотите начать сужать его до того, какие процессы (IIS WAM, SQL Server и т. Д.) Вызывают у вас горе.

Как было сказано на других плакатах - если вы выполняете SQL-запросы, то, вероятно, это проблема оптимизации базы данных. Однако не упускайте из виду возможность того, что ваши скрипты выполняют глупые запросы (SELECT * и фильтруют результаты в скрипте и т. Д.), Которые вызывают аномальную загрузку базы данных.

Если вы перейдете к отдельным скриптам (т.е. вы обнаружите, что узкое место указывает на процессы IIS / WAM), взгляните на этот вопрос Stackoverflow: https://stackoverflow.com/questions/398028/performance-testing-for-classic-asp-pages Там есть фрагмент кода, который представляет собой базовый таймер выполнения. Рискуя еще больше повлиять на производительность, но в целях большей наглядности, вы также можете рассмотреть возможность записи в базу данных передаваемых параметров и времени выполнения ваших скриптов. Поиск выбросов в этих данных может помочь вам найти граничные условия в ваших скриптах. В идеале вы хотите проектировать с учетом профилирования с самого начала, а модернизация может оказаться сложной задачей.