Время отклика уменьшается с течением дня, с чего начать устранение неполадок?

Мои ИТ-специалисты просто пожимают плечами, когда я поднимаю эту тему, поэтому я обращаюсь к SE за помощью.

Думаю, это изображение лучше всего видно.

Проще говоря, с течением дня время отклика становится все хуже и хуже, примерно до полуночи что-то происходит, и оно резко падает до почти нормального. Мы находимся в IIS, эта страница все еще находится в классическом ASP, но это происходит на всех страницах, даже на простых HTML-страницах, что, как мне кажется, исключает проблему подключения SQL.

Думаю, у меня вопрос, с чего мне начать искать? Я просмотрел обычные журналы и не увидел ничего, что бы на меня выскочило. Но что-то явно происходит, и я не знаю, с чего начать.

Это может быть вызвано рядом причин - к сожалению, нам, вероятно, потребуется немного больше информации.

Прежде чем я перейду к собственному ответу, кратко остановлюсь на ваших HTML-страницах: вообще говоря, пул приложений может отвечать только на определенное количество запросов за раз. Если он занят ответом на запросы динамических страниц, то у него может не осталось потоков для обслуживания статических страниц. По этой причине проблема кода на динамической странице может создать иллюзию, что статические страницы обслуживаются «медленно». Я хочу сказать, что не исключайте код или SQL.

Например: если у вас 100 страниц одновременно обращаются к базе данных или API, и все 100 ждут ответа, запрос 101 может быть заблокирован до тех пор, пока не завершится 1 из первых 100.

Сейчас, вы можете сделать множество вещей, чтобы помочь вам диагностировать эту проблему:

Какой у вас обычно профиль нагрузки? Это имеет большое значение - возможно, вы всегда есть проблема, но вы не сможете увидеть ее влияние, пока ваш сайт не получит нагрузку. Вы можете попробовать и протестировать это (на стадии постановки) с помощью чего-то вроде JMeter.
Включите журналы IIS (если вы еще этого не сделали), а затем просматривая их, чтобы узнать, какие запросы занимают больше всего времени. Вы можете использовать что-то вроде Анализатор журнала (от Microsoft) для выполнения SQL-подобных запросов к вашим журналам (или даже сброса ваших журналов в базу данных SQL), если это облегчит жизнь. Как только вы узнаете, какие страницы занимают больше всего времени, вы можете сосредоточить на них часть своего внимания.
Есть ли в вашем приложении логи? Если нет, вам следует подумать о добавлении журнала. Если у вас уже есть логи, что они говорят? Есть ли исключения в вашем приложении? Есть ли что-то, что постоянно дает сбой?
Какой объем памяти используется вашим пулом приложений? Утечка памяти - очевидный кандидат, но вы должны быть довольно легко заметны. Используйте встроенную в Windows Монитор производительности для отслеживания памяти, потребляемой пулом приложений в течение дня, и посмотреть, увеличивается ли она с течением дня.
Как я уже упоминал в открытии, SQL все еще может быть проблемой. Я бы рекомендовал взглянуть на сервер базы данных, чтобы увидеть, есть ли какие-либо длительные или заблокированные запросы (например, в sys.dm_exec_requestsпосмотрите на wait_type, wait_time, blocking_session_id и total_elapsed_time).
Проверьте, сколько подключений открыто в вашем пуле приложений, используя что-то вроде TCPView (еще один инструмент Microsoft). Ваш пул приложений будет пытаться повторно использовать соединения, где это возможно, но вы, вероятно, увидите много открытых соединений с вашим пулом приложений. Из этого вы можете увидеть одну интересную вещь: теперь у вас есть много открытых соединений с вашей базой данных SQL или любыми внешними API-интерфейсами, которые использует ваше приложение.
Используйте инструмент производительности и мониторинга приложений. AppDynamics или аналогичный инструмент сможет помочь точно определить медленно работающие части вашего кода. К сожалению, для того, чтобы эффективно использовать эти инструменты, нужно немного научиться, но они могут быть очень мощными при диагностике проблем с вашими приложениями.

Обновить

Перезапуск пула приложений может помочь решить проблему, если у вас есть утечка памяти, но с этим нужно быть осторожным: могут возникнуть некоторые неблагоприятные последствия. После перезапуска пула приложений ваше приложение начнет загружать статические объекты в память и т. Д. В зависимости от сложности вашего приложения это может занять много времени (может быть 5-10 минут или больше). В это время запросы к вашему серверу могут задерживаться, что делает его появиться что проблема обострилась.

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

Другими словами: Если это определенно не проблема с утечкой памяти, возможно, не стоит перезапускать пул приложений, потому что проблема может возникнуть снова сразу.

Примечание: Перезапуск пула приложений приведет к не повлиять на любые текущие запросы. Они будут продолжаться до завершения, если вы не отключите пул приложений принудительно (например, Crtl + Alt + Del)

Может случиться так, что код хреновый и утечка памяти, и есть ночной перезапуск пула приложений, который сбрасывает состояние приложения. Вы как-нибудь пробовали его отлаживать? Тестовый сервер, отладчик, профилировщик - и все это при какой-то нагрузке, напоминающей производственную?

Я имею в виду, что также стоит проверить фактическую производительность сервера, чтобы убедиться, что с сервером не происходит медленного ввода-вывода или чего-то еще. Так что поработайте со своим ИТ-отделом, чтобы исключить это, конечно. Такие слова, как Perfmon, Solarwinds или SCOM, могут быть подходящими в зависимости от вашей среды. Однако вы должны быть готовы работать и на своей стороне.

Я был на месте айтишника, которого обвиняют в «медленных веб-приложениях», когда буквально нет проблем на сервере, но есть проблемы в коде.