Как выполнить нагрузочное тестирование с использованием jmeter и visualVM?

Question

Я хочу провести нагрузочное тестирование для 10 миллионов пользователей моего сайта.Сайт представляет собой веб-приложение на основе Java.Мой подход состоит в том, чтобы создать план тестирования Jmeter для всех ссылок, а затем составить отчет для 10 миллионов пользователей.Затем с помощью jvisualVM выполните профилирование и проверьте, нет ли узких мест.

Есть ли лучший способ сделать это?Есть ли демоверсия для этого?Я делаю это впервые, поэтому любая помощь будет очень полезна.

Answer 1

Вы находитесь на правильном пути, но ваш предел нагрузки имеет высокий коэффициент.

Почему я говорю это, потому что вашему сайту, вероятно, понадобится больше машин для работы с пользователями 10Milj Concurrent. Самому процессу, вероятно, будет трудно справиться с одновременными 32K TCP-потоками. Также определите, какая пропускная способность потребуется для работы с пользователями 10Milj.

Теперь я не знаю, какую услугу вы планируете предоставлять на своем сайте, но если подумать о том, что JVisualVM замедляет обработку в 10 раз (или более для отслеживания методов), вы на самом деле не будете измерять «реальный мир». "если вы заставили JMeter и JVisualVM работать одновременно.

JVisualVM более полезен при работе на более низких нагрузках.

Для создания хорошего измерения сначала убедитесь, что у вас хорошая базовая линия. Проведите тест с 10 одновременными пользователями, подключите JVisuamVM и дайте ему поработать некоторое время, а не по всем интересующим значениям.

После того, как у вас есть базовый уровень, вы можете начать добавлять дополнительную нагрузку. Добавьте 10-кратную нагрузку (например, 100 пользователей), посмотрите на изменения в JVisualVM. Продолжайте так до тех пор, пока не станет очевидно, что JVisualVM замедляет вас, каждый раз, когда вы добавляете дополнительную нагрузку, убедитесь, что вы записали числа, которые вас интересуют. Запишите числа на графике.

Теперь ... Интерполируйте график (вручную) для количества желаемых пользователей. Это работает для использования памяти, доступа к диску и т. Д., Но не для использованного процессорного времени, поскольку JVisualVM будет потреблять процессор и сообщать вам недопустимые числа (особенно если у вас включена трассировка методов).

Если вы действительно хотите достичь уровня 10Milj, я бы тоже не стал доверять JMeter, я бы написал свою собственную небольшую тестовую программу, которая выполняет желаемый вами тест. Это было бы хорошо, так как настройка сайта для обработки 10Milj также потребует времени, поэтому тратить немного больше времени на инструменты тестирования не пустая трата времени.

Answer 2

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

Узкие места приложения обычно делятся на три категории: база данных, утечка памяти или медленный алгоритм.Их обнаружение включает в себя нахождение рассматриваемой заявки под нагрузкой (то есть под нагрузкой) в течение продолжительного периода времени - не менее часа, возможно, до нескольких дней.Jmeter - хороший инструмент для этой цели.Одной из вещей, которые следует учитывать, является запуск одного и того же теста с включенной обработкой файлов cookie (т. Е. Jmeter сохраняет файлы cookie и отправляет их при каждом последующем запросе) и отключается - иногда вы получаете очень разные результаты, и это важно, поскольку последний фактически представляет собой симуляцию того,сканеры делают на ваш сайт.Ниже приведены подробные сведения об обнаружении узких мест:

База данных

Таблицы без индексов или операторов SQL, включающих несколько объединений, являются частыми узкими местами приложений.Каждый сервер баз данных, с которым я имел дело, MySQL, SQL Server и Oracle имеет некоторый способ регистрации или идентификации медленно выполняющихся операторов SQL.MySQL имеет медленный журнал запросов, тогда как SQL Server имеет динамические административные представления, которые отслеживают самый медленный SQL-запрос.После того, как вы освоите медленные операторы, используйте план объяснения, чтобы увидеть, что движок базы данных пытается сделать, используйте любые функции, которые предлагают индексы, и рассмотрите другие стратегии - такие как денормализация - если эти два варианта не устраняют узкое место,

Утечка памяти

