Нагрузочное тестирование (англ. load testing ) - подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).

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

Нагрузочное тестирование программного обеспечения

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

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

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

Одним из оптимальных подходов в использовании нагрузочного тестирования для измерений производительности системы является тестирование на стадии ранней разработки. Нагрузочное тестирование на первых стадиях готовности архитектурного решения с целью определить его состоятельность называется "proof-of-concept" тестированием.

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

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

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

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

В общем случае время отклика системы подчиняется функции нормального распределения .

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

Основные показатели (метрики) производительности

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

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

Метрика, показывающая количество памяти, использованной приложением. Использованная память делится на несколько категорий:

• Virtual - объём виртуального адресного пространства, которое использует процесс. Этот объём подразумевает, как использование соответствующего дискового пространства так и оперативной памяти. Система виртуальной памяти гарантирует, что потоки одного процесса не получат доступа к памяти принадлежащей другому процессу.
• Private - объём адресного пространства, занятого процессом и не разделяемого с другими процессами.
• Working Set - набор страниц памяти, недавно использованных процессом. В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае, когда свободной памяти остаётся мало, использованные страницы перемещаются из ОЗУ на жёсткий диск (или другой накопитель, такой как Флеш-память), освобождая ОЗУ для загрузки других активных страниц памяти.
• Shared - объём используемой процессом физической памяти, которая может использоваться совместно с другими процессами. Хотя память выделенная процессу должна быть изолированной, процессам, иногда, необходимо иметь возможность обмениваться информацией. Общая память является самым быстрым способом межпроцессного взаимодействия .

При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым сборщиком мусора . Время затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в Java - так называемый «постоянный Full GC») или когда процессу выделены большие объёмы памяти, нуждающиеся в очистке. На время, требующееся для очистки памяти, доступ процесса к страницам выделенной памяти может быть заблокирован, что может повлиять на конечное время обработки этим процессом данных.

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

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

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

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

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

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

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

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

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

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

Нагрузочное тестирование – это технология измерения производительности сервера, которая заключается в отправке имитируемого HTTP-трафика на сервер. Это позволяет найти ответы на такие вопросы:

