NewRelic, async http-обработчик и AcquireRequestState

У меня проблема с одним обработчиком async в распределенном веб-приложении ASP.NET. Сначала позвольте мне пояснить пример использования:

приложение использует IIS 8 на машине с 2012 годом с .NET Framework 4.5.2.

приложение отключило модули сеанса и аутентификации через web.config, как это

     <system.webServer>
       ....
       <modules>
            <remove name="WindowsAuthentication" />
            <remove name="Session" />
            <remove name="FormsAuthentication" />
        </modules>
     </system.webServer>

приложение использует пользовательский обработчик async для обслуживания конкретного запроса
приложение имеет очень большой трафик (около 50 тыс. запросов в минуту на сервер, обработчик async имеет около 10 тыс. запросов в минуту на каждый сервер, отслеживаемый с помощью NewRelic) Приложение
распространяется через несколько процессов w3wp (2 процесса w3wp) и несколько виртуальных серверов (около 10 серверов).
приложение имеет большое количество соединений

Все нормальные (запросы синхронизации) работают нормально, но запрос async, который выполняет немного больше работы (что мы используем async-запрос), часто медленный, но NewRelic сообщает, что он медленный из-за "AcquireRequestState". Теперь я просмотрел переполнение google и stack, и это событие связано с созданием сеанса, но у нас отключены сеансы в web.config. Кто-нибудь знает, что еще может сделать "AcquireRequestState"? Нам не хватает места для удаления состояния сеанса? Добавив, что из web.config в machine.config ничего не сделал...

Вот фрагмент запроса в NewRelic:

   **Slowest components   Count Duration     %   **
     AcquireRequestState    1   12,600 ms   100%  --> WTF?
     ExecuteRequestHandler  1   5.01 ms     0%
     Integrated Pipeline    1   0.334 ms    0%
     UpdateRequestCache     1   0.3 ms      0%
     EndRequest             1   0.168 ms    0%
     AuthenticateRequest    1   0.161 ms    0%
     Total time                 12,600 ms   100%

EDIT: У меня <sessionState mode="Off" /> в разделе web.config(<system.web>), так что это не так.

Ответ 2

Я изучил это, потому что у нас были подобные проблемы, я нашел этот сообщение в форуме, интересный ответ:

К сожалению, проблема не так проста, как просто отключить sessionState. Фактически, одна из ключевых фраз при описании проблем с AcquireRequestState - это фраза, например, состояние сеанса, когда дело доходит до возникновения этого события. Если глубже вникать в это (фактически глядя на источник .NET), мы можем видеть, что это вызывается, когда выполняется EventHandler или создается объект RequestNotification. Я полагаю, что существуют другие методы и/или события, которые при вызове будут вызывать событие AcquireRequestState. Отслеживание всех из них представляет собой нечто вроде борьбы. Похоже, это не что-то, что не говорилось о многом за пределами более нормализованных обсуждений состояния сеанса. Наиболее распространенное место, которое мы видим в этом событии, безусловно, связано с управлением сеансом. Но есть очень очевидные выбросы, когда это событие все еще может быть поднято. Его можно даже вызывать непосредственно из кода приложения. То, что агент схватывает, заключается в том, что он может идентифицировать событие, но редко источник. Когда он возникает как часть конвейера ASP, единственным уведомлением, которое получает агент, является то, что это один сегмент транзакции. Источником или методами, выполняемыми внутри события, является то, что агент редко применяет по умолчанию. Хотелось бы, чтобы мы могли больше рассказать вам об этом. В .NET-приложении много движущихся частей, некоторые из которых связаны с самой операционной системой, IIS, версией .NET, независимо от того, являются ли эти методы асинхронными, настройки пула приложений, режимы выполнения, разрешения и т.д. Хотя я не хочу открывать вторую банку червей здесь, это усугубляется проблемой с отсутствием трассировки стека за 500 ошибок. Агент предоставляет трассировку стека, когда он предлагается и/или доступен. Там, где трассировка стека, если она существует, встречается в конвейере ASP, чрезвычайно важна. Иногда это происходит до того, как будет выполнен фактический код приложения. В таких случаях сообщение об ошибке сообщается приложению, которое, в свою очередь, позволяет агенту .NET видеть и сообщать, что произошла ошибка, но никакие другие данные не предоставляются. Агент просто видит, что это произошло, и сообщает как можно больше информации. Кроме того, агент просто не имеет никаких подробностей, которые он может предложить.

Мы сдались, поэтому мне было бы интересно узнать, поняли ли вы это!

Ответ 1

Ответ 2