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

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

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

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

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

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

EDIT: Спасибо за все комментарии ребята. Я продолжал заниматься этим вопросом... если он будет решен, по крайней мере, это спасет других людей совсем некоторое время;). Вот ответы на некоторые из вопросов.

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

ОТВЕТЫ

Ответ 1

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

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

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

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