Мое приложение ASP.NET занимает много времени, чтобы загрузить запрос первой страницы после переработки iisreset или домена приложения.Сроки первоначального запуска в приложении ASP.NET
Есть ли способ достоверно измерить количество времени, которое требуется для восстановления домена приложения?
Недостаточно написания приложения, которое контролирует процессы и ожидает, что процессорное время достигнет нуля, скорее всего, вам понадобится использовать секундомер и просто перезапустить несколько раз. Когда вы попадаете во много-секундные тайминги, миллисекунды уже не имеют никакого значения. Итак, секундомер должен быть достаточно хорошим.
Вы можете использовать профилировщик, перемещаясь по коду, измеряя узкие места с различными режимами выборки процессора и т. Д. Инструментом такого типа является dotTrace. :) http://www.jetbrains.com/profiler/
У нас была аналогичная проблема, и я не знаю, поможет ли наш опыт. К счастью, это произошло в то время, когда мы сначала изучали сервис-ориентированную архитектуру, поэтому нам было очень интересно, как использование веб-сервисов влияет на производительность по сравнению с другими методами получения данных.
Я не говорю, что наши результаты будут полезны для вас, но, возможно, методология.
Мы фактически провели два полных 8-часовых дня, ничего не делая, кроме тестирования разных сценариев подключения. Нам особенно любопытно добавлена пропускная способность, связанная с получением данных через XML, а не двоичные данные. Мы полностью ожидали снижения производительности просто за счет получения XML-данных, которые, как мы предполагали, будут больше байтов по всей сети.
Я не буду вдаваться в результаты, поскольку это был документ на 10 страниц сам по себе, но мы обнаружили интересное отставание, которое произошло, когда мы получали данные из веб-службы, написанной на языке .Net, к которому обращались данные о iSeries (AS/400, System i, или что-то новое в наши дни). Так же, как вы описали, первый вызов для получения данных занял некоторое время, но последующие вызовы были более быстрыми.
Оказалось, что тип подключения, который мы использовали (ODBC, предоставленный Microsoft), был виновником в нашем случае, если посмотреть на сетевые пакеты.
Мы измерили сетевые пакеты между клиентом и веб-службой, а также между веб-службой и хранилищем iSeries (хранилище данных), и мы обнаружили, что это отставание происходит, поскольку первый раз веб-служба установила соединение с iSeries, несколько ненужных пакетов отправлялись туда и обратно.
Вкратце, сторона Windows отправила запрос на соединение, подождать несколько миллисекунд, а затем отправить другой. Между тем, iSeries просто не отвечал на запросы, поэтому в первой попытке подключения было четыре вызова для подключения со стороны Windows к стороне iSeries, а затем четыре ответа от iSeries, которые были проигнорированы стороной Windows (потому что сторона Windows соединения отказалась). Наконец, после 4-6 попыток было установлено соединение. После этого соединение должно быть объединено, потому что последующие соединения в течение короткого времени были быстрыми. Однако, если время прошло (мы никогда не определяли, сколько времени понадобилось для этого), медленное начальное соединение всплыло.
ТАК, после всего этого долгого извержения @Aggelos Mpimpoudis предложил профилировать собственный код. Мое предложение было бы найти того, у кого есть опыт и инструменты для анализа сетевых пакетов и анализа всего процесса. Возможно, вы сможете проследить виновника таким образом.
Кстати, наша проблема улучшилась после того, как мы переключились на подключение к iSeries с использованием Ibm.Data.Db2.iseries вместо драйвера System.Data.Odbc. И после того, как у нас было достаточно веб-сервисов, написанных, что частота вызовов на iSeries было достаточно, чтобы открыть объединенное соединение.
Проблема в том, что он пытается измерить время * вне * кода, который он написал. –
Не обязательно ,,, Часть отставания может быть в его собственном коде – David
Он хочет измерить весь процесс, поэтому измерить его часть недостаточно. –