Поиск узких мест в производительности на классическом веб-сайте ASP / SQL Server

Question

У меня есть старое классическое серверное приложение asp / sql, которое постоянно выбрасывает 500 ошибок / тайм-аутов, хотя нагрузка невелика. Некоторые из запросов к БД довольно интенсивны, но они не должны вызывать сбоев.

Есть ли какие-нибудь хорошие программы, которые я могу установить на своем сервере, которые точно покажут, где находятся узкие места в asp или в БД?

Answer 1

Где происходит тайм-аут? Это в строках, когда ASP подключается / выполняет sql? Если это так, то ваша проблема либо с подключением к серверу БД, либо с самим БД. Загрузите профилировщик SQL в MSSQL, чтобы узнать, сколько времени занимают запросы. Возможно, это связано с блокировками в базе данных.

Используете ли вы транзакции? Если это так, убедитесь, что они не блокируют вашу базу данных в течение длительного времени. Убедитесь, что вы используете транзакции в ADO, а не на всей странице ASP. Вы также можете игнорировать блокировку в SQL Select, используя подсказку WITH (NOLOCK) для таблиц.

Убедитесь, что ваша база данных оптимизирована с помощью индексов.

Также убедитесь, что вы подключены к БД как можно быстрее, т. Е. (Например, не работает код): conn.open; set rs = conn.execute (); rs.Close; conn.Close. Поэтому сохраняйте наборы записей в переменной, а не проходите по циклу, удерживая соединение с БД открытым. Хорошим способом является использование функции GetRows () в ADO.

Всегда явно закрывайте и устанавливайте объекты ADO на ничего. Это может привести к тому, что соединение с БД останется открытым.

Включить пул соединений.

Загрузка констант ADO в global.asa, если вы их используете

Не хранить какие-либо объекты в областях сеанса или приложения.

Обновление до последних версий пакетов обновления ADO, MDac, SQL Server и т. Д.

Вы уверены, что сервер может справиться с нагрузкой? Может быть, обновить его? Это на виртуальном хостинге? Может быть, ваше приложение не проблема.

Очень просто измерить производительность скрипта, синхронизировав его от 1 строки до последней строки. Таким образом, вы можете идентифицировать медленно работающие страницы.

Answer 2

Некоторые инструменты, которые вы можете попробовать:

• HP (ранее Mercury) LoadRunner или Performance Center
• Visual Studio Тест Центра приложений (только для Enterprise Edition?)
• Microsoft Инструмент веб-приложения Stress (он же WAS, он же "Гомер"; предшественник Application Center Test)
• WebLoad
• MS Visual Studio Analyzer , если вы хотите отследить код приложения. Это может показать вам, как долго приложение ожидает вызовов БД, и какой SQL был использован. Затем вы можете использовать профилировщик SQL для настройки запросов.

Answer 3

Если вы удовлетворены тем, что запросы к БД слишком интенсивны, возможно, вам нужно установить более подходящие таймауты на тех страницах, которые используют эти запросы.

Установите для параметра Server.ScriptTimeout что-то большее, вам также может потребоваться установить время ожидания для объектов команд ADO, используемых сценарием.

Answer 4

Вы пытались запустить SQL Server Profiler на сервере? Он выделит любую неожиданную активность, попавшую в базу данных из приложения, а также поможет выявить плохо выполняющиеся запросы.

Answer 5

Вот как я подхожу к этому.

1. Посмотрите на запущенные задачи на сервере. Что занимает больше процессорного времени - сервер SQL или IIS? В большинстве случаев это будет SQL-сервер, и, конечно же, он звучит так, исходя из вашего поста. Очень редко любое ASP-приложение на самом деле выполняет большую часть обработки на стороне ASP, в отличие от сторон COM или SQL.

2. Используйте SQL Profiler для проверки всех запросов к серверу базы данных.

3. Сначала разберитесь с низко висящими фруктами. Обычно у вас будет несколько «проблемных» запросов, которые часто попадают в базу данных и занимают много времени. Смирись с этим. (Правдой в разработке программного обеспечения является то, что 10% кода занимает 90% времени выполнения ...)

В дополнение к рассмотрению затрат на запросы с помощью SQL Profiler и Query Analyzer / SQL Studio и выполнению обычной работы по детектированию производительности SQL вы также можете проверить, возвращают ли ваши вызовы базы данных непомерное количество данных в ваш код ASP. Я видел случаи, когда безобидно выглядящие запросы возвращали ОГРОМНОЕ количество ненужных данных в ASP - классический («select * from tablename») запрос, написанный ленивыми / неопытными программистами, который возвращает 10000 огромных строк, когда программисту действительно нужны были только 1 поле из 1 ряда. Причина, по которой я упоминаю этот особый случай, заключается в том, что такие запросы часто имеют низкое время выполнения и низкую стоимость запросов на стороне SQL, и поэтому могут ускользнуть от внимания.