• Достаточно ли у сервера ресурсов (памяти, 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

(или ApacheBench) – это простой однопоточный инструмент командной строки для тестирования HTTP-серверов. Изначально он разрабатывался как часть HTTP-сервера Apache, но его можно использовать для тестирования любого HTTP- или HTTPS-сервера.

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

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

ab -n 1000 -c 100 http://example.com/

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

. . .
Requests per second: 734.76 [#/sec] (mean)

Time per request: 136.098 (mean)
Time per request: 1.361 (mean, across all concurrent requests)
Transfer rate: 60645.11 received
Percentage of the requests served within a certain time (ms)
50% 133

66% 135

75% 137

80% 139

90% 145

95% 149

98% 150

99% 151

100% 189 (longest request)

JMeter

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

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

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

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

Siege

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

siege -c 100 -t 30s http://example.com/

Флаг –с указывает конкурентность. Флаг -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:

wrk -t4 -c100 -d30s -R100 --latency http://example.com/

Параметр -t определяет количество потоков (в данном случае их 4, здесь нужно использовать количество процессорных ядер вашего сервера). Параметр -c указывает количество одновременных запросов (здесь 100). Флаг –d определяет продолжительность тестирования (30 секунд). Флаг –R указывает частоту запросов в секунду (100). Подробный вывод задержки предоставит флаг —latency.

. . .
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
. . .

Заключение

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

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

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

Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, пока не будет достигнут один из критериев его остановки. Например, стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S).

На втором этапе проводится нагрузочный тест (Load Test) , с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте. Уровень нагрузки при тестировании банковской системы поддерживался на одном уровне в течение восьми часов и составил 1200 пользователей. Нагрузочный тест показал существенное ухудшение производительности системы с течением времени, а дополнительное профилирование ее компонентов позволило обнаружить дефекты, проявляющиеся только при длительной работе большого количества пользователей (например, утечки памяти).

Как правильно подавать нагрузку на систему?

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

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

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

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

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

По желанию заказчика возможно проведение дополнительных видов тестов.

Дополнительные виды тестов производительности

Задачей объемного теста (Volume Test) является оценка производительности системы при увеличении объемов данных, хранимых в базе данных приложения. Схема подачи нагрузки при данном виде теста такая же, как и при нагрузочном. Для проведения теста требуется база данных, заполненная необходимым объемом данных. Так, при тестировании биллинговой системы для оператора мобильной связи, объем данных был выбран исходя из ее прогнозируемого наполнения через два года после выхода обновленной версии системы в производство.

Тест на стабильность (Stability Test) позволяет оценить работоспособность системы при длительной ожидаемой нагрузке в режиме работы 24/7. К примеру, если веб-сайт посещают пользователи, находящиеся в разных часовых поясах, уровень нагрузки может сохраняться постоянным. Помимо возможных перезапусков серверов системы под продолжительной нагрузкой, при тесте на отказоустойчивость также изучается влияние редких событий на деградацию производительности системы, например, работа сборщиков мусора.

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

Тестирование клиентской части vs . тестирование производительности

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

Наилучшим решением проблем со стабильностью и сбоями в работе веб-серверов является обеспечение двухуровневой архитектуры приложения: клиентской, или Front - end , части и серверной, или Back - end , части.

Пользователь открывает браузер и отправляет запрос к странице сайта на Front - end сервер. Запрос принимается и запрашивается у исполнительной части веб-приложения – Back - end сервера, который хранит логику приложения, обеспечивает выполнение PHP-скриптов и генерирует HTML-страницы. Front-end принимает сформированную страницу от Back-end и в качестве ответа на запрос пользователя передает ее в браузер. Получив страницу, браузер пользователя начинает ее отображение, что сопровождается отправкой серии запросов на графический контент и CSS. Эти запросы принимает Front-end и обрабатывает без обращений к Back-end’у.

Оценка скорости работы клиентской и серверной частей веб-приложения осуществляется двумя разными видами тестирования: для Front-end применяется тестирование клиентской части, или Client - Side Testing , а для Back-end – тестирование производительности серверной части .

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

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

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

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

Другая необходимая проверка направлена на анализ заголовков кэширования, поскольку корректность его выполнения при повторном посещении страницы позволяет повысить скорость загрузки страницы до 80%.

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

Тестирование производительности серверной части направлено на анализ выполнения запросов и получения соответствующего запроса от Back-end.

Цели данного вида тестирования:

• Измерить время отклика самых важных бизнес-транзакций;
• Определить предельный уровень допустимой нагрузки;
• Выявить «узкие» места в производительности системы;
• Составить рекомендации по улучшению производительности;
• Найти возможные дефекты, проявляющиеся только при одновременной работе большого количества пользователей.

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

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

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

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

Jmeter

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

Поиск: jmeter, нагрузочное тестирование с jmeter

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

До сих пор мне не удалось полностью освоить все «фишки» Jmeter, поскольку он обладает Очень большим функционалом. Но основные задачи по созданию тестовых сценариев для нагрузки я освоил. Во время работы с jmeter, у людей, не знакомых с нагрузочным тестированием, появится достаточно много вопросов по новым терминам. Этому также способствует англоязычный интерфейс, записывайте непонятные названия и обязательно изучайте их по ходу. Например для меня это были thread и swap.

Поиск: thread, swap

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

После изучения стандартных возможностей Jmeter я один раз сильно обжегся. Я совсем неправильно оценил собранные метрики и получил нагоняй от старшего коллеги. Из этого я сделал вывод — для тестирования нагрузки не достаточно знания только инструмента. Очень важно правильно оценивать собранные метрики после нагрузочных тестов и на их основании сделать правильный вывод.

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

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

Yandex Tank

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

Поиск: нагрузочные тесты yandex tank

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

Поиск: locust, нагрузочное тестирование locust

UPD. Есть несколько интересных онлайн сервисов для нагрузочного тестирования. Например loadimpact.com . Конечно масштабное нагрузочное тестирование там платное, но во всяком случае можно попробовать триальный режим.

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

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

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

Часто повторяющиеся ситуации

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

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

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

Поиск: профайлеры кода

Еще здесь очень полезны системы мониторинга. К примеру Zabbix, Ansible и другие. С их помощью можно отслеживать потребляемые ресурсы тех или иных скриптов и строить долгосрочные отчеты. Эти системы используются в основном dev-ops командами, но также сильно помогут в тестировании.

На этом все. Надеюсь я показал в какую сторону копать и что практиковать. Буду рад вашим вопросам в комментариях.

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

Вместо предисловия

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

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

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

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

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

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

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

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

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

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


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

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

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