Новое программное обеспечение и другие высокотехнологические продукты регулярно появляются на современном IT-рынке. Определить степень сопоставимости для решения конкретных задач, в каком объеме и достаточно ли безопасны в использовании возможно только в режиме нагруженного тестирования – услуги, которая предоставляется Компанией «Getbug Engineering ».
Нагрузочное тестирование (англ. Load Testing ) – процесс умышленной нагрузки системы, путем подачи множества запросов на саму систему или устройство, с целью определения показателей производительности, времени отклика, проверки соответствия требованиям, которые были предъявлены к данной системе или отдельному устройству
Для чего нужно нагрузочное тестирование сайта? Нагрузка на хостинг или сервер Вашего сайта растет и может создать нагрузку, которая будет критичной для работы сайта. Мы проводим нагрузочное тестирование для предотвращения подобных проблем с помощи комплексного стресс-теста. Основное направление деятельности компании направлено на осуществление контроля качества разрабатываемых высокотехнологичных продуктов на всем протяжении жизненного цикла их разработки. Востребованными услугами являются проблемы тестовых исследований взаимодействия человека и программного продукта, функциональное нагрузочное тестирование и тестирование безопасности применения ПО.
Оборудование тестового стенда должно как можно ближе соответствовать промышленной конфигурации. Особенно если на основе полученных в результате тестирования времени выполнения операций будут приниматься бизнес решения. Если речь идет об оптимизации приложения, то соответствие конфигураций тестового стенда и промышленного уже не так актуально. Для мониторинга тестовых серверов необходимо иметь доступ на сервера с правами для использования необходимых утилит, например, MS Windows Performance для MS Windows или sar, iostat, vmstat для unix-образных OS.
Первые запуски тестов являются пробными и позволяют понять поведение системы в целом: работу приложения и оборудования. Начинать испытания надо с нагрузочных точек с меньшей нагрузкой, двигаясь по мере нарастания нагрузки от меньшей к большей. В процессе тестирования количество нагрузочных точек может поменяться и изменятся количества виртуальных пользователей, входящих в ту или иную нагрузочную точку. Результаты испытаний, должны быть логически согласованы и при увеличении нагрузки, результаты времени выполнения операций и загрузки тестового оборудования, должны соответственно изменяться. Если на нагрузочной точке с большей нагрузкой результаты лучше, то такой эксперимент надо провести заново, чтобы понять причины такого “выброса”. Возможна ситуация, что нагрузочные точки были неправильно спроектированы и возможно нужно увеличить размер “шага”, чтобы действительно почувствовать увеличение нагрузки. Набор экспериментов и результатов, должны быть достаточны для того, чтобы можно было провести анализ “узких” мест и сделать выводы о производительности и стабильности работы тестируемого приложения.
Задача тестирования производительности определить масштабируемость приложения под нагрузкой:
Тестирование стабильности (надежности) проверяет работоспособность приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций играет второстепенную роль, а на первое место выходит отсутствие утечек памяти, перезапуски серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
Стрессовое тестирование проверяет работоспособность приложения или системы в целом в условиях стресса. Помогает оценить способность системы к возвращению в нормальное состояние после прекращения воздействия нагрузки. Нагрузкой может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Частной задачей стрессового тестирования может быть оценка деградации производительности.
Объемное тестирование позволяет оценить производительность при увеличении объемов данных в базе данных приложения:
Согласно положениям современной системной инженерии процедура тестирования не должна являться конечным этапом в процессе создания программного обеспечения. Ошибки в процессе создания подобного рода продуктов не выявленные на этапе их возникновения будут накапливаться, поэтому, так важно своевременное их обнаружение и устранение. Сам процесс тестирования должен применяться не только к программам, но и к интерфейсам или электронному оборудованию.
Проверка функциональности пользовательского интерфейса ставит перед собой задачу установления степени его адаптации к требованиям, которые ставили перед собой разработчики. Это относится в равной степени, как к интернет-приложениям, так и к веб-страницам. Проверке подлежит эргономичность, которая определяет взаимодействие типа «человек-компьютер», простота и отзывчивость управления, быстрота ознакомления с функциями нового программного продукта. Это основные характеристики, от показателей значения которых зависит экономия времени и удобство применения.
Компания производит тестирование в несколько этапов, которые состоят из:
анализа требований, которые были предъявлены разработчиками к своему продукту и их корректность;
разработки чек-листа тестирования;
проведения тестовых процедур;
определения полноты соответствия заявленных требований к результатам тестирования;
выработке отчета или об успешности теста, либо о выявленных нарушениях в функционировании программного продукта.
Целью проведения проверки степени безопасности продукта, является определение его уязвимости к воздействию вирусов или внешних атак хакеров. От этого показателя напрямую зависит правильность и надежность работы, как программ, так и оборудования. Конечный потребитель должен получить гарантии того, что установка нового продукта не снизит производительность и не поставит под угрозу целостность системы. Безопасность это также конфиденциальность и низкий уровень доступности. Целостность системы оценивается ее способностью к самовосстановлению, после внешнего проникновения или при несанкционированном воздействии.
Мы проводим комплекс работ любой сложности и обладаем лабораторией, квалифицированными специалистами и собственными инструментами разработки и проведения тестовых работ.
По мере роста и усложнения сайтов и приложений главной проблемой разработчиков становится обеспечение высокой производительности. Все современные исследования говорят о том, что от производительности сайта напрямую зависит количество посетителей, рост продаж и увеличение трафика. Потому так важно обратить внимание на то, как быстро пользователи могут получить доступ к сайту в браузере.
За последние несколько лет в сфере оптимизации производительности было разработано много передовых методов и технологий. Многие из этих методов предназначены для уменьшения размера загружаемых веб-страниц, оптимизации JavaScript и ограничения количества отдельных запросов HTTP.
Данная статья расскажет об основных понятиях и открытых инструментах для оптимизации производительности. С ее помощью вы сможете выяснить, как быстро ваш сервер отвечает на запросы пользователей, и разработать индивидуальный план.
Для начала нужно ознакомиться с базовыми терминами и понятиями.
Нагрузочное тестирование – это технология измерения производительности сервера, которая заключается в отправке имитируемого HTTP-трафика на сервер. Это позволяет найти ответы на такие вопросы:
Нагрузочное тестирование выполняется путем запуска специального программного обеспечения на одном компьютере (или в кластере машин). Это ПО генерирует большое количество запросов и отправляет их на веб-сервер на втором компьютере (или в другой инфраструктуре). Существует много таких инструментов, позже мы рассмотрим некоторые их них. На данный момент сосредоточимся на общих терминах, которые будут актуальны независимо от того, какое средство для нагрузочного тестирования вы выберете. Обычное программное обеспечение для нагрузочного тестирования используется для определения максимального количества запросов в секунду, которое может обрабатывать сервер. Для этого на сервер отправляется как можно большее количество запросов; затем нужно проверить, сколько из них сервер смог обработать успешно.
Это позволяет на базовом уровне определить максимальные возможности сервера, но это не предоставит много информации о задержках, ежедневной производительности и пользовательском опыте. Перегруженный сервер может возвращать тысячу ответов в секунду, но если обработка каждого ответа занимает десять секунд, пользователи, вероятно, не будут ждать.
Общая тенденция такова: чем выше нагрузка (чем больше запросов в секунду), тем выше задержка. Чтобы получить более реальную картину о задержке сервера при заданной нагрузке, нужно будет протестировать его несколько раз с разным количеством запросов. Не все приложения для тестирования нагрузки способны на это, но немного позже мы ознакомимся с wrk2 (это средство командной строки для тестирования нагрузки, которое может выполнить эту функцию).
Время загрузки веб-сайта в диапазоне 2-5 секунд – обычное дело, но часть времени, связанная с задержкой веб-сервера, обычно составляет около 50-200 миллисекунд. Идеальный показатель задержки индивидуален для каждого сайта. Он зависит от большого количества факторов (аудитории, рынка, целей сайта, наличия пользовательского интерфейса или API и т. д.). Имейте в виду: большинство исследований показывают, что в производительности учитывается каждый маленький бит скорости, и даже совсем незаметные улучшения приводят к улучшению результатов в целом.
Чтобы понять, как работает сервер и веб-приложение и как они реагируют на нагрузку, можно предпринять несколько общих действий. Во-первых, во время тестирования нужно отслеживать правильные системные ресурсы. Затем нужно определить максимальное количество запросов в секунду, которое может обработать данный сервер. Также следует определить пропускную способность, при которой задержка сервера приведет к низкой производительности и плохому пользовательскому опыту.
Программное обеспечение для нагрузочного тестирования соберет и предоставит информацию о запросах и задержках. Но есть и некоторые другие системные показатели, которые нужно отслеживать, чтобы понять, каких ресурсов не хватает серверу при работе с большими объемами трафика.
В основном это касается нагрузки процессора и свободной памяти: мониторинг этих данных при большой нагрузке поможет вам принять более обоснованные решения о том, как масштабировать инфраструктуру и где сосредоточить усилия при разработке приложения.
Если у вас уже есть система мониторинга типа 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).
Как говорилось ранее, большинство программ нагрузочного тестирования особенно хорошо подходят для поиска максимальной скорости ответа веб-сервера. Как правило, при этом нужно указать только конкурентность и продолжительность тестирования.
Конкурентность – это показатель, который отображает количество параллельных подключений, которое может обрабатывать сервер. Значение по умолчанию 100 подходит в большинстве случаев, но вы можете выбрать индивидуальное значение. Для этого нужно проверить MaxClients, MaxThreads сервера и другие подобные параметры.
Также вам нужно будет выбрать URL-адрес для тестирования. Если ваше программное обеспечение может обрабатывать только один URL за один раз, стоит выполнить несколько тестов для разных URL-адресов, так как требования к обработке могут сильно различаться в зависимости от страницы. Например, требования к загрузке домашней страницы сайта и страницы продукта разные.
Некоторое программное обеспечение для нагрузочного тестирования позволяет сразу указать несколько URL-адресов, которые нужно проверить. Это позволяет более точно имитировать реальный трафик. Если у вас есть данные об использовании сайта (из аналитического программного обеспечения или логов сервера), вы можете применить эти данные в тестировании.
Отобрав URL-адреса, запустите тестирование. Убедитесь, что программное обеспечение очень быстро отправляет запросы. Если программное обеспечение разрешает выбрать скорость запроса, выберите значение, которое почти наверняка будет слишком высоким для вашего сервера. Если программное позволяет установить задержку между запросами, уменьшите это значение до нуля.
Использование ресурсов процессора и памяти будет увеличиваться. Свободные ресурсы процессора могут достигать 0%, и клиент может получить ошибку соединения. Это нормально, поскольку сервер работает на пределе возможностей.
Когда тестирование закончится, программное обеспечение выведет статистические данные, включая количество запросов в секунду. Обратите внимание на время отклика: этот показатель, вероятно, будет очень плохим, так как сервер должен быть чрезвычайно перегружен во время теста. Поэтому количество запросов в секунду не является точным показателем максимальной пропускной способности сервера, но это хорошее начало для дальнейшего исследования.
Затем нужно повторить тестирование, чтобы получить дополнительную информацию о том, как работает сервер на пределе ресурсов.
На данном этапе нужно использовать программное обеспечение, которое может немного ускорить загрузку, чтобы проверить производительность сервера на разных уровнях пропускной способности. Некоторые программы позволяют указывать задержку между каждым запросом, но это затрудняет определение точной пропускной способности.
Здесь можно обратиться к инструменту wrk2, который позволяет указывать точное количество запросов в секунду.
Возьмите максимальную скорость запросов, которую вы определили на предыдущем этапе, и разделите ее на 2. Запустите еще один тест с новыми данными и обратите внимание на время ответа. Находится ли показатель в приемлемом диапазоне?
Если да, увеличьте значение до максимума и повторите тестирование, пока задержка не достигнет максимального значения, которое вы считаете приемлемым. Это и будет фактическая максимальная скорость ответа, которую может обрабатывать ваш сервер.
Существует множество программных пакетов с открытым исходным кодом для нагрузочного тестирования серверов. Кроме того, существует множество платных сервисов, которые умеют автоматически создавать графики и отчеты на основе данных, полученных в ходе тестирования. Эти сервисы отлично подходят крупным сайтам, которым необходимо генерировать высокую нагрузку для тестирования большой инфраструктуры.
Тем не менее, некоторые из открытых инструментов также могут работать в режиме кластера. Рассмотрим несколько наиболее популярных инструментов с открытым исходным кодом.
(или 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 – это мощное и многофункциональное приложение для нагрузочного и функционального тестирования от Apache Software Foundation. Функциональное тестирование – это проверка вывода приложения.
JMeter предлагает графический интерфейс Java для настройки тестовых планов.
Планы тестирования можно записать с помощью прокси-сервера JMeter и обычного браузера. Это позволяет вам использовать в тестах трафик, который более точно имитирует реальную работу сервера.
JMeter может выводить информацию о процентилях в отчетах HTML и других форматах.
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 – это инструмент для нагрузочного тестирования на основе Python, который предоставляет веб-интерфейс для мониторинга результатов в реальном времени.
Сценарии тестирования Locust пишутся с помощью кода Python, что предоставляет дополнительные преимущества тем, кто хорошо знаком с этим языком программирования.
Locust также можно запускать в распределенном режиме: вы можете запустить кластер из серверов Locust, который будет создавать высокую нагрузку вашего сервера. Это позволяет выполнить качественное нагрузочное тестирование целой инфраструктуры веб-серверов.
Locust может предоставить подробную статистику в CSV-файлах, которые можно загрузить.
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.
Цели данного вида тестирования:
Нагрузочное тестирование
Нагрузочное тестирование (англ. Load Testing ) - определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Для исследования времени отклика системы на высоких или пиковых нагрузках производится стресс-тестирование , при котором создаваемая на систему нагрузка превышает нормальные сценарии её использования. Не существует чёткой границы между нагрузочным и стресс-тестированием, однако эти понятия не стоит смешивать, так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию.
Термин нагрузочное тестирование может быть использован в различных значениях в профессиональной среде тестирования ПО. В общем случае он означает практику моделирования ожидаемого использования приложения с помощью эмуляции работы нескольких пользователей одновременно. Таким образом, подобное тестирование больше всего подходит для мультипользовательских систем, чаще - использующих клиент-серверную архитектуру (например, веб-серверов). Однако и другие типы систем ПО могут быть протестированы подобным способом. Например, текстовый или графический редактор можно заставить прочесть очень большой документ; а финансовый пакет - сгенерировать отчёт на основе данных за несколько лет. Наиболее адекватно спроектированный нагрузочный тест даёт более точные результаты.
Основная цель нагрузочного тестирования заключается в том, чтобы, создав определённую ожидаемую в системе нагрузку (например, посредством виртуальных пользователей) и, обычно, использовав идентичное программное и аппаратное обеспечение, наблюдать за показателями производительности системы.
| Пример 1:
Веб-сервис с функциональностью корзины покупателя рассчитан на 100 одновременно работающих пользователей, которые следуют некоторому определённому сценарию (заданные действия в указанных пропорциях):
В данном случае нагрузочное тестирование должно эмулировать вышеописанный типичный сценарий работы с веб-сервисом с целью удостовериться, что система готова к выходу в эксплуатацию. При этом для анализа могут сниматься показатели производительности системы в целом или каждого узла системы в частности. |
В идеальном случае в качестве критериев успешности нагрузочного тестирования выступают требования к производительности системы, которые формулируются и документируются на стадии разработки функциональных требований к системе до начала программирования основных архитектурных решений. Однако часто бывает так, что такие требования не были четко сформулированы или не были сформулированы вовсе. В этом случае первое нагрузочное тестирование будет являться пробным (exploratory load testing ) и основываться на разумных предположениях об ожидаемой нагрузке и потреблении аппаратной части ресурсов.
Одним из оптимальных подходов в использовании нагрузочного тестирования для измерений производительности системы является тестирование на стадии ранней разработки. Нагрузочное тестирование на первых стадиях готовности архитектурного решения с целью определить его состоятельность называется "Proof-of-Concept" тестированием.
Ниже рассмотрены некоторые экспериментальные факты, обобщённые в принципы, используемые при тестировании производительности в целом и применимые к любому типу тестирования производительности (в частности и к нагрузочному тестированию).
1. Уникальность запросовДаже сформировав реалистичный сценарий работы с системой на основе статистики ее использования, необходимо понимать, что всегда найдутся исключения из этого сценария.
Иллюстрация различной дисперсии распределений для времени выполнения запросов X и Y.
В случае Примера 1 это может быть пользователь, обращающийся к отличным от всех остальных, уникальным страницам веб-сервиса.
2. Время отклика системыВ общем случае время отклика системы подчиняется функции нормального распределения .
В частности это означает, что имея достаточное количество измерений, можно определить вероятность с которой отклик системы на запрос попадёт в тот или иной интервал времени.
3. Зависимость времени отклика системы от степени распределённости этой системы.Дисперсия нормального распределения времени отклика системы на запрос пропорциональна отношению количества узлов системы, параллельно обрабатывающих такие запросы и количеству запросов, приходящихся на каждый узел.
То есть, на разброс значений времени отклика системы влияет одновременно количество запросов приходящихся на каждый узел системы и само количество узлов, каждый из которых добавляет некоторую случайную величину задержки при обработке запросов.
4. Разброс времени отклика системыИз утверждений 1, 2 и 3 можно также заключить, что при достаточно большом количестве измерений величины времени обработки запроса в любой системе всегда найдутся запросы, время обработки которых превышает определённые в требованиях максимумы; причем, чем больше суммарное время проведения эксперимента тем выше окажутся новые максимумы.
Этот факт необходимо учитывать при формировании требований к производительности системы, а также при проведении регулярного нагрузочного тестирования.
5. Точность воспроизведения профилей нагрузкиНеобходимая точность воспроизведения профилей нагрузки тем дороже, чем больше компонент содержит система.
Часто невозможно учесть все аспекты профиля нагрузки для сложных систем, так как чем сложнее система, тем больше времени будет затрачено на проектирование, программирование и поддержку адекватного профиля нагрузки для неё, что не всегда является необходимостью. Оптимальный подход в данном случае заключается в балансировании между стоимостью разработки теста и покрытием функциональности системы, в результате которого появляются допущения о влиянии на общую производительность той или иной части тестируемой системы.
Следует отметить, что для большинства видов тестирования производительности используется один и тот же инструментарий, умеющий выполнять типовые задачи.
Существует распространённое ошибочное понимание того, что инструменты для нагрузочного тестирования системы - это инструменты такие же по принципу записи и воспроизведения как и инструменты для автоматизации регрессионного тестирования . Инструменты для нагрузочного тестирования работают на уровне протокола, тогда как инструменты для автоматизации регрессионного тестирования работают на уровне объектов графического пользовательского интерфейса.
Существуют различные инструменты для обнаружения и исследования проблем в различных узлах системы. Все узлы системы могут быть классифицированы следующим образом:
Также следует отметить появление сетевых Business-to-business (B2B) приложений, использующих соглашение об уровне услуг (или SLA, Service Level Agreement). Нарастающая популярность B2B-приложений привела к тому, что всё больше приложений переходят на сервис-ориентированную архитектуру , в случае которой обмен информацией происходит без участия веб-браузеров. Примером такого взаимодействия может служить бюро туристических услуг, запрашивающее информацию об определённом авиарейсе между Санкт-Петербургом и Омском, в то время как авиакомпания обязана предоставить ответ в течение 5 секунд. Часто нарушение договора об SLA грозит крупным штрафом.
Наиболее популярные инструменты для нагрузочного тестирования представлены ниже.
| ПО | Наименование производителя | Комментарии |
|---|---|---|
| OpenSTA | "Open System Testing Architecture" | Свободно распространяемое программное обеспечение для нагрузочного/стресс тестирования, лицензированное GNU GPL. Использует распределённую архитектуру приложений, основанную на CORBA . Доступна версия под Windows, хотя имеются проблемы с совместимостью с Windows Vista. Поддержка прекращена в 2007 году. |
| IBM Rational Performance Tester | IBM | Основанное на среде разработки Eclipse ПО, позволяющее создавать нагрузку больших объёмов и измерять время отклика для приложений с клиент-серверной архитектурой. Требует лицензирования. |
| JMeter | Открытый проект Apache Jakarta Project | Основанный на Java кроссплатформенный инструментарий, позволяющий производить нагрузочные тесты с использованием JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP соединений. Даёт возможность создавать большое количество запросов с разных компьютеров и контролировать процесс с одного из них. |
| HP LoadRunner | HP | Инструмент для нагрузочного тестирования, изначально разработанный для эмуляции работы большого количества параллельно работающих пользователей. Также может быть использован для unit- или интеграционного тестирования . |
| SilkPerformer | Micro Focus | |
| Visual Studio Load Test | Microsoft | Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing |
| LoadComplete | SmartBear |
Одним из результатов, получаемых при нагрузочном тестировании и используемых в дальнейшем для анализа, являются показатели производительности приложения. Основные из них разобраны ниже.
1. Потребление ресурсов центрального процессора (CPU, %)Метрика, показывающая сколько времени из заданного определённого интервала было потрачено процессором на вычисления для выбранного процесса. В современных системах важным фактором является способность процесса работать в нескольких потоках, для того, чтобы процессор мог производить вычисления параллельно. Анализ истории потребления ресурсов процессора может объяснять влияние на общую производительность системы потоков обрабатываемых данных, конфигурации приложения и операционной системы, мультипоточности вычислений, и других факторов.
2. Потребление оперативной памяти (Memory usage, Mb)Метрика, показывающая количество памяти, использованной приложением. Использованная память может делиться на три категории:
При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым «сборщиком мусора» (англ. Garbage Collector ). Время затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в Java - так называемый «постоянный Full GC») или когда процессу выделены большие объёмы памяти, нуждающиеся в очистке. На время, требующееся для очистки памяти, доступ процесса к страницам выделенной памяти может быть заблокирован, что может повлиять на конечное время обработки этим процессом данных.
3. Потребление сетевых ресурсовЭта метрика не связана непосредственно с производительностью приложения, однако её показатели могут указывать на пределы производительности системы в целом.
| Пример 3:
Серверное приложение обрабатывая запрос пользователя, возвращает ему видео-поток, используя сетевой канал в 2 мегабит. Требование гласит, что сервер должен обрабатывать 5 запросов пользователей одновременно. Нагрузочное тестирование показало, что эффективно сервер может предоставлять данные только 4 пользователям одновременно, так как мультимедиа-поток имеет битрейт в 500 килобит. Очевидно, что предоставление этого потока 5 пользователям одновременно невозможно в силу превышения пропускной способности сетевого канала, а значит, система не удовлетворяет заданным требованиям производительности, хотя при этом потребление ей ресурсов процессора и памяти может быть невысоким. |
Работа с дисковой подсистемой может значительно влиять на производительность системы, поэтому сбор статистики по работе с диском может помогать выявлять узкие места в этой области. Большое количество чтений или записей может приводить к простаиванию процессора в ожидании обработки данных с диска и в итоге увеличению потребления CPU и увеличению времени отклика.
5. Время выполнения запроса (request response time, ms)Время выполнения запроса приложением остаётся одним из самых главных показателей производительности системы или приложения. Это время может быть измерено на серверной стороне, как показатель времени, которое требуется серверной части для обработки запроса; так и на клиентской, как показатель полного времени, которое требуется на сериализацию / десериализацию , пересылку и обработку запроса. Надо заметить, что не каждое приложение для тестирования производительности может измерить оба этих времени.
Wikimedia Foundation . 2010 .
Когда веб-приложение (сайт, сервис) еще достаточно молодое, но нацелено на широкую аудиторию, то весьма сложно понять насколько мощное серверное оборудование требуется. Так что лучшим решением будет симуляция потока пользователей при помощи синтетических тестов.
Наверное, один из самых простых в использовании и популярных тестов для проверки нагрузки на сайт. Утилита подходит как для простого, так и продвинутого тестирования:
Ab -c 50 -n 10000 -f TLS1.2 -H "Accept-Encoding: gzip,deflate" https://somesite.com/
# Проверка максимального количества запросов с TLS
Команда выполнила 10 000 запросов в 50 потоков и, кроме всего прочего, показала скорость и обработанное количество запросов:
Total transferred: 59560000 bytes HTML transferred: 52160000 bytes Requests per second: 816.77 [#/sec] (mean) Time per request: 122.434 (mean) Time per request: 2.449 (mean, across all concurrent requests) Transfer rate: 2375.33 received
# Лог теста выдает намного больше информации
Из этого отчета самыми важными данными будут:
AB пригодится для быстрой и грубой оценки производительности веб-сервера, так что если нужно получить более приближенные к реальности данные, придется воспользоваться дополнительными утилитами.
Этот тест с открытым исходным кодом был разработан в HP для измерения производительности веб-сервера. Инструмент не обновлялся несколько лет, но все еще является весьма актуальным.
Утилита, как и ab, проста в использовании и обладает достаточно широким функционалом. Запускается она так же просто, как и ab:
Httperf --hog --server 192.168.122.10 --wsess=100000,5,2 --rate 1000 --timeout 5
# Создание 100 000 сессий (по 5 вызовов через каждые 2 с) со скоростью 1000
А лог будет выглядеть так:
Total: connections 117557 requests 219121 replies 116697 test-duration 111.423 s Connection rate: 1055.0 conn/s (0.9 ms/conn, <=1022 concurrent connections) Connection time : min 0.3 avg 865.9 max 7912.5 median 459.5 stddev 993.1 Connection time : connect 31.1 Connection length : 1.000 Request rate: 1966.6 req/s (0.5 ms/req) Request size [B]: 91.0 Reply rate : min 59.4 avg 1060.3 max 1639.7 stddev 475.2 (22 samples) Reply time : response 56.3 transfer 0.0 Reply size [B]: header 267.0 content 18.0 footer 0.0 (total 285.0) Reply status: 1xx=0 2xx=116697 3xx=0 4xx=0 5xx=0 CPU time [s]: user 9.68 system 101.72 (user 8.7% system 91.3% total 100.0%) Net I/O: 467.5 KB/s (3.8*10^6 bps)
# Кроме всего прочего, производительность показывает величина скорости запросов (Request rate)
В этом отчете стоит сфокусироваться на:
Но для более глубокой проверки и существенной нагрузки придется использовать еще более продвинутые инструменты.
Это мощная, продвинутая, мультизадачная и мультипоточная утилита. Инструмент может использоваться для нагрузки серверов HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP и Jabber/XMPP. Поддерживается SSL, мониторинг ресурсов системы и агенты SNMP, Munin или Erlang на удаленных серверах, симуляция поведения юзеров и расширенные отчеты.
Инструмент написан на Erlang, так что для начала необходимо установить нужные репозитории, а затем скачать и установить Tsung:
Wget http://tsung.erlang-projects.org/dist/tsung-1.6.0.tar.gz tar zxfv tsung-1.6.0.tar.gz cd tsung-1.6.0 ./configure && make && make install
# Распаковка и компиляция утилиты
Все настройки инструмента необходимо прописать в его файле конфигурации:
Cp /usr/share/doc/tsung/examples/http_simple.xml /root/.tsung/tsung.xml
# Копирование шаблона файла конфигурации в директорию Tsung
После чего его нужно отредактировать, задав необходимые параметры:
# Можно указывать дополнительные опции (к примеру браузеры юзеров), множества нодов для симуляции пользователей
Теперь можно запускать tsung:
Tsung -f tsung.xml start Starting Tsung "Log directory is: /root/.tsung/log/20160428-1117"
# Для запуска с множества нодов их нужно предварительно указать в настройках
Когда утилита закончила свою работу, можно просмотреть отчет:
Mkdir report_output cd report_output /usr/lib/tsung/bin/tsung_stats.pl --stats /root/.tsung/log/20160428-1117/tsung.log chromium graph.html
# Указывается предпочтительный браузер
Отчет будет состоять из графиков и важной дополнительной информации. В нем стоит обратить внимание на:
Дополнительные графики позволят оценить нагрузку на веб-сервер за все время тестирования, отследить возникшие ошибки и динамику.
Конечно же список инструментов для проверки производительности веб-сервера и тестирования нагрузки на сайт не ограничивается приведенным в этом материале. Таких утилит огромное множество, как платных, так и бесплатных. Существуют сайты для генерации нагрузки, типа LoadImpact, утилиты для запуска из командной строки и полноценные программы с GUI. Одной из самых популярных с пользовательским интерфейсом, кстати, является Apache JMeter — мощная, продвинутая и достаточно сложная.
Apache Bench, Httperf и Tsung отлично подходят для тестирования нагрузки на большие и маленькие сайты. Но только tsung сможет выжать все соки из веб-сервера и показать на что он способен в условиях, приближенных к реальности. Не забывайте, что сначала все тесты нужно провести для одного пользователя, чтобы проследить зависимость и иметь точку отсчета.
