Блог

У меня возникли некоторые проблемы с производительностью моего веб-сервера iis. Он зависает случайным образом, и я пытаюсь выяснить, как ускорить работу сервера. Я включил отслеживание неудачных запросов на сервере и настроил его на создание журнала, когда запрос выполняется более 3 секунд.

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

65. i GENERAL_GET_URL_METADATA PhysicalPath="", AccessPerms="513" 17:46:32.577

66. i HANDLER_CHANGED OldHandlerName="", NewHandlerName="ExtensionlessUrlHandler-Integrated-4.0", NewHandlerModules="ManagedPipelineHandler", NewHandlerScriptProcessor="", NewHandlerType="System.Web.Handlers.TransferRequestHandler" 17:46:32.577

67. i VIRTUAL_MODULE_UNRESOLVED Name="FormsAuthentication", Type="System.Web.Security.FormsAuthenticationModule" 17:46:47.771

Я не уверен, какой обработчик изменен, но это занимает много времени, любые советы о том, с чего начать поиск, были бы полезны.

Трудно найти решение, не имея в виду ни одного фрагмента кода. Вот несколько общих советов, которым вы можете следовать, чтобы добиться отличной производительности при ASP.NET применение.

• Самый быстрый способ выполнить запрос — не выполнять его в первую очередь. Попробуйте кэшировать все, что можно кэшировать. Существуют кэши на стороне сервера и кэши на стороне клиента. Каждый из них имеет свое собственное применение, но вы не ограничены только одним типом.
• Убедитесь, что вы не кэшируете и / или не сохраняете ссылки на какие-либо связанные с запросом объекты в памяти. ASP.NET имейте ограниченное количество одновременных запросов, и сохранение ссылки на запрос в памяти приведет к зависанию вашего сервера, если на нем закончатся потоки
• Закройте запрос, как только вы закончите с ним
• Все, что не нужно клиенту во время запроса, должно выполняться в фоновом режиме
• Убедитесь, что в вашем приложении нет утечки памяти. Сборки мусора часто являются причиной зависаний в ASP.NET применение. При сборе мусора все запущенные потоки приостанавливаются. Это особенно верно для Gen 2 сбора мусора. Вы можете включить фоновую сборку мусора поколения 2.
• Изолируйте проблемный код. Используйте профилировщик и посмотрите, какой тип запроса требует больших ресурсов процессора. Затем копните глубже и посмотрите, что внутри этого запроса замедляет его выполнение.
• В любом хорошо сбалансированном приложении объекты должны быть либо недолговечными, либо жить вечно. В случае ASP.NET приложение, объекты, созданные в ходе запроса, в идеале должны умереть в этом запросе или во время следующего GC gen 0.
• Рассмотрите возможность объединения объектов для больших объектов и объектов, которые долго инициализируются
• Убедитесь, что ваш пул приложений не завершает работу и не перезапускается (посмотрите журналы IIS и / или события Windows)

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

• LeanSentry. Отлично подходит для диагностики ASP.NET сервер зависает
• windbg. Высокая кривая обучения, но, безусловно, самый мощный инструмент отладки, который вы можете использовать
• PerfView. Полезно для анализа событий ETW, таких как ввод-вывод или загрузка процессора

Существует много способов повысить производительность сервера. Но перед этим вам следует начать с проверки загрузки процессора во время «зависания». Такое поведение может быть вызвано бесконечным циклом в коде приложения. Если в цикле нет операций ввода-вывода, блокировки или спящего режима, вы сможете увидеть это по загрузке ЦП, поскольку вы получите ровно одно полное ядро загрузки ЦП для каждого бесконечного цикла.

Ссылка на справку для повышения производительности сервера

Дополнительная информация: я вижу запись, связанную с НЕРАЗРЕШЕННЫМ ВИРТУАЛЬНЫМ МОДУЛЕМ: что связано с неправильным использованием ответа.Перенаправление (url); Также убедитесь, что вы развернули свое приложение в интегрированном режиме в IIS.

вот простой контрольный список, который вы, возможно, захотите пересмотреть: всегда предварительно компилируйте свой сайт, а не копируйте его! вы можете значительно повысить производительность, скомпилировав свой веб-сайт перед развертыванием: ASP.NET Обзор предварительной компиляции

Не запускайте рабочее приложение с включенным debug=»true», когда в вашем web.config установлен флаг отладки true, во время выполнения в приложении используется гораздо больше памяти, а поскольку включены некоторые дополнительные пути отладки, коды могут выполняться намного медленнее. Проверьте файл Web.config, чтобы убедиться, что трассировкаотключено в разделе IIS 7.5 поставляется с функцией автозапуска. WAS (служба активации процессов Windows) запускает все пулы приложений, настроенные на автоматический запуск. Убедитесь, что ваш пул приложений настроен на AlwaysRunning в IIS 7.5 applicationHost.config, смотрите здесь для получения более подробной информации.

Каждый asp.net сервер может быть хорошо настроен с помощью файла aspnet.config, расположенного в корне папки framework. Убедитесь, что в вашем файле aspnet.config для подтверждения безопасности доступа к коду (CAS) установлено значение false, это может увеличить начальную загрузку страницы при перезапуске ASP.NET пул приложений. подробнее об этом можно прочитать здесь .

Также вы можете попробовать модуль инициализации приложения для IIS 7.5, этот модуль, также доступный в IIS 8.0, может уменьшить время ответа на первые запросы путем предварительной загрузки рабочих процессов