Как проводить нагрузочное тестирование web приложений

Обновлено: 07.01.2025

Нагрузочное тестирование позволяет оценить производительность программного обеспечения при различных нагрузках от действий определенного количества пользователей. Бизнесу всегда важно знать производительность программного обеспечения в реальных условиях, выявить основные уязвимости и обеспечить высокое качество ПО. Нагрузочное тестирование позволяет снизить риск сбоя после запуска приложения в реальных условиях. Однако, если Вы хотите эффективно выполнить нагрузочное тестирование, Вам понадобятся инструменты тестирования эффективности нагрузки, которые помогут смоделировать виртуальных пользователей и выполнять тестовые сценарии.

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

Инструменты

Apache JMeter

Apache JMeter – на настоящий момент один из самых популярных инструментов с открытым исходным кодом для нагрузочного тестирования. Инструмент разрабатывается с 2003 года и за прошедшие десятилетия оброс богатой функциональностью и достаточно давно успел себя зарекомендовать, как прекрасную альтернативу платным аналогам для большинства решаемых задач.

Инструмент кроссплатформенный, так как разработан на Java. Доступна как работа из GUI, так и запуски в консольном режиме.

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

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

Плюсы

• Удобный интерфейс
• Анализ результатов и кэширование
• Базовую поставку легко расширить с помощью многочисленных плагинов
• 100% на языке Java
• Скрипт графически разделён на блоки-сэмплеры, что упрощает его разработку
• Удобная работа с многопоточностью
• Анализ и визуализация данных
• Динамический ввод

Минусы

• Не поддерживает JavaScript
• Есть предел использования памяти, после которого появляются ошибки у большого числа пользователей
• Иногда бывает трудно протестировать сложные приложения с использованием JavaScript или динамического контента, такого как CSRF токены

Протоколы

Ценообразование

• Бесплатное приложение с открытым исходным кодом

Кому подходит

LoadRunner

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

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

Плюсы

• Четкое обнаружение проблемных мест на уровне системы, конечного пользователя и кода
• Обнаруживает первопричину проблем производительности приложений
• Сокращает затраты на время простоя приложений, вызванного проблемами с производительностью
• Позволяет проводить тестирование производительности существующих устаревших приложений
• Позволяет тестировать мобильные приложения
• Снижение затрат на программное и аппаратное обеспечение за счет прогнозирования производительности и масштабируемости ПО
• Позволяет командам разработчиков программного обеспечения настраивать интеллектуальные соглашения об уровне услуг до запуска их продукта в эксплуатацию
• Сокращает циклы тестирования для ускорения доставки приложений пользователям?
• Обеспечивает эффективное отслеживание использования инструмента
• Браузерный интерфейс для доступа к распределённым тестовым ресурсам
• Оптимальное использование генераторов нагрузки

Минусы

• Очень дорогой
• Использует много памяти и аварийно завершает работу, если система не отвечает своим вычислительным требованиям
• Стоимость лицензии на использование зависит от количества виртуальных пользователей

Ценообразование

• Community Edition / Можно получить лицензии на 50 виртуальных пользователей бессрочно / Бесплатно
• Дни виртуальных пользователей / Дает вам возможность добавить больше виртуальных пользователей| начинается с $1,40 за день виртуального пользователя
• Объемное ценообразование| Можно связаться с поставщиком для получения ценового предложения

Протоколы

• Loadrunner поддерживает все виды протоколов, связанных с его услугами

Кому подходит

Load Ninja

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

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

Плюсы

• Используется из облака
• Все те действия, которые реальный пользователь производит в браузере, теперь выполняют сотни и тысячи виртуальных пользователей
• Vu Debugger отладочные тесты в режиме реального времени
• Vu Inspector управляет активностью виртуальных пользователей в режиме реального времени
• Браузерные метрики с функциями аналитики и отчетности
• Создание и проведение нагрузочного теста без написания скриптов

Минусы

• Полностью зависит от AJAX, который в свою очередь полагается на JavaScript; таким образом, LoadNinja не работает, если JavaScript отключен или не поддерживается
• Динамически отображаемые и загружаемые данные не являются частью страницы приложения
• Асинхронные свойства Ajax вызывают задержки
• Дороговизна

Протоколы

Ценообразование

• Есть бесплатная демонстрация
• Базовый (годовой) | $1,799 / 1000 пользователей / 100 часов / Продолжительность: 1 час
• Базовый (годовой) | $2,999 / 1000 пользователей / 2500 часов / Продолжительность: 1 час

Кому подходит

WebLOAD

Плюсы

• Мощное средство для автоматической корреляции
• Создание нагрузки на рабочих машинах или в облаке
• Поддерживает все основные веб-технологии
• Автоматическое обнаружение узких мест
• Гибкое создание тестового сценария

Минусы

• Сложный
• По отзывам некоторых пользователей, относительно дорогой

Протоколы

Ценообразование

• Бесплатная пробная версия
• По тарифному плану

Кому подходит

LoadUI Pro

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

LoadUI Pro также позволяет пользователям запускать несколько сценариев нагрузочного тестирования одновременно. Это позволяет пользователям оценить, как различные условия тестирования взаимодействуют друг с другом и влияют на производительность API.

Плюсы

• Нагрузочные тесты API в облаке
• Можно использовать повторно существующие функциональные тесты
• Параллельное нагрузочное тестирование API
• Изоляционное нагрузочное тестирование
• Мониторинг сервера для диагностики на предмет ресурсов, которые вызывают задержки и снижают производительность

Минусы

• Дорогой
• Оптимизирован только для тестирования API и микросервисов

Протоколы

Ценообразование

Кому подходит

LoadUI Pro отлично подходит для разработчиков ПО и ИТ-специалистов. LoadUI Pro предлагает облачное и локальное программное обеспечение API. Вы можете использовать этот инструмент автоматизации нагрузочного тестирования для создания, управления и выполнения нагрузочных тестов баз данных, микросервисов и API REST & SOAP.

BlazeMeter

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

Плюсы

Минусы

• Отчеты Blazemeter довольно простые и не детализированные
• Blazemeter дорог для нагрузочных тестов больше чем с 1000 пользователей.

Ценообразование (годовые планы)

• Бесплатно (50 одновременных пользователей)
• Базовый: $ 99 / мес (1000 одновременных пользователей)
• Pro: $ 499 / мес (5000 одновременных пользователей)

Кому подходит

K6

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

K6 написан разработчиками другого нагрузочного инструмента – loadimpact и служит прежде всего для проверки производительности сайтов. Backend инструмента написан на языке Go, а сами скрипты пишутся на JavaScript.

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

Запуск тестов происходит в консольном режиме, результаты тестирования по умолчанию также выводятся в консоль, однако доступна поддержка таких плагинов для вывода результатов, как Kafka, Datadog, InfluxDB, JSON и StatsD.

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

Плюсы

• доступна интеграция с CI-инструментами;
• возможность создания кастомных метрик;
• ориентирован на разработчиков согласно концепции «everything is code»;

Минусы

• нет возможности распределенного запуска;
• поддерживает только тестирование веб-сайтов;
• соединения websocket иногда зависают;
• нет поддержки языка Go;
• ориентирован на разработчиков.

Ценообразование

• Open source версия бесплатна (мы не говорим про стоимость инфраструктуры);
• Облачная версия имеет кастомное ценообразование, прайсы в открытом доступе отсутствуют.

Протоколы

Кому подходит

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

Яндекс.Танк

Не секрет, что в компании Яндекс имеется своя экосистема различных инструментов для абсолютно разных задач. Некоторые говорят, что если есть возможность написать свой инструмент, то Яндекс обязательно это сделает (иногда без оглядки на уже имеющиеся решения). Не обошла стороной эта тема и инструменты для нагрузочного тестирования.

Кроме того, можно использовать BFG-Python-генератор и написанный на Go Pandora.

Сам Танк реализован на Python и может использоваться только в Unix-системах.

Плюсы

• функция автоматической остановки теста;
• встроенный мониторинг серверов по ssh-протоколу;
• открытая конфигурация для создания собственных модулей;
• доступна интеграция с Graphite.

Минусы

• нет кроссплатформенности;
• порог вхождения выше среднего, так как требуется разбираться и настраивать множество различных модулей.

Ценообразование

• инструмент бесплатно распространяется по лицензии LGPL

Протоколы

• Зависят от используемого генератора нагрузки.

Кому подходит

Яндекс.Танк хорошо подходит в сочетании с phantom, если отсутствует необходимость в сценарном тестировании и требуется высокая производительность.

Gatling

Gatling – это ещё один популярный инструмент для проведения нагрузочного тестирования с открытым исходным кодом. Он написан на языке Scala с использованием технологий Netty и Akka.

Если Вы – разработчик, знакомый со Scala и Вам нужно провести нагрузочное тестирование, то Gatling – идеально вам подойдёт.

Скрипты на gatling пишутся в привычной среде разработки, и поддерживают инструменты автоматизации сборки sbt и maven. Также реализована возможность встраивания в процессы непрерывной интеграции с помощью Jenkins.

Удобство gatling для разработчика также состоит в том, что по завершении тестирования отчёт создаётся автоматически, его остаётся только проанализировать.

Плюсы

• при высоких нагрузках может быть более производительным, чем другие бесплатные инструменты, особенно при тестировании вебсокетов;
• подойдёт, если вы разрабатываете на Scala;
• имеются официальные и неофициальные плагины для тестирования Kafka, RabbitMQ, JDBC и др.

Минусы

• проще создавать скрипт вручную, чем пользоваться имеющимся рекордером;
• отсутствие распределённого запуска из коробки;
• если у вас нет опыта работы со Scala, порог вхождения для полноценного использования gatling будет выше, чем для других инструментов нагрузочного тестирования.

Протоколы

Ценообразование

• Бесплатное приложение с открытым исходным кодом
• Имеется Enterprise-версия с расширенной функциональностью

Кому подходит

Boomq.io

Для маркетологов boomq.io предоставляет простой в использовании инструмент, который интегрируется с Google Analytics и Яндекс.Метрикой для получения статистической информации и выполнения тестов производительности без какого-либо программирования или других технических разработок.

Разработчики и инженеры могут использовать boomq.io для удобного проведения тестов производительности в облаке. У них появляется полный набор инструментов тестирования (работающих в облаке в качестве службы SaaS), таких как импорт HAR/Insomnia, определение запросов, параметризация и корреляция.

У boomq.io есть удобный анализ результатов повторяющихся онлайн тестов с помощью графических панелей. В целом, boomq.io представляет новое поколение продуктов для тестирования производительности, которое позволяет легко создавать, планировать, запускать и выполнять тесты в облаке, используя простой и понятный веб-интерфейс.

Плюсы

• Удобный и понятный веб интерфейс
• Простота использования
• Интеграция с Google Analytics и Яндекс Метрикой
• Импорт из HAR и Insomnia
• Облачное развертывание

Минусы

Протоколы

Ценообразование

Кому подходит

Вывод

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

На сегодняшнем стендапе Марек (программист из Польши принимающий участие в проекте EmForge) сказал, что общался с рядом друзей, у которых в прошлом был большой опыт работы с Liferay (который мы как раз активно используем) — и опыт оказался очень негативный, в первую очередь из-за проблем со скоростью. Некоторые проекты тупо накрылись из-за того что эти проблемы так и не получилось решить.

Не «по-быстренькому»

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

Вообщем задача не на один час

А по-быстренькому?

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

Совсем по-быстренькому?

Если совсем по-быстрому — то это Load Impact — не надо никаких регистраций — заходите — даете URL — и в течении 10-15 минут 50 виртуальных пользователей терроризируют вашу страницу. Тупо, просто — но по крайней мере позволит увидеть что при первом же наплыве ваше приложение не ляжет. Не легло? Идем дальше

Нагрузочное тестирование за 1.5 часа

Мне очень понравился LoadStorm. С ним работа строится следующим образом:
1. регистрируемся
2. Создаем тест — в котором указывает сайт который будем пытать
3. Прежде чем начать пытку- требуется верификация (а вдруг вы хотите положить сайт конкурента. ). надо на главную страницу положить определенный текст с кодом — или файл с определенным именем в корень
4. Дальше создаем сценарий — при создании сценария описываем, как пользователь идет по вашему сайту, какие линки нажимает, можно засабмитить формы. Все достаточно интуитивно и понятно
5. потом говорим когда запустить
6. в назначенное время тест запускается, ждем 30 минут пока до 50-ти пользователей бродят по вашему сайту согласно вашим указаниям — и получаем отчет.

Вообщем на описание сценария из 15 последовательных страниц, ожидание запуска теста и ожидание самих результатов ушло порядка полутора часов, в результате я получил графики типа

На этом графике показывается как терзалась система — в моем случае максимально было 47 пользователей — и чуть более 3-ех запросов в секунду
Ну и самый интересный

Из которого следует — что если исключить максимальный пик в 5 секунд (в этот момент решил включиться Garbage Collector) — в остальном приложение вело себя хорошо — и не зависимо от количества пользователей — то есть — нагрузка в 50 пользователей сайт не нагружает — есть еще и запас хороший.

Понятно — что такое тестирование не совсем «серьезное» по выдаваемым результатам, да и 50 одновременных пользователей — нельзя назвать серьезной нагрузкой, но, учитывая потраченное время (полтора часа) и деньги (0 руб) — результат вполне адекватный. По крайней мере мы убедились что если с производительностью есть какие-то проблемы — в ближайшие месяцы мы ее все-таки не увидим

Чуть подлинней и подороже

Если хочется чуть более серьезного — можно попробовать BrowseMob — сам их не пробовал — отличие в том, что у них, вместе с виртуальными пользователями ваш сайт мучают реальные — но это и стоит дороже. В любом случае гляньте — может пригодится

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

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

Основные понятия

Для начала нужно ознакомиться с базовыми терминами и понятиями.

• Задержка – это показатель того, насколько быстро сервер реагирует на запросы клиента. Обычно измеряется в миллисекундах (мс). Задержка также часто называется временем отклика. Чем ниже этот показатель, тем быстрее сервер обрабатывает запрос. Задержка измеряется на стороне клиента с момента отправки запроса до получения ответа. В этот показатель включены затраты сетевых ресурсов.
• Пропускная способность – это количество запросов, которые сервер может обрабатывать в течение определенного промежутка времени. Обычно этот показатель измеряется в запросах в секунду.
• Процентиль – это способ группировки результатов по проценту от всего набора данных.

Основы нагрузочного тестирования

• Достаточно ли у сервера ресурсов (памяти, CPU и т. п.), чтобы обработать ожидаемый трафик?
• Достаточно ли быстро реагирует сервер, чтобы обеспечить хороший пользовательский опыт?
• Эффективно ли работает приложение?
• Нужно ли серверу вертикальное или горизонтальное масштабирование?
• Есть ли особо ресурсозатратные страницы или вызовы API?

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

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

Как определить разумный показатель задержки?

Время загрузки веб-сайта в диапазоне 2-5 секунд – обычное дело, но часть времени, связанная с задержкой веб-сервера, обычно составляет около 50-200 миллисекунд. Идеальный показатель задержки индивидуален для каждого сайта. Он зависит от большого количества факторов (аудитории, рынка, целей сайта, наличия пользовательского интерфейса или API и т. д.). Имейте в виду: большинство исследований показывают, что в производительности учитывается каждый маленький бит скорости, и даже совсем незаметные улучшения приводят к улучшению результатов в целом.

Планирование нагрузочного тестирования

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

1: Мониторинг ресурсов

Программное обеспечение для нагрузочного тестирования соберет и предоставит информацию о запросах и задержках. Но есть и некоторые другие системные показатели, которые нужно отслеживать, чтобы понять, каких ресурсов не хватает серверу при работе с большими объемами трафика.

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

Если у вас уже есть система мониторинга типа Prometheus, Graphite или CollectD, вы сможете собрать все необходимые данные.

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

Для мониторинга доступной памяти используйте команду free. В комбинации с командой watch данные будут обновляться каждые 2 секунды.

Флаг -h выводит числа в удобочитаемом формате.

total used free shared buffers cached
Mem: 489M 261M 228M 352K 7.5M 213M
-/+ buffers/cache: 39M 450M
Swap: 0B 0B 0B

Выделенное число в выводе представляет свободную память после вычитания буфера и кэша. Новые версии free выводят другие результаты:

. total used free shared buff/cache available
Mem: 488M 182M 34M 14M 271M 260M
Swap: 0B 0B 0B

Новый столбец available вычисляется по-разному, но обычно представляет одну и ту же метрику: текущий объем доступной памяти для приложений.

Для мониторинга использования CPU в командной строке есть утилита mpstat, которая выводит количество свободных ресурсов CPU. По умолчанию утилита mpstat не установлена в Ubuntu. Вы можете установить ее с помощью следующей команды:

sudo apt-get install sysstat

При запуске mpstat нужно задать интервал обновления данных в секундах:

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

Linux 4.4.0-66-generic (example-server) 08/21/2017 _x86_64_ (4 CPU)
08:06:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
08:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

Столбец %idle показывает, какой процент ресурсов ЦП не используется. Загрузка процессора часто разделяется на разные категории (user CPU и system CPU).

2: Определение максимальной скорости отклика

Как говорилось ранее, большинство программ нагрузочного тестирования особенно хорошо подходят для поиска максимальной скорости ответа веб-сервера. Как правило, при этом нужно указать только конкурентность и продолжительность тестирования.

Конкурентность – это показатель, который отображает количество параллельных подключений, которое может обрабатывать сервер. Значение по умолчанию 100 подходит в большинстве случаев, но вы можете выбрать индивидуальное значение. Для этого нужно проверить MaxClients, MaxThreads сервера и другие подобные параметры.

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

Некоторое программное обеспечение для нагрузочного тестирования позволяет сразу указать несколько URL-адресов, которые нужно проверить. Это позволяет более точно имитировать реальный трафик. Если у вас есть данные об использовании сайта (из аналитического программного обеспечения или логов сервера), вы можете применить эти данные в тестировании.

Отобрав URL-адреса, запустите тестирование. Убедитесь, что программное обеспечение очень быстро отправляет запросы. Если программное обеспечение разрешает выбрать скорость запроса, выберите значение, которое почти наверняка будет слишком высоким для вашего сервера. Если программное позволяет установить задержку между запросами, уменьшите это значение до нуля.

Использование ресурсов процессора и памяти будет увеличиваться. Свободные ресурсы процессора могут достигать 0%, и клиент может получить ошибку соединения. Это нормально, поскольку сервер работает на пределе возможностей.

Когда тестирование закончится, программное обеспечение выведет статистические данные, включая количество запросов в секунду. Обратите внимание на время отклика: этот показатель, вероятно, будет очень плохим, так как сервер должен быть чрезвычайно перегружен во время теста. Поэтому количество запросов в секунду не является точным показателем максимальной пропускной способности сервера, но это хорошее начало для дальнейшего исследования.

Затем нужно повторить тестирование, чтобы получить дополнительную информацию о том, как работает сервер на пределе ресурсов.

3: Определение максимальной пропускной способности

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

Здесь можно обратиться к инструменту wrk2, который позволяет указывать точное количество запросов в секунду.

Возьмите максимальную скорость запросов, которую вы определили на предыдущем этапе, и разделите ее на 2. Запустите еще один тест с новыми данными и обратите внимание на время ответа. Находится ли показатель в приемлемом диапазоне?

Если да, увеличьте значение до максимума и повторите тестирование, пока задержка не достигнет максимального значения, которое вы считаете приемлемым. Это и будет фактическая максимальная скорость ответа, которую может обрабатывать ваш сервер.

Инструменты для нагрузочного тестирования

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

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

Инструмент ab

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

Базовый вызов команды ab выглядит следующим образом:

Флаг –n задает количество запросов. Флаг –с задает конкурентность. Затем нужно указать URL, который нужно протестировать. Вывод (выдержка из которого приведена ниже) указывает количество запросов в секунду, время запроса и список процентилей времени ответа:

JMeter

JMeter – это мощное и многофункциональное приложение для нагрузочного и функционального тестирования от Apache Software Foundation. Функциональное тестирование – это проверка вывода приложения.

JMeter предлагает графический интерфейс Java для настройки тестовых планов.

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

JMeter может выводить информацию о процентилях в отчетах HTML и других форматах.

Siege

Siege – еще один инструмент командной строки для нагрузочного тестирования. Он похож на ab, но имеет несколько дополнительных функций. Siege – многопоточный инструмент, что обеспечивает относительно высокую пропускную способность. Он также позволяет указать сразу несколько URL-адресов для нагрузочного тестирования. Базовый вызов выглядит так:

Флаг –с указывает конкурентность. Флаг -t определяет продолжительность тестирования (в данном случае – 30 секунд). Siege выводит среднее время отклика и скорость запроса:

. . .
Transactions: 5810 hits
Availability: 100.00 %
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Response time: 0.01 secs

Transaction rate: 197.15 trans/sec
Throughput: 4.59 MB/sec
Concurrency: 2.23
. . .

Siege не предоставляет процентилей для статистики задержек.

Locust

Locust – это инструмент для нагрузочного тестирования на основе Python, который предоставляет веб-интерфейс для мониторинга результатов в реальном времени.

Сценарии тестирования Locust пишутся с помощью кода Python, что предоставляет дополнительные преимущества тем, кто хорошо знаком с этим языком программирования.

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

Locust может предоставить подробную статистику в CSV-файлах, которые можно загрузить.

Инструмент wrk2

wrk2 – это многопоточный инструмент командной строки для нагрузочного тестирования, способный производить нагрузку с заданной частотой запросов. Он может предоставлять подробную статистику задержек и поддерживает сценарии на языке программирования Lua.

wrk2 вызывается командой wrk:

. . .
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .

Заключение

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

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

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

Обсудим, как написать план такого тестирования. Нужно рассмотреть следующие моменты.

Какой результат ожидается от нагрузочного тестирования?

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

Что нужно уяснить во время нагрузочного тестирования:

1. Какой элемент приложения будет “стопорящим” (так называемый bottleneck), когда резко возрастет количество пользователей?
2. Корректно ли масштабируется приложение под большой нагрузкой?
3. Корректно ли ведет себя приложение во время тестирования в условиях, имитирующих реальную нагрузку?
4. Сколько пользователей одновременно может работать с приложением в “пиковых” условиях?
5. Как время ответа (response time) изменяется в ответ на рост числа пользователей?
6. Как можно оптимизировать производительность приложения?

Как мы будем тестировать приложение?

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

Будем тестировать приложение в двух условиях нагрузки.

При реалистичной нагрузке

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

При пиковой нагрузке

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

Сбор начальных данных для сценариев

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

Какое максимальное количество одновременных пользователей ожидается?

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

Количество одновременных пользователей = (количество пользователей за 2 часа) * среднее время проведенное на странице, в секундах / 3600 секунд / 2 часа = ?

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

В нашем случае, у нас было 20 тысяч сессий, а среднее время проведенное на странице составило 2 минуты. В итоге получилось 333 одновременных пользователя.

Всего сессий за 2 часа = 20 000 сессий

Среднее время проведенное на странице = 120 секунд

Одновременных пользователей = 333 пользователя

Какие части веб-приложения нагружаются больше всего?

Это важно знать, чтобы сбалансировать части приложения, базируясь на реалистичных ожиданиях.

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

Анализ может выглядеть примерно так (сайт магазина):

Проверяем пределы выносливости приложения

Теперь нужно знать предел, на котором приложение перестает отвечать на тестовые запросы.

1. Сколько времени приложению нужно, чтобы обработать запрос?
2. Какой ответ считается успешным?

Эти пределы должны быть испытаны в тестовом наборе.

Создание тестовых сценариев

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

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

Выполнение тестов

После создания плана, и написания скриптов, выполняем тесты.

При этом надо учесть следующее:

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

• Наладить мониторинг в реальном времени, чтобы сразу видеть последствия нагрузки; как высокий трафик влияет на веб-приложение и другие части сервера.

• Тестировать приложение в продакшн-среде, или среде, сопоставимой по мощности.

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

Разбор результатов

Все это выглядит примерно так:

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

Все идет по плану

Прежде чем бросаться в бой, вначале следует разобраться, что мы хотим
получить в результате тестирования. Ведь проверка, как и любая другая работа,
требует предварительной подготовки. При неправильно сформулированной задаче
могут получиться результаты, которые будут не полностью отражать реальное
положение дел. Исходя из предполагаемой нагрузки веб-сервера, необходимо
определиться с критериями испытания. Установить, что будет считаться как успех,
а что как неприемлемая работа сервиса (например, время ответа, загрузка
сервера). Различают три варианта теста:

• Нагрузочный (Load-testing) – определяется работоспособность системы
  при некоторой строго заданной заранее (планируемой, рабочей) нагрузке.
• Устойчивости (Stress) – применяется для проверки параметров системы
  в анормальных и экстремальных условиях, основная задача во время этого теста -
  попытаться нарушить работу системы. Позволяет определить минимально
  необходимые величины системных ресурсов для работы приложения, оценить
  предельные возможности системы и факторы, ограничивающие эти возможности.
  Также определяется способность системы к сохранению целостности данных при
  возникновении внештатных аварийных ситуаций.
• Производительности (Performance) – комплексная проверка, включающая
  предыдущие два теста, предназначена для оценки всех показателей системы.

Во время тестирования имитируется одновременная работа нескольких сотен
или тысяч посетителей. Для большей правдивости каждый из виртуальных
пользователей может «ходить» по сайту по индивидуальному сценарию и иметь личные
параметры. Также в процессе тестирования можно имитировать кратковременные пики
нагрузки, когда количество посетителей скачкообразно увеличивается, что очень
актуально для сайтов с неравномерной аудиторией. Итак, чтобы полноценно провести
тестирование, необходимо знать:

Любой из этих параметров может повлиять на конечный результат. Необязательно
все проверки включать в один тест, можно разбить сначала задачу на подзадачи.
Например, проверка базовой системы (серверы: веб, приложений, базы данных) и
проверка отдельных модулей (сервлеты, скрипты и пр., например, проверка
аутентификации при большом количестве пользователей). В результате при
тестировании выдаются графики трех видов: линейный, нелинейный и насыщение. В
первом случае при возрастании нагрузки время отклика (т.е. обработки) остается
постоянным. При дальнейшем увеличении нагрузки время отклика также увеличивается
(почти линейно), и, наконец, наступает ситуация, подобная DOS-атаке, когда время
отклика бесконечно увеличивается. Теперь, когда план действий готов, переходим к
краткому обзору утилит, которые помогут его воплотить. Начнем с бесплатных.

Open Systems Testing Architecture

Apache JMeter

В JMeter предусмотрены механизмы авторизации виртуальных
пользователей, поддерживаются пользовательские сеансы, шаблоны, кэширование и
последующий offline анализ результатов теста, функции позволяют сформировать
следующий запрос, основываясь на ответе сервера на предыдущий. Есть возможность
проводить распределенные тесты. В этом случае один из компьютеров является
сервером (bin/jmeter-server.bat), который управляет клиентами и собирает
итоговую информацию.

Для работы достаточно запустить ApacheJMeter.jar или в консоли jmeter.bat
(Windows) или jmeter.sh (*nix).

JMeter имеет встроенный прокси-сервер, который предназначен для записи
сессий, но можно использовать и внешний. Перед началом тестирования необходимо
составить тестовый план, описывающий серию заданий, которые необходимо выполнить
JMeter. Он должен содержать одну или несколько групп потоков (Thread
Groups) и другие элементы:

• Логические контроллеры (Logic controllers);
• Типовые контроллеры (Sample generating controllers);
• Слушатели (Listeners);
• Таймеры (Timers);
• Соответствия (Assertions);
• Конфигурационные элементы (Configuration elements).

Бесплатные продукты, увы, закончились, теперь парочка коммерческих решений.

WAPT – Web Application Testing

После нажатия на кнопку Готово сценарий сохраняется. Теперь, чтобы указать на
объект тестирования, создаем профиль New – Profile и заполняем все параметры на
вкладках. Здесь же доступны для редактирования некоторые параметры, задаваемые
раннее с помощью мастера. Также указывается загрузка рисунков виртуальным
пользователем, параметры аутентификации, использование Cookies и другие.
На вкладке Recorder указываем адрес сайта, доступность которого можно тут же
проверить, нажав Go. Одновременно последует запрос на запуск Recorder, который
будет отслеживать посещенные страницы и записывать URI (они будут выводиться в
панели слева). Когда вся информация собрана, нажимаем Run Test. Подробные отчеты
в форме графика выводятся по ходу проведения теста, по окончании будет
сформирована HTML-страница. В результате можно получить информацию о времени
ответа сервера с возрастанием нагрузки, по количеству ошибок, переданных и
принятых байт и т.д.

NeoLoad

При помощи NeoLoad можно проводить и распределенные тесты. Один из
компьютеров является контролером, на остальные устанавливаются генераторы
нагрузки (loadGenerator). Контролер распределяет нагрузку между loadGenerator и
собирает статистику.

Сценарий будущего теста создать очень просто. Запускаем приложение (при
первом запуске потребуется ввести регистрационный ключ, 30-дневная версия после
регистрации будет отправлена по почте), выбираем New Project, вводим название
проекта. После этого будет показана небольшая подсказка по поводу дальнейших
действий, нажатие Start Recording запустит веб-браузер, все перемещения будут
записаны. По окончании нажимаем Stop Recording или закрываем браузер.
Запускается мастер, который поможет создать виртуальных пользователей и
произведет автоматический поиск динамических параметров в записанных страницах,
выставит среднее значение thinktime. Компоненты страницы (HTML, images, CSS)
сохраняются отдельно. Для получения результата требуется пройти три шага:

• Design - настройка проекта, здесь три вкладки. В Repository указываются
  веб-страницы и параметры запросов, в Virtual User создаются виртуальные
  пользователи, указываются URL, которые они должны "посетить", и дополнительные
  условия из левой вкладки поля Actions. В Populations – задания каждой из групп
  пользователей. В Actions могут быть выбраны следующие действия: Delay
  (установка задержки), Loop (повтор запроса), While (цикл), If. Then. Else
  (условие), Container и Random Container (групповые действия), Try. Catch
  (обработка ошибок), Stop virtual user (останов работы виртуального
  пользователя).
• Runtime – указываются параметры теста, проводится тест. Здесь же в
  отдельных вкладках по ходу проведения теста выводится статистика.
• Results – отвечает за вывод различной статистики в виде таблиц и графиков.

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

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

Продукты от Microsoft

Читайте также:

  
• Не работает бкс брокер приложение
  
• Как подарить приложение в google play
  
• Как скачать приложение томская электронная школа
  
• Как привязать карту сбербанка к халве в приложении пошаговая инструкция
  
• Как пользоваться приложением pocket