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

Question

Я слежу за производительностью моего сайта и из всего медленно выполняющегося кода (> 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 в веб-приложениях Возможно, это происходит.

Answer 1

Вот то, что я обнаружил как проблему, или я должен сказать причину, из-за того, что мое приложение показало низкую производительность метода: System.Web.HttpRequest.FillInFormCollection()

Кажется, System.Web.HttpRequest.FillInFormCollection() запускается, как только оно получаетначало данных, отправляемых в форму, и завершается после получения последнего бита данных.Если у моего пользователя плохое соединение, может потребоваться много времени для полной отправки этой информации.Отсюда и долгие времена для этого метода.

Я использовал ограничитель пропускной способности на своем локальном компьютере и смог воспроизвести согласованные результаты, которые соответствовали изменяющимся скоростям, на которых я тестировал, чем медленнее скорость соединения, тем дольшеSystem.Web.HttpRequest.FillInFormCollection() запущен для запуска.

Если вы не получаете жалоб на то, что ваш веб-сайт не работает, вы, вероятно, просто просматриваете код, запускаемый пользователями с дрянными подключениями.