Узкое место

Количество vusers растет.
Transaction Responce Time растет.
Transaction/sec остается неизменным с момента когда количество vusers достигает определенной величины.

CPU сервера приложений загружен процентов на 70. И больше загружаться не хочет.
Сетевые адаптеры загружены меньше чем на 1%.
CPU сервера базы данных загружен процентов на 20-30.

Как искать узкое место?

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

Тут в принципе, логика такая:
1. сервер приложений может обработать еще больше запросов, но у него стоит ограничение на создание request handler'ов => сообщения встают в очередь => время ответа растет, а trans. per sec не увеличивается.
2. если это максимум, который обрабатывает сервер приложений, то надо смотреть на проблемы параллелизма, переключение контекстов между тредами, т.е. кто-то кого-то ждет.
Мне видится такой подход. Если у кого-то есть другие идеи, будет интересно почитать.

Сообщение отредактировал AxelM: 08 июля 2011 - 13:55

• Смотрите загрузку других системных ресурсов, cpu и сети для анализа мало. Потоки очередей, память, кэш. Можно выбрать все-все ресурсы в perfmon'e и искать горлышко.
• Проверьте масштабируемость: что изменится при изменении конфигурации сервера в лучшую сторону (если возможно)? Вы можете столкнуться с 2мя интересными вариантами: повышением результатов и загрузкой проца на 70% или такими же результатами с меньшей загрузкой проца.
• Проверьте ресурсы на машине-нагрузчике, вдруг это он ботлнек?

А вообще, чтобы понимать, что анализировать, нужно понимать архитектуру продукта, в противном случае проблемы алгоритма локализовать почти невозможно. Можно ли для тестов изолировать сервер приложений от сервера БД?