System.Web.HttpRequest.FillInFormCollection () и System.Web.HttpRequest.GetEntireRawContent () очень медленно

Я отслеживал производительность своего веб-сайта и из всего медленно выполняющегося кода (> 1 с) более 90% связано с System.Web.HttpRequest.GetEntireRawContent () (вызывается System.Web.HttpRequest.FillInFormCollection ())

Это нормально для ASP. NET ...иногда проводить более 10 секунд в методе FillInFormCollection (очевидно, он вызывается из System.Web.UI.Page.PerformPreInit ())?

Или есть способ решить эту проблему?

Я компилирую. NET Framework 3.5.

Страница У меня в основном проблемы со страницей входа в систему, хотя в ней нет ничего необычного - два текстовых поля, флажок для RememberLogin и кнопка входа в систему. Request.ContentLength составляет около 5 КБ (я зарегистрировал Request.Form.ToString () - ничего необычного не обнаружил). Я выполнил много трассировки (ожидал огромных POST) и отладки, но не смог найти какой-либо рациональной причины для того, чтобы FillInFormCollection занимала более 10 секунд (однажды у меня был экстремальный пример с 250 секундами). Я даже пытался замедлить свое соединение со Fiddler, но не смог воспроизвести проблему.

РЕДАКТИРОВАТЬ: Спасибо за все комментарии, ребята. Я продолжал заниматься этой проблемой ... если она будет решена, по крайней мере, это сэкономит другим людям время;). Вот ответы на некоторые вопросы.

1. Это обычный HTTP (не HTTPS), 0 ошибок в журнале (забавно, что запросы фактически завершаются;)
2. Сайт не загружается, когда пользователь нажимает на Login.aspx. Сайт действительно работает довольно хорошо 99% времени (обрабатывает около 40 миллионов HTTP-запросов в неделю при использовании ЦП AVG ниже 10%)
3. Это определенно application / x-www-form-urlencoded - формы ASP.NET (runat = server) отправляются таким образом. Единственное, чего я не понимаю, это почему .NET требуется> 10 секунд для чтения POST размером менее 6 КБ.
4. Единственный рациональный вывод, к которому я пришел (пока), -> клиенты обращаются к сайту через очень медленное соединение ( помните GPRS ?). Но мне бы очень хотелось изучить все другие варианты, а не просто прибегать к «пользовательскому подключению». И если бы это было так - я ожидаю, что подобное будет происходить с пользователем на каждой странице.
5. Надеюсь, что это не что-то вроде этого: Сервер IIS 6.0 слишком занят HTTP 503 Connection_Dropped DefaultAppPool
6. На эту страницу ссылались: Выявление уязвимостей медленных HTTP-атак в веб-приложениях Возможно, что это происходит.