Если вы хотите убедиться, что ваш сайт работает хорошо вне зависимости от интенсивности трафика, проведите нагрузочное тестирование.
Выражаясь простыми словами, нагрузочное тестирование – это разновидность тестирования производительности. Его используют для того, чтобы определить верхний предел веб-приложения и чтобы проверить, как система справляется с большой нагрузкой.
Если вы хоть раз задавались вопросом «как этот веб-сайт себя поведет с точки зрения производительности при экстремальной нагрузке, если к нему одновременно будет обращаться слишком много пользователей?», тогда эта статья для вас – здесь мы ответим на этот вопрос.
Ниже мы продемонстрируем три различных инструмента, с помощью которых вы сможете провести нагрузочное тестирования.
Но прежде, чем мы приступим, давайте для начала посмотрим, какие данные нам необходимо собрать.
Когда речь заходит о тестировании производительности, стоит понимать, что есть определенные показатели, которые могут описать наше приложение. Вот они:
- Время отклика (Response time) – количество времени между запросом и ответом на него.
- Среднее время загрузки (Average load time) – среднее время отклика.
- Максимальное время отклика (Peak response time) – самое большое значение времени отклика.
- Пропускная способность / запросы в секунду (Throughput / requests per second (rps)) – количество запросов, обрабатываемых в секунду.
- Использование памяти/ЦП (Memory/CPU utilization) – объем памяти/ЦП, потребляемый главным компьютером.
- Частота появления ошибок (Error rate) – соотношение типа ошибки/запросы.
- Одновременно работающие пользователи (Concurrent users) – количество активных пользователей/сеансов в приложении.
- Процентили (50% и 95%) (Percentiles) – процент запросов, время выполнения которых лучше некоторого определенного значения.
Loadtest
loadtest
Первый инструмент – это пакет npm под названием loadtest.
Для того, чтобы у вас была возможность использовать данный инструмент, вы должны установить на вашем компьютере NodeJS. После этого вам необходимо запустить следующую команду:
npm install -g loadtestLoadtest – это, определенно, самый простой и самый легкий инструмент для настройки и использования из данного списка. Все, что от вас требуется, это открыть командную строку и запустить:
loadtest [-n requests] [-c concurrency] URLВ демонстрационных целях мы будем использовать мой любимый веб-сайт blank.org. По сути, это пустая страница, которую чаще всего используют именно для тестирований.
Следующая команда отправит максимум 60 запросов от 30 различных одновременно работающих клиентов:
loadtest -n 60 -c 30 https://blank.orgПримечание: количество одновременно работающих пользователей никак не связано с количеством одновременно отправленных запросов.
Параллельно работающие пользователи/параллельные сеансы – это количество пользователей, подключенных к приложению, которые отправляют запросы через равные промежутки времени, но одновременно.
Результат работы предыдущей команды будет таким:
Этот инструмент дает нам информацию о:
- процентилях (50, 90, 95, 99 и 100%);
- среднем времени отклика;
- частоте появления ошибок.
Мы можем видеть, что для blank.org для 50% наших запросов время отклика 581 мс, а самое большое значение времени отклика составило 649 мс.
Loadmill
Loadmill
Еще один инструмент, который мы можем использовать для нагрузочного тестирования, - это Loadmill. Это бесплатный веб-инструмент. Он также включен в пакет npm (это на случай, если вдруг мы захотим написать код самостоятельно), но для демонстрационных целей мы будем использовать онлайн-инструмент.
Для того, чтобы провести нагрузочное тестирование с помощью Loadmill, все, что нам нужно сделать, это создать запрос в соответствующей панели и указать URL-адрес нашего приложения.
После чего мы должны нажать кнопку «Run Test» (Запустить тестирование) и настроить количество параллельных сеансов и продолжительность тестирования.
Вы заметите, что домен blank.org отображается красным. Это из-за того, что он считается непроверенным доменом. Не стоит забывать, что я не владею сайтом blank.org. По этой причине есть определенное максимальное пороговое значение нагрузки, которую мы можем направить на этот сайт.
Настроив такую конфигурацию, мы увидим, как себя поведет blank.org, когда в течение 2 минут приложением одновременно попытаются воспользоваться 5 пользователей.
В качестве результата мы можем увидеть производительность в динамике:
- у всех запросов среднее время отклика составило 55мс;
- наибольшая нагрузка была в начале, когда у 95% запросов время отклика было менее 1 059 мс, а у 50% запросов - менее 51 мс.
Это значит, что самое долгий ответ пользователь ожидал более 1 секунды.
Здесь же мы можем видеть частоту появления ошибок и пропускную способность в rps (запросы в секунду) наших сеансов. Это количество запросов, которые были отправлены нашими одновременно работающими пользователями за 1 секунду.
А теперь можете спросить себя, почему же такое большое расхождение между результатами тестирования с помощью первого инструмента и этого.
Здесь крайне важно обратить внимание на актуальность и точность данных. Вы должны оставаться реалистами и стараться, чтобы ваши тесты как можно точнее отражали реальность.
Когда речь заходит о тестировании производительности, то есть несколько стратегий. Некоторые инструменты и поставщики используют только локальную среду, тогда как другие для каждого параллельно работающего пользователя запускают виртуальные машины.
Loadmill выделяется среди других служб тем, что для того, чтобы создать нагрузку на тестируемый сервер, он использует реальный веб-трафик. То есть, трафик, который идет на целевой веб-сервер, исходит от реальных браузеров.
Пакет Loadtest тесно связан с локальным компьютером, на котором запускаются тестирования, и вы можете удаляться от него лишь настолько, насколько позволяет вам ваш ЦП.
Вы уже видели, что я запускал тестирование с помощью loadtest на своем компьютере с помощью командной строки. Время отклика было в 10 раз больше, чем при использовании Loadmill. Давайте разберемся почему так происходит.
Если мы откроем инструментальные средства разработки на blank.org, то найдем там его IP – 18.217.80.105. Выполним поиск и увидим, что сервер находится в Огайо, США.
Мы знаем, что время отклика – это время, которое прошло с момент отправки запроса и до момента получения ответа. Итак, запрос отправляется на сервер, а затем обратно с сервера к агенту (браузеру).
С помощью первого инструмента мы получили результат в 500мс, так как я отправляю запросы со своего компьютера. Получается, что запросы должны пробежать туда и обратно почти 11 000 миль.
Если мы перейдем ко второму инструменту и взглянем на его панель результатов PERFORMANCE/COUNTRY, то мы увидим, что все запросы были отправлены из США. Именно поэтому время отклика существенно меньше.
Не забывайте, что лучше всего моделировать условия, которые были бы максимально приближены к реальным, чтобы данные были как можно более точными.
Перед тем, как мы перейдем к следующему инструменту, я хочу отметить еще кое-что касательно Loadmill: его можно настроить для гораздо более масштабных целей, чем эта.
Мы можем создавать сложные сценарии нагрузочного тестирования с несколькими запросами, которые содержат параметры и данные, в том числе сценарии стандартной аутентификации и уведомлений по электронной почте.
Apache JMeter
Apache JMeter
Последний инструмент в нашем списке – Apache JMeter. Это Java-приложение с открытым исходным кодом, которое предназначено для тестирования производительности. Это приложение необходимо устанавливать, и в настройке он не такой уж простой. Поэтому всю дальнейшую информацию мы поделили на отдельные шаги.
Шаг 1 – Загрузите и установите
Загрузите архив с бинарными файлами на свой компьютер и распакуйте его.
Затем перейдите в папку bin и запустите файл jmeter.bat два раза. Один раз, чтобы настроить инструмент, и второй раз, чтобы его запустить.
Шаг 2 – Добавьте группу потоков (Thread group)
У Thread Group есть три самых важных свойства, которые влияют на нагрузочное тестирование:
- Количество потоков (пользователей) (Number of threads (users)): количество параллельных сеансов, которые создаст JMeter.
- Период увеличения нагрузки (Ramp-up period): продолжительность теста.
- Счетчик циклов (Loop count): сколько раз необходимо выполнить тест.
Шаг 3 – Добавьте набор образцов HTTP-запросов
В шаблоне HTTP-запроса, под названием раздела HTTP Request, заполните поля Server Name (имя сервера), Protocol (протокол) и Path (путь) для приложения, которое вы хотите протестировать.
Шаг 4 – Добавьте просмотр результатов
В JMeter для вывода результатов тестирования производительности используются компоненты listener. У них есть много разновидностей, но вы можете также добавить какие-то другие с помощью плагинов. В нашем случае мы будем использовать таблицу (Table).
Шаг 5 – Запустите тестирование
Нажмите на зеленый треугольник и запустите тестирование.
Теперь мы можем проанализировать наш тест.
Прежде всего, в правом верхнем углу мы можем видеть, что тест выполнялся в течение 10 секунд. Именно так мы указали в параметрах.
Далее больше всего нас интересуют столбцы Status (Статус) и Latency (Задержка/время отклика).
- Latency: количество миллисекунд, которое прошло с момент отправки запроса и до момента получения ответа.
- Status: отображает статус запроса, успешно он был выполнен или нет. Он используется для расчета частоты повторения ошибок.
Попутно хочу заметить, что значения практически такие же, как и значения, которые мы получили с помощью нагрузочного тестирования. Это потому, что они работают одинаково.
Остальные показатели
С помощью этих инструментов мы смогли получить информацию практически по всем показателям, которые упоминали в начале.
А если мы хотим получить информацию об использовании памяти/ЦП, нам нужно подключиться к компьютеру, на котором находится наше приложение, и выполнить следующие команды:
$ top
Эта команда продемонстрируем вам как процент загрузки ЦП, так и использование памяти.
или
$ free -h
Эта команда продемонстрирует вам только информацию касательно памяти, но ее вывод более удобный для восприятия.
Заключение
Существует большое количество инструментов, которые можно использовать для тестирования производительности. Очень важно найти тот, который вам будет легко использовать, но при этом он должен показывать как можно более точные данные. И помните, что ваши тесты всегда должны моделировать условия, которые максимально приближены к реальным.
