Как протестировать производительность сайта в JMeter: пошаговые примеры и настройки

Apache JMeter — приложение на Java, созданное для нагрузочного тестирования и измерения производительности. Изначально создавалось для тестирования web-приложений, однако, позже были добавлены другие функции тестирования.

Для полноценного использования JMeter рекомендуется всегда скачивать актуальную версию с официального сайта. Графический интерфейс предназначен для создания, отладки тестов и небольших нагрузочных тестов. Для серьёзного тестирования используйте консольный режим.

  • Установите Java
  • Перейдите на официальный сайт JMeter. Скачайте последнюю версию JMeter в архиве .zip для Windows.
  • Необязательно, но рекомендуется установить Менеджер плагинов (plugins-manager.jar). вам нужно просто скачать файл и поместить в директорию apache-jmeter\lib\ext.
  • Запускать файл Windows apache-jmeter\bin\ApacheJMeter.jar

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

apt update
apt install openjdk-11-jre openjdk-11-jdk
apt install jmeter

Запускать файл Linux /usr/share/jmeter/bin/ApacheJMeter.jar. Для консольного запуска используйте команду:

./jmeter -n -t testPlan.jmx -l log.jtl

1. Создание Test Plan

  • Кликните на “Test Plan” в левой панели.
  • Введите название плана, например: Load Test for site.com.
  • Необязательно: отметьте “Run Thread Groups consecutively” для последовательного запуска групп потоков.

2. Добавление Thread Group (группа потоков)

  • Правый клик по Test Plan → Add → Threads (Users) → Thread Group.
  • Установите параметры:
    1. Number of Threads (users): количество виртуальных пользователей (например, 100). Number of Threads (users) - этот параметр определяет, сколько виртуальных пользователей одновременно будут "заходить" на ваш сайт или сервис, имитируя настоящих людей. Если указать 100 – это значит, что JMeter будет вести себя так, будто в один момент сайт используют сразу 100 человек.
    2. Ramp-Up Period (seconds): За сколько секунд все пользователи запустятся, например, 10 секунд. За сколько секунд все эти пользователи «включатся» в работу. 👉 Например, если указать 200 пользователей и Ramp-Up Period = 10 секунд, то JMeter будет запускать примерно 20 пользователей в секунду (200 ÷ 10 = 20). Это позволяет нагрузке плавно увеличиваться, а не обрушиваться мгновенно. 💡 Если ты поставишь Ramp-Up = 0, то все 200 пользователей стартуют одновременно, и это создаст мгновенный пик нагрузки (что не всегда хорошо для сервера).
    3. Loop Count: число повторов, например 5. Loop Count показывает, сколько раз каждый "пользователь" выполнит ваши действия (например, откроет страницу или отправит запрос). Если указано 5 — каждый пользователь сделает одно и то же 5 раз.

2.1 Как посчитать количество запросов

Общее число выполненных сценариев рассчитывается по формуле:

Number of Threads × Loop Count

Пример: 200 пользователей × 5 повторов = 1000 итераций сценария.

Если внутри сценария (Thread Group) есть несколько HTTP-запросов, например 3, то итог будет: 200 × 5 × 3 = 3000 HTTP-запросов.

3. Добавление HTTP Request

Вместо HTTP Request, при необходимости, можно выбрать другие виды Sampler-ов, например, FTP Request, JDBC Request, SOAP/XML-RPC Request, TCP Sampler или даже создать собственный с помощью JSR223 Sampler (позволяет выполнять скрипты прямо внутри JMeter), чтобы тестировать разные сервисы, протоколы и сценарии.

  • Правый клик по Thread Group → Add → Sampler → HTTP Request.
  • Заполните поля:
    1. Protocol: http или https
    2. Server Name or IP: например, example.com
    3. Path: адрес страницы, например, /
    4. Method: GET или POST

Достаточно Path

