ASP.NET Web Services + Диагностика производительности IIS

Question

Необходимо найти узкое место производительности в серверном приложении под большой нагрузкой. Приложение состоит из экземпляра одиночных сервисов (.asmx) и некоторых файлов, которые время от времени запрашиваются по http. Мой план решения этой проблемы: 1) получить исключительную ситуацию, когда сервер начинает сбой как-то 2) анализировать счетчики производительности и журналы в этот момент времени, чтобы вычесть, какие вызовы вызвали это.

Для этого я внедрил специальный клиент, который обрабатывает оба типа запросов и заставляет его повторять соответствующие циклы неопределенно надеясь, в какой-то момент я получу ошибки во время запросов URL-адреса WebMethod/GET (NB - стандартные уже существующие решения такие как JMeter и WAPT не могут использоваться в сложном сценарии использования сервисов). До сих пор я наблюдаю увеличение времени отклика в вызовах службы и некоторых исключениях тайм-аута сети во время загрузки файлов (используя HttpClient, который генерирует OperationCanceledException, который считается тайм-аутом в соответствии с - this thread). Кстати, это странно, потому что размер файлов невелик kb, а методы службы возвращают 5-10 мб данных за запрос. Мысль «большие» запросы с большей вероятностью потерпит неудачу в первую очередь.
Perfmon показывает увеличенную загрузку процессора и абсолютно никаких всплесков памяти/утечек. Request Execution Time counters довольно случайны и выглядят неуместными, длина очереди всегда равна 0.
Это говорит о том, что IIS хорошо справляется с моим импровизированным DDoS и в то же время делает неэффективным подход к тестированию (увеличение времени ответа означает более активные запросы в памяти на тестовый клиент, который вызывает переполнение памяти в какой-то момент, и я уже очищаю данные сразу после получения, не делая ничего с ним).
Подробнее: серверный компьютер имеет 4x3 ГГц ядра, 4 Гб оперативной памяти. Я генерирую нагрузку 50-100 запросов в секунду, что приводит к полосе пропускания 10-20 Мбит/с (тестовые клиенты расположены на виртуальной машине внутри центра данных сервера, NIC 4 Гбит/с). 30-минутный сеанс тестирования составляет ~ 10-30 Гб чистой передачи данных между сервером и клиентом.
Как я могу заставить веб-службу/IIS спуститься?

Answer 1

Во-первых, я бы не стал писать свой собственный инструмент тестирования нагрузки; есть много доступных. Я использовал JMeter (с открытым исходным кодом). Вы можете использовать JMeter (и другие подобные инструменты) для отправки как POST, так и GET parameters, файлов cookie и других HTTP-заголовков - хотя, по общему признанию, это становится сложной задачей для сложных случаев.

Затем убедитесь, что ваша проблема действительно является сервером, а не другой инфраструктурой - сетью, маршрутизаторами, брандмауэрами и т. Д. Все имеют максимальные возможности и могут быть основной причиной проблемы. Большинство из них имеют инструменты ведения журнала и отчетности. Например, я видел, как тесты сообщают о пропускной способности, когда они достигли максимальной емкости брандмауэра; серверы не были даже близки к точке разлома. Это произошло из-за того, что мы включили в тестовые примеры довольно большой двоичный файл, который, как правило, будет обслуживаться с CDN.

Далее, в целом маловероятно, что обслуживание статических HTTP-запросов является проблемой - IIS действительно, действительно good. Для такого типа оборудования, о котором вы говорите, я ожидал бы обрабатывать много тысяч запросов в секунду. для статических файлов.

В большинстве случаев это динамические страницы, которые вызывают проблему - ваш .asmx. Таким образом, я бы проигнорировал все статические файлы при нагрузочном тестировании и сосредоточился на .asmx. Что касается оборудования, которое вы упомянули, вам, вероятно, придется генерировать много сотен запросов в секунду, если asmxes работают правильно.

Исходя из предположения, что ваш веб-сервер настроен правильно, а сценарии asmx достаточно эффективны, я ожидал бы, по крайней мере, вдвое больше (процессор и память) из тестовой системы, так как ваш сервер должен (это основано на моем опыте работы с JMeter, который не так эффективен, как мои веб-приложения, но облегчает развертывание нескольких тестовых клиентов). Поэтому в вашем случае я бы поискал 2 машины, соответствующие вашей спецификации сервера.

С JMeter (и почти всеми другими инструментами тестирования нагрузки, с которыми я работал) вы можете легко использовать несколько машин в качестве тестовых клиентов нагрузки; Я также использовал создание нагрузки на основе облачных вычислений с использованием JMeter.

Я не совсем уверен, почему это эмпирическое правило верно, но я наблюдал его за несколькими проектами.