Включите подробное ведение журнала сбора мусора и порт мониторинга JMX.Затем используйте jConsole, которая обеспечивает намного лучшие графики, чтобы наблюдать тенденции.В частности, утечки, как правило, обнаруживаются как заполнение пробелов Старого или Пермского поколений.Утечки являются узким местом, поскольку JVM тратит все больше времени на попытки безуспешного сбора мусора, пока не возникнет ошибка OOM.

Perm Gen подразумевает необходимость увеличения места в качестве параметра командной строки для JVM.В то время как Old Gen подразумевает утечку, где вы должны остановить нагрузочное тестирование, сгенерировать дамп кучи, а затем использовать Eclipse Memory Analysis Tool для определения утечки.

Медленный алгоритм

Это сложнее отследить.Наиболее частыми нарушителями являются синхронизация, межпроцессное взаимодействие (например, RMI, веб-сервисы) и дисковый ввод-вывод.Другая распространенная проблема - код, использующий вложенные циклы (посмотрите на производительность O (n ^ 2)!).

Лучший способ найти эти проблемы в отсутствие некоторых более глубоких знаний - генерировать трассировки стека.Они скажут, что все потоки делают в данный момент времени.Вам нужны блокированные потоки или несколько потоков, которые обращаются к одному и тому же коду.Это обычно указывает на некоторую медлительность в кодовой базе.

Answer 3

То, что у вас есть 10 миллионов пользователей в базе данных, не означает, что вам нужно загрузить тест с использованием такого количества пользователей.Подумайте об этом - действительно ли ваш сайт будет иметь 10 миллионов одновременных пользователей?Для веб-приложений распространено соотношение 1: 100 зарегистрированных пользователей, т.е. вряд ли у вас будет более 100 000 пользователей в любой момент.

Может ли JMeter справляться с такими нагрузками?Я сомневаюсь.Пожалуйста, попробуйте Фабан вместо.Он очень легкий и может поддерживать тысячи пользователей на одной виртуальной машине.Вы также можете значительно повысить гибкость при создании рабочей нагрузки и автоматизировать мониторинг всей тестовой инфраструктуры.

Теперь перейдем к части анализа.Вы не сказали, какой сервер вы используете.Любой Java-сервер приложений обеспечит достаточную поддержку мониторинга.Коммерческие серверы предоставляют хорошие инструменты графического интерфейса, в то время как Tomcat обеспечивает расширенный мониторинг через JMX.Возможно, вы захотите начать здесь, прежде чем перейти к уровню JVM.

Для JVM вы действительно не хотите использовать VisualVM при выполнении такого большого теста производительности.Помимо поддержки такой загрузки, я предполагаю, что вы используете несколько экземпляров appserver / JVM.Основной проблемой производительности обычно является GC, поэтому используйте параметры JVM для сбора и регистрации информации GC.Вам придется постобработать данные.

Это нетривиальное упражнение - удачи!

Answer 4

Я начал использовать плагины JMeter .
Это позволяет мне собирать метрики приложений, доступные через JMX для использования в моем нагрузочном тесте.

Answer 5

Я веду блог, как я продолжил тест производительности:

1. Убедитесь, что на сервере (аппаратное обеспечение может соответствовать требованиям подготовки / производства) нет других установок, которые могут повлиять на производительность.
2. Для настройки пользователей в БД можно использовать процедуру, которая может быть вызвана как часть плана тестирования jmeter.
3. Установите jmeter на отдельном компьютере, чтобы он не влиял на производительность.
4. Создайте план тестирования в jmeter (как показано на рисунке 1) для всех URI с проверкой ответов и запросами на основе таймера.
5. Взять начальный тест, используя jmeter.
6. Проверьте URI с низкой производительностью. Это те моменты, которые следует ожидать для узких мест.
7. Попробуйте различные варианты улучшения производительности, но сосредоточьтесь только на одном узком месте за раз.
8. Попробуйте любое исправление из шага 6, а затем сделайте тест. Если есть какие-либо улучшения, передайте изменения и повторите с шага 5. В противном случае вернитесь и попробуйте любые другие варианты с шага 6.
9. Следующим шагом будет использование балансировки нагрузки, аппаратного масштабирования, кластеризации и т. Д. Это может включать некоторые физические настройки и стоимость аппаратного / программного обеспечения. Дайте результаты с опциями масштабируемости.

Для подробного объяснения: http://www.daemonthread.com/2011/06/site-performance-tuning-using-jmeter.html