В JMeter достаточно указать в поле Path полный URL, например https://textodrom.net/services/reklama-restorana-teksty-i-slogany, если требуется выполнить запрос именно по этому адресу. В этом случае поля Protocol, Server Name или Port заполнять не нужно — JMeter автоматически определит их из полного URL. Это упрощает настройку отдельных HTTP-запросов к конкретной странице или сервису.

4. Добавление Listener (отчётов)

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

  • Правый клик по Thread Group → Add → Listener → View Results Tree.
  • Рекомендуется добавить несколько Listener для разных вариантов анализа.

Если потребуется более глубокий анализ ― например, сравнивать среднее время отклика, процент ошибок или скорость обработки запросов на больших нагрузках ― можно подключить дополнительные Listener типа Summary Report или Aggregate Report, которые выведут общую статистику и помогут отследить производительность при массовом тестировании. Но для первых шагов и ручной проверки чаще всего вполне достаточно одного “дерева результатов”.

5. Сохранение и запуск теста

  • Сохраните тестовый план (File → Save) с расширением .jmx.
  • Запустите тест кнопкой “Start” (зелёная стрелка).
  • Просмотрите результаты в выбранных Listener.

Полезные рекомендации

  • Для сложных сценариев используйте конфигураторы (Header Manager, CSV Data Set Config, Cookie Manager).
  • На больших нагрузках Listener "View Results Tree" лучше отключать для экономии ресурсов.
  • Для запуска в консольном режиме используйте:
jmeter -n -t testplan.jmx -l results.jtl
  • Анализируйте Summary Report для выявления узких мест и ошибок.

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

Информационные сайты (блоги, новостники, каталоги) обычно имеют небольшую долю одновременных посетителей и относительно лёгкие запросы к базе данных. Для стандартного информационного сайта на WordPress рекомендую задать такие значения для первого теста:

  • Number of Threads (users): укажите конкретное число активных пользователей, например, 50 или 100. Это имитирует реальный трафик — сколько посетителей одновременно будут заходить на сайт.
  • Ramp-Up Period (seconds): выберите время "разгона", например, 20–30 секунд — так пользователи начнут тест одновременно, но с небольшими паузами, как в жизни.
  • Loop Count: установите, сколько раз каждый виртуальный пользователь повторит действия, например, 3–5 раз.

👉 Такой сценарий покажет, как сайт реагирует на умеренную, но стабильную нагрузку, аналогичную ситуации, когда одновременно заходят десятки реальных пользователей.

Для магазина на WooCommerce эти значения лучше увеличить, чтобы проверить работу сайта под нагрузкой от большого числа покупателей. WooCommerce-сайты создают более тяжёлую нагрузку: каждый запрос может задевать базу данных, корзину, кэш и плагины. Рекомендуемые значения:

  • Number of Threads: 150–300 (это может показать работу во время распродажи).
  • Ramp-Up Period: 30–60 секунд.
  • Loop Count: 5–10 и более.

👉 Такой тест поможет выявить, как быстро сервер реагирует при пиковых нагрузках — например, во время акций или распродаж.

Настройка этих параметров помогает смоделировать реальные сценарии посещения — выявить, когда сайт начинает “тормозить”, где возникают ошибки при большом наплыве пользователей. На основе полученных данных видно, выдержит ли ваш хостинг высокую нагрузку, стоит ли выбрать более мощный тариф VPS/VDS, если сайт или магазин часто посещают одновременно. Эти тесты дают реальное понимание, как сайт ведёт себя под нагрузкой и помогают принять обоснованное решение при выборе хостинга.

Не существует универсальных значений для Number of Threads, Ramp-Up Period и Loop Count — всё зависит от того, что именно вы хотите проверить. Одно дело — убедиться, что сайт работает стабильно при обычной посещаемости, другое — понять, выдержит ли он всплеск трафика во время рекламной кампании или распродажи.

Этот тест нужен, чтобы оценить, как сайт ведёт себя при обычном уровне трафика — например, когда одновременно на сайте 10–20 человек.

Рекомендуемые параметры:

  • Number of Threads (users): 10–20
  • Ramp-Up Period: 10–20 секунд
  • Loop Count: 10–20

Такой сценарий показывает поведение сайта в повседневных условиях. Подходит для небольших блогов, корпоративных сайтов, лендингов и молодых проектов на WordPress.


Когда сайт уже посещают сотни пользователей в день, стоит проверить, как он реагирует при росте одновременных подключений — например, во время публикации статьи или продвижения в поиске.

Рекомендуемые параметры:

  • Number of Threads: 50–150
  • Ramp-Up Period: 20–40 секунд
  • Loop Count: 5–10

Такой тест позволяет выявить «узкие места» — например, медленные плагины, неэффективный кэш или слабый CPU на хостинге.


Для WooCommerce-магазинов и крупных проектов полезно знать, где предел. Такой тест имитирует пиковые продажи или акции, когда на сайт одновременно заходит много покупателей.

Рекомендуемые параметры:

  • Number of Threads: 150–300
  • Ramp-Up Period: 30–60 секунд
  • Loop Count: 5–10

Этот тест помогает оценить, выдержит ли сайт внезапный наплыв трафика и как быстро сервер начнёт терять производительность.

При нагрузочном тестировании важно не столько число «виртуальных» пользователей, сколько то, какую реальную ситуацию вы моделируете. JMeter имитирует одновременных посетителей, выполняющих заданные действия, а не общее количество посетителей за сутки.

Тип сайта Number of Threads (users) Ramp-Up Period (seconds) Loop Count Примерная нагрузка (эквивалент)
Информационный сайт на WordPress 20–50 20–30 3–5 ~1 000–3 000 посетителей в сутки
Интернет-магазин на WooCommerce 50–100 30–60 5–10 ~5 000–10 000 посетителей в сутки
Средний корпоративный портал 100–150 60 5–10 ~10 000–20 000 посетителей в сутки

Эти значения условные! Они помогают понять, какую одновременную нагрузку выдерживает сайт, а не точное число реальных пользователей в сутки.

Результаты зависят от длительности теста, задержек между действиями (think time) и количества HTTP-запросов внутри сценария.

После теста JMeter покажет среднее время отклика, процент ошибок и производительность (Throughput). Эти данные помогут:

  • Оценить, справляется ли текущий хостинг с реальной нагрузкой.
  • Понять, стоит ли переходить на более мощный тариф (VPS, выделенный сервер).
  • Сравнить разные провайдеры по скорости и стабильности под одинаковыми условиями.

💡 Совет

Если ваш сайт выдерживает тест с 100 одновременными пользователями без ошибок и с временем отклика < 2 секунд — такой хостинг уже можно считать надёжным решением для реальной аудитории 10–20 тысяч посетителей в сутки.

Лучше не ограничиваться одним тестом:

  1. Начните с реалистичных параметров, чтобы убедиться, что сайт работает стабильно.
  2. Затем постепенно увеличивайте нагрузку, чтобы понять, где начинаются задержки и ошибки.

Такой подход помогает оценить запас прочности и выбрать хостинг осознанно:

  • shared-тариф подойдёт для блогов;
  • VPS/VDS — для WooCommerce и проектов с динамическими страницами;
  • managed WordPress-серверы — для тех, кто хочет стабильную скорость без ручной настройки.

📌 Удобный подбор VPS по параметрам доступен на DIEGfinder.com - официальном инструменте проекта DIEG. Это часть единой экосистемы, созданной для того, чтобы помочь быстро найти подходящий VPS/VDS сервер для любых задач хостинга.

📌 Для тестирования скриптов, установщиков VPN и Python-ботов рекомендуем использовать надежные VPS на короткий срок. Подробнее о быстрой аренде VPS для экспериментов - читайте здесь.

💥 Подпишись в Телеграм 💥 и задай вопрос по сайтам и хостингам бесплатно!