Что занимает более 65% времени в приложении ASP.NET? - PullRequest
9 голосов
/ 11 августа 2011

У меня есть веб-приложение .Net Framework 4.0, ASP.NET, ASP.NET MVC 3, размещенное на Windows 7 / IIS 7.5.Ведение журнала IIS на этом компьютере включено и настроено для входа в режиме W3C.

Приложение скомпилировано с использованием конфигурации выпуска и было развернуто в IIS с явно установленным атрибутом <compilation debug='false'.Web.config определяет использование состояния сеанса на основе SQL Server.

Я добавил следующие выражения в Global.asax в событиях BeginRequest и EndRequest соответственно.Результаты, т. Е. «Sw.Elapsed.TotalMilliseconds», сохраняются в списке значений уровня приложения.Я выкидываю эти значения через страницу отладки и получаю в среднем то же самое.

// in BeginRequest
HttpContext.Current.Items.Add("RequestStartEnd", System.Diagnostics.Stopwatch.StartNew());

// in EndRequest
var sw = (System.Diagnostics.Stopwatch)HttpContext.Current.Items["RequestStartEnd"];
sw.Stop();

Я создал нагрузочный тест, который запускает один запрос к этому приложению с одновременной пользовательской нагрузкой в ​​20 пользователей.Тест выполняется в Visual Studio 2010 Ultimate Edition.

После запуска нагрузочного теста я получаю среднее время, которое записывается секундомером, как 681 миллисекунду. Среднее время, требуемое в соответствии с IIS для этихзапросы (я очистил все журналы перед запуском нагрузочного теста) составляет 2121 миллисекунду.Среднее время, затрачиваемое согласно подсчетам IIS, со значением, показанным в отчете о нагрузочном тесте Visual Studio.

Время, затраченное на секундомер, составляет только 32% времени, указанного в журналах IIS / Visual Studio.Куда уходит остальные 68% времени?

Обновление 1: Я установил состояние сеанса на InProc и повторно запустил нагрузочный тест.В этом сценарии разница между средним временем, сообщаемым секундомером, и средним временем, зарегистрированным журналами IIS, выросла до более чем 70% !!!Куда все это время идет?

Обновление 2: @Peter - я опробовал трассировку невыполненных запросов, установив правило трассировки для входа в код состояния 200. Затем я запустил нагрузочный тест с 20 одновременными пользователями дляоколо 1,5 минут.Просматривал последние 50 файлов трассировки и обнаружил, что поле «Время взято» в этом отчете имеет диапазон от 750 до 1300 мс.Отчет Visual Studio показал среднее значение.время, принятое как 2300 мс.В отчете, используя компактный вид, я вижу, что время, затраченное на изменение, изменяется между следующими переходами (1) AspNetStart -> AspNetAppDomainEnter (2) ManagedPipelineHandler-start ManagedPipelineHandler-end.Элемент (2), вероятно, код моего приложения.Тем не менее, существует большая разница между максимальным количеством времени, затрачиваемым согласно журналам неудачных запросов, т.е. 1300 мс, и средним значением.время, как показано Visual Studio 2300ms.Как найти учет для этого?Спасибо за этот замечательный совет, хотя!

Ответы [ 5 ]

3 голосов
/ 17 августа 2011

Как долго вы проводите нагрузочный тест? Если вы запускаете его под Windows 7, вы можете получить и другие результаты, чем под Windows сервером. У вас могут быть проблемы с получением потоков, выделенных для пула потоков при пакетных нагрузках. .Net немедленно выделит потоки до минимума пула потоков, а затем медленно выделит до максимума пула потоков. Я считаю, что настройки по умолчанию для клиентских ОС отличаются от настроек для серверных ОС. Это может быть в клиентской ОС. Минимальная настройка потока по умолчанию равна числу ядер на вашей машине, а это значит, что .net будет медленно выделять больше потоков для удовлетворения вашей пакетной нагрузки.

Простая проверка состояла бы в том, чтобы позволить вашему нагрузочному тесту продлиться дольше и посмотреть, не уменьшается ли разрыв между вашими 2 измерениями.

2 голосов
/ 21 августа 2011

Скорее всего, комбинация Управляемого конвейера служебной нагрузки и вашей сети (даже localhost или 127.0.0.1), вероятно,где «потерянное» время может быть учтено.

  1. Вы упоминаете, что IIS регистрирует данные с нагрузочных тестов Visual Studio - оба из них включают сетевой стек и управляемую линию.
  2. Ваш код секундомера выполняется только внутри контекста ASP.NET (непосредственно перед началом выполнения ASP.NET и непосредственно перед его завершением) и не учитывает накладные расходы IIS при обработке сетевого запроса TCP, разбирая HTTP-заголовки длявремя запроса и ответа, а также время передачи через управляемый конвейер и стек TCP.
  3. [EDIT] Эта пропорция еще больше преувеличена, если время выполнения страницы ASP.NET действительно быстрое, напримерон не потребляет много ресурсов ЦП относительно остальной части стека TCP и управляемого конвейера, который маршалирует HTTP-запрос для вас
2 голосов
/ 19 августа 2011

Я бы предложил заглянуть в MvcMiniProfiler. Это пакет NuGet, который вы можете добавить и подключить (почти без усилий), который действительно сокращает время выполнения различных точек в вашем приложении MVC. Вы можете увидеть в реальном времени каждый запрос и определить наличие узких мест.

Дополнительная информация:

2 голосов
/ 11 августа 2011

Существует лучший способ заглянуть внутрь вашего приложения, используя "Правила отслеживания невыполненных запросов"

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

С этим вы можете точно следовать тому, что ваше приложение делает в IIS

1 голос
/ 18 августа 2011

Если у вас есть проблемы с длительным временем загрузки, это может быть связано с несколькими вещами, если у вас большое количество операций ввода-вывода, это может повлиять на это, если вы выполняете запросы к базе данных с помощью orm, попробуйте профилировать ваши операторы sql в vs withSQL Server Profiler или SQL Server, встроенный в Profiler. Если вы получаете много отдельных запросов, вы можете рассмотреть возможность использования некоторых из ваших запросов linq для объединения некоторых ваших данных в отдельные запросы

.рассмотреть вопрос об использовании асинхронных контроллеров для сокращения времени отклика, если у вас много операций ввода-вывода, поэтому ваше приложение не ждет, пока каждая операция завершится, см. wintellect.com / CS / blogs / jprosise / archive / 2010/03/ 29 /…

Существуют также лучшие решения для ведения журнала, чем протоколирование iis, так как это довольно старый компонент, вы можете взглянуть на log4net для более общего ведения журнала или elmah для ошибок ведения журнала.и исключения, поскольку эти решения могутсвяжите кучу записей журнала и запишите несколько в одной операции, также улучшая производительность ввода-вывода

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...