MiniProfiler и Azure пропали без вести для TTFB
Я использую StackExchange.MiniProfiler с помощью дополнений MVC и EntityFramework, чтобы попытаться отследить длинный TTFB, который надежно встречается для одного типа запроса на нашем веб-сайте. Как вы можете видеть на изображении внизу, длительность, указанная для этого запроса, составляет 504,3 мс. Я считаю, что это соответствует времени между звонком MiniProfiler.Start в BeginRequest и призыв к MiniProfiler.End в EndRequest (минус время детских шагов). Используя инструменты браузера, я вижу, что TTFB для этого запроса соответствует данным из MiniProfiler, поэтому я считаю, что MiniProfiler является точным. Я добавлял шаги профилировщика во все больше и больше кода и думаю, что все теперь обернуто, но они не складываются в что-то около 504 мс.
Этот запрос является ajax-запросом, который выполняется на странице, когда одновременно выполняется несколько других запросов. Если я возьму URL и нажму его из того же браузера изолированно, длительность и TTFB будут всего ~100 мс. Казалось бы, это означает, что что-то из одного из других запросов блокирует этот, но я не думаю, что у нас есть что-то, что должно вообще блокировать, и, конечно, не так долго, ни один из других запросов не займет столько времени.
Сайт работает как служба приложений среднего уровня Azure. Может ли это быть каким-то ограничением? Как я могу подтвердить или опровергнуть это? Какие-нибудь хитрости MiniProfiler, которые могли бы раскрыть здесь больше данных?
1 ответ
Эта проблема была связана с этим вопросом SO здесь: я только что обнаружил, почему все сайты ASP.Net работают медленно, и я пытаюсь решить, что с этим делать
Состояния сеанса блокируются, поэтому, если у вас есть несколько одновременных запросов от одного браузера / сеанса, они могут в конечном итоге ожидать друг друга. Указание некоторых из наших соответствующих контроллеров как предназначенных только для чтения с атрибутом устраняет все плохое: [SessionState(SessionStateBehavior.ReadOnly)]