В одном из моих приложений периодически возникали задержки в определенной части системы. Пользователи нажимали кнопку «Сохранить», и иногда на ответ требовалось 30 секунд. Я включил Трассировка ASP.NET а затем использовал Логман и ETW для записи подробных трассировок.
Трассировка показала, что задержка произошла на этапе «HTTPSYS_CACHEABLE». Но я не мог понять, почему это вызывает задержку. Я не нашел никакой полезной документации об этапах трассировки в IIS6, и Google не нашел никого, кто бы решил эту проблему.
Я попытался отключить кеширование HTTP.SYS, изменив ключ реестра и отредактировав machine.config. Ни одно из действий не привело к изменению производительности страницы или журналов трассировки.
Соответствующая часть результатов трассировки - это этот раздел. Обратите внимание на разрыв между отметками времени.
IISCache: URL_CACHE_ACCESS_END - IIS ends accessing URL cache
ErrorCode: 0x00000000
PhysicalPath: H:\JobTraQ_Site\
URLInfoFromCache: 1
URLInfoAddedToCache: 0
ContextIDSeq: 4
Timestamp: 00:30:29.406.250000
IISCache: HTTPSYS_CACHEABLE - IIS decides if the request is HTTP.SYS cacheable
Reason: RESPONSE_MORE_DATA
HttpsysCacheable: 0
ContextIDSeq: 4
Timestamp: 00:30:53.421.875000
Я обнаружил, что запись трассировки URL_CACHE_ACCESS_END происходит до завершения процесса страницы ASP.NET, а HTTPSYS_CACHEABLE - после его завершения. Я обнаружил это, добавив 5-секундный сон в свой код, а затем сравнив трассировки со сном и без него. Задержка сна отображается во временной метке HTTPSYS_CACHEABLE.
Итак, это не проблема IIS или ASP.NET. В моем случае один из наших разработчиков изменил код, из-за которого в определенных случаях запускался длинный цикл, который просто запускали наши пользователи.