Если у вас есть сервер, вы можете примерно знать, с каким объемом запросов он может справиться, прежде чем он начнет падать или отказывать. Падение может принимать форму отказа в подключении или длительного ответа на все запросы или на определенную часть запросов.
Чтобы получить некоторое представление о том, как ваш сервер работает в условиях нагрузки, вы можете использовать методы тестирования производительности или нагрузочного тестирования.
В чем разница между нагрузочным тестированием и сравнительным тестированием?
Хороший вопрос!
Нагрузочное тестирование - это большая нагрузка на ваше приложение. Итак, если мы говорим о сервере, это, вероятно, означает отправку на него большого количества запросов. Вас интересует, что происходит в системе в целом. Возможно, вы не ищете ничего конкретного, но вы хотите видеть, когда начинают происходить необычные вещи - замедление, плохая реакция, необычное поведение.
Для меня сравнительный анализ предлагает более конкретную цель. Вы хотите увидеть, как определенный фактор (или факторы) выдерживает определенное количество определенного стресса. Это может быть не чрезмерное количество стресса, а обычное количество. Например, если вы знаете, что можете ожидать, что на ваш сервер попадет 300 запросов в секунду, вы хотите запустить тест производительности, чтобы увидеть, как время отклика вашего сервера работает в этих условиях. Или вы можете захотеть запустить тест, в два или 10 раз превышающий вашу обычную нагрузку. Но цель - получить конкретный результат - сказать «с этим трафиком 95% запросов обрабатываются за n миллисекунд».
В этой статье я покажу вам, как вы можете использовать два инструмента, Apache Benchmark и JMeter, для нагрузочного тестирования или тестирования производительности.
Подготовка
Чтобы проверить свой сервер, сначала убедитесь, что он работает. Убедитесь, что вы запускаете его локально или как отдельный экземпляр для разработки, чтобы не повредить рабочий сервер и не вывести его из строя для реальных клиентов! Я бы порекомендовал запустить его как отдельный экземпляр для разработки и убедиться, что базовое оборудование максимально похоже на производственное оборудование, иначе у вас не будет честного теста.
Вероятно, ваш сервер будет взаимодействовать с внешними службами, такими как база данных, и эти службы будут влиять на работу вашего сервера. Чтобы пройти честный тест, вам следует как можно лучше воспроизвести эти внешние сервисы, например создать тестовую базу данных, тестовую очередь для вставки, тестовый кеш. Если вы просто удалите вызовы этих отдельных сервисов, вы не получите реалистичного представления о том, как ваш сервер будет вести себя в производственной среде.
Когда ваш сервер запущен, пора приступить к нагрузочному тестированию и тестированию производительности.
Я бы порекомендовал использовать два инструмента. Самый простой - это Apache Benchmark.
С помощью Apache Benchmark
Тест Apache - это простой в использовании инструмент, который поможет вам понять, как HTTP-сервер справляется с большими объемами трафика. Инструмент предустановлен на MacOS. Если вы используете дистрибутив Linux, Apache Benchmark поставляется вместе с пакетом httpd, который можно установить с любой системой управления пакетами, которую использует ваш дистрибутив.
Чтобы узнать больше об Apache Benchmark и увидеть, что он может делать, введите $ man ab
Мы можем попросить AB отправить определенное количество запросов на конкретную конечную точку. Мы также можем контролировать другие параметры, такие как параллелизм (сколько запросов будет запущено одновременно).
Отправка 500 запросов с максимальным одновременным выполнением 10 запросов
$ ab -c 10 —n 500 —r localhost:8000/api/books
Флаг —r означает, что в случае ошибки не выходить. По умолчанию AB выполняет запрос GET, поэтому, если вам нужно протестировать другой тип запроса, вам придется передать ему конкретную опцию для этого, а также установить заголовок типа содержимого запроса с помощью флага —T. Например, для отправки запросов POST с конкретным файлом, используемым в качестве данных POST, команда может иметь следующую форму:
$ ab -c 10 -n 500 -p event.json -r -T application/json localhost:8000/api/books
После выполнения теста AB распечатает такой отчет:
Здесь вы можете увидеть разбивку того, как быстро обрабатываются запросы, количество запросов в секунду и количество запросов, которые не удалось выполнить. Эта информация может быть очень полезной!
Обратите внимание, что Apache Benchmark будет запускать запросы как можно быстрее, учитывая разрешенный параллелизм. Трудно сказать «отправить 1000 запросов в течение 1 минуты» - это просто выполнит 1000 запросов как можно быстрее. Поэтому сложно смоделировать реалистичную нагрузку. AB обычно лучше выясняет, в какой момент ваша служба начинает ухудшаться, а затем выясняет, можно ли когда-либо разумно ожидать такой нагрузки.
Раньше я считал полезным использовать команду watch, чтобы продолжать запускать запросы AB в конечной точке и просто сидеть сложа руки и наблюдать за результатами. Например, эта команда повторяет тест AB каждую секунду:
$ watch -n 1 ab -c 10 -n 150 -r localhost:8080
(watch по умолчанию недоступен на Mac, но может быть установлен с $ brew install watch)
С JMeter
JMeter - более мощный инструмент, чем Apache Benchmark, и позволяет вам более точно определять, как запускается ваш трафик. Например, с JMeter можно сказать «Отправить 1000 запросов с интервалом более 1 минуты», что гораздо более реалистично. Он настолько настраиваемый, что предоставляет графический интерфейс пользователя (GUI), который поможет вам настроить тесты.
Установка
JMeter построен на Java, поэтому в вашей системе должна быть установлена Java. Если вы обнаружите, что вам нужно установить Java, вы можете сделать это здесь.
После установки Java на Mac вы можете установить JMeter с помощью Homebrew.
$ brew install jmeter
После этого вы сможете запустить графический интерфейс:
$ jmeter
На компьютере с Linux лучшим вариантом кажется перейти на веб-сайт JMeter и загрузить приложение прямо оттуда (опять же, сначала вам понадобится Java). Затем извлеките файл и запустите JMeter:
$ tar -xf apache-jmeter-5.1.tgz (или любую другую версию, которую вы скачали)
Перейдите в распакованный каталог:
$ cd apache-jmeter-5.1
И запустите следующее, чтобы запустить его:
$ ./bin/jmeter
Конфигурация
Откроется графический интерфейс, позволяющий настроить «план тестирования». Вы должны использовать графический интерфейс для настройки и тестирования своего «плана тестирования», но вернуться к интерфейсу командной строки для его фактического выполнения, поскольку графический интерфейс не сможет справиться с отображением огромных объемов запросов.
Сначала добавьте новую группу потоков, щелкнув правой кнопкой мыши План тестирования и выбрав Добавить → Темы → Группа потоков.
В настройках группы потоков вы можете указать, как должны вести себя запросы. Количество потоков представляет собой количество пользователей, которые будут одновременно подключаться к вашему приложению. Это похоже на параллелизм в AB. Период разгона - это время, в течение которого JMeter должен увеличить нагрузку с 0 до целевой, позволяя вашему серверу немного разогреться. Это значение может быть полезно использовать, чтобы вы могли видеть, как ваш сервер ведет себя при постепенном увеличении нагрузки.
Вы также можете изменить количество циклов или продолжать выполнение теста бесконечно, пока вы вручную не остановите его, установив галочку «навсегда». Начните с очень маленьких цифр, чтобы вы могли протестировать свою конфигурацию. Затем вернитесь и увеличьте их, когда будете готовы использовать интерфейс командной строки.
Вы можете настроить детали для фактического HTTP-запроса, который будет сделан, добавив HTTP-запрос Sampler:
В конфигурации для сэмплера вы можете добавить все детали запроса, включая метод, любые данные POST, кодировку контента и, конечно же, протокол, хост и путь.
Наконец, вам понадобится Listener, который будет фиксировать результаты вашего теста. Добавьте то, что вам нравится. Поэкспериментируйте и посмотрите, какой из отчетов даст вам самый интересный.
Пришло время сохранить конфигурацию и запустить ее, что можно сделать с помощью зеленой стрелки воспроизведения вверху. Убедитесь, что вы используете только небольшое количество пользователей для этого первого запуска, и переключитесь на интерфейс командной строки, когда будете довольны настройкой теста.
После того, как вы запустите тест, вы получите отчет в любом указанном вами формате, который вы сможете просмотреть через графический интерфейс, нажав на прослушиватель.
Запуск в режиме без графического интерфейса
Чтобы запустить тест JMeter из интерфейса командной строки, который необходим для больших нагрузок, сохраните конфигурацию теста как файл .jmx (я назвал свой blogpost.jmx), а затем в терминале введите
$ jmeter -n -t blogpost.jmx -l testresult.jlt где последний аргумент - это имя выходного файла, в котором будет сохранен отчет.
NB, если вы используете Linux, команда jmeter будет ./bin/jmeter.
После завершения теста файл результатов можно открыть и просмотреть в графическом интерфейсе. Откройте графический интерфейс и добавьте прослушиватель любого типа (например, сводный отчет) в план тестирования. Никакой другой конфигурации не требуется.
В области с надписью «Запись / чтение из файла» выберите файл .jlt, в котором были сохранены ваши результаты. Мне пришлось ввести путь к файлу в область ввода, потому что я не мог заставить работать файловый браузер 😔 Однако, если вы каким-то образом выберете файл .jlt, он отобразит результаты в графическом интерфейсе для вас!
Вот и все, что касается простой настройки. Вы можете настроить гораздо больше, в том числе использовать таймер постоянной пропускной способности для обеспечения постоянной нагрузки на ваш сервер, что может быть весьма полезно. Я не собираюсь здесь подробно останавливаться, так как есть много других руководств для достижения конкретных целей с помощью JMeter.
Надеюсь, это было полезно 🐙
Следуйте за мной в Twitter и оставьте аплодисменты, если вам это понравилось!
