stenfordskyANAТы без моего совета даже не допёр, что надо убрать этот самый autoConfig="true", так что давай не будешь тут писать кому и куда идти.
Документацию для начала сам научись читать
так значит в гугл не пойдешь читать почему autoConfig="true" выдаёт "настолько низкие" значения? Или хотя-бы мой пост где подробно расписано почему? Вот и сиди в своем перманентном "хз" состоянии и дальше
Не пойду, я ещё 5 лет назад прочитал, что при autoConfig="true" значения зависят от параметров железки.
И поэтому надо бы на эту самую железку взглянуть, о чём и написал.

С чем не согласен?

Агнец за бортомstenford,

Ты в итоге разобрался (не косвенно) - кто жрёт эти 2.5 секунды?
Да в использовании сессии у тебя проблема.
Замени IRequiresSessionState на IReadOnlySessionState, если хэндлер только читает из неё, и будет тебе счастье.

stenfordIIS-же их держит в случае "взрывного" увеличения запросов, лечится только прямым указанием в конфиге что нужно выделять столько-то потоков.
Асинхронностью ещё лечится.

Агнец за бортомДа знаю я, в чём у меня была проблема, и не в сессии дело, Дима.
И в чём, если не секрет?

Агнец за бортомВопрос - как отрейсить запрос целиком (с IIS до ответа) - так и открыт.
Всё в одном инструменте? Тогда NewRelic.

New Relic provides the ability to track the time after a request enters your production systems and before it reaches your application.
This portion of your request's life cycle is referred to as request queuing.
Depending on the specifics of your production systems, this time may include an actual queue that requests enter, or it may represent other functions (such as load balancing or internal network latency).

Petro123Хватит уже год пугать хранением сессии на бэке.
Прямо миф какой то создали. Или религию.
Да какой миф, есть официальная документация, где рассказано как устроена работа с сессией в ASP.NET.
Про блокировки и прочее.
И туева хуча обсуждений на разных форумах тормозов при использовании Session.
Просто надо знать об этом и знать как обходить. Либо вообще сессию не использовать.

И вот собственно ссылка на документацию: ASP.NET Session State Overview

Concurrent Requests and Session StateAccess to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently.

However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information.
The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.)

If the EnableSessionState value in the @Page directive is set to ReadOnly , a request for the read-only session information does not result in an exclusive lock on the session data.

However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.

Агнец за бортомДмитрий Муха просто спросил: "И в чём, если не секрет?".

Тыц

Stalled . The request could be stalled for any of the reasons described in Queueing .

Queueing . The browser queues requests when:
There are higher priority requests.
There are already six TCP connections open for this origin , which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
The browser is briefly allocating space in the disk cache

Это не объясняет твою ситуацию.

У тебя 7 + 1 HTTP запрос, 2 выполняются, а 5 ждут. Ты под IE 7.0 и ниже что-ли пишешь?

skyANA2 выполняются, а 5 6 ждут
поправил

skyANAТы под IE 7.0 и ниже что-ли пишешь?
Нет, раз Timeline в Хроме смотришь...

Агнец за бортом,

покажи Timing для любого из "pending" запросов к хэндлеру.