Нагрузочный сервер. Начинающему тестировщику — Нагрузочное тестирование. Цели нагрузочного тестирования

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

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

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

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

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

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

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

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

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

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

1. Уникальность запросов

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

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

2. Время отклика системы

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

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

3. Зависимость времени отклика системы от степени распределённости этой системы.

ПО	Наименование производителя	Комментарии
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- или интеграционного тестирования .
LoadComplete	SmartBear	Проприетарный продукт, позволяющий проводить нагрузочное тестирование веб-приложений
SilkPerformer	Micro Focus (Borland)
Siege	Joe Dog Software	Siege - это утилита для нагрузочного тестирования веб-серверов.
Visual Studio Team System	Microsoft	Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing
QTest	Quotium
HTTPerf
QALoad	Compuware Ltd.
(The) Grinder
WebLOAD	RadView Software	Нагрузочное тестирование инструмент для веб-и мобильных приложений, включая веб-панели для тестирования производительности анализа. Используется для крупномасштабных нагрузок, которые могут быть сгенерированы также из облака. лицензированный.
Яндекс.Танк	Яндекс	Модульный и расширяемый инструмент, позволяющий использовать внутри разные генераторы, в частности, знакомый многим JMeter. Это open-source проект, опубликованный Яндексом в 2012 году.

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

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

1. Потребление ресурсов центрального процессора, %

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

2. Потребление оперативной памяти, Мб

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

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

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

3. Потребление сетевых ресурсов

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

Пример 3: Серверное приложение обрабатывая запрос пользователя, возвращает ему видео-поток, используя сетевой канал в 2 мегабит. Требование гласит, что сервер должен обрабатывать 5 запросов пользователей одновременно. Нагрузочное тестирование показало, что эффективно сервер может предоставлять данные только 4 пользователям одновременно, так как мультимедиа-поток имеет битрейт в 500 килобит. Очевидно, что предоставление этого потока 5 пользователям одновременно невозможно в силу превышения пропускной способности сетевого канала, а значит, система не удовлетворяет заданным требованиям производительности, хотя при этом потребление ей ресурсов процессора и памяти может быть невысоким.

4. Работа с дисковой подсистемой (время ожидания ввода-вывода, англ. I/O wait )

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

5. Время выполнения запроса, мс

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

Мы продолжаем рассказывать о компаниях-разработчиках решений (ISV), использующих облачные технологии. В этом выпуске мы расскажем про применение облачных сервисов Visual Studio Team Services, Azure, Application Insights и других для профессионального нагрузочного тестирования коммерческих продуктов на примере AdvantShop – решения для электронной коммерции, разработанном на базе ASP.NET. Предыдущие статьи цикла вы всегда можете найти на Хабре по ссылке #isvcloudstory . - Владимир Юнев

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

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

Специалисты компании "Логрокон" производят тщательную подготовку к тестированию, которая включает:

1. Анализ требований и сбор информации о тестируемой системе
2. Определение целей нагрузочного тестирования
3. Конфигурация тестового стенда для нагрузочного тестирования
4. Разработка модели нагрузки (Профиль НТ)
5. Выбор инструмента для нагрузочного тестирования
6. Разработка методики нагрузочного тестирования.
7. Создание и отладка тестовых скриптов

Результаты тестирования оформляются в отчете, который содержит:

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

Перед нами была поставлена задача тестирования производительности интернет-магазина AdvantShop . На сегодняшний день рынок ИТ предоставляет большое разнообразие средств для проведения нагрузочного тестирования ПО. И первый вопрос, который необходимо было решить для себя – какому из инструментов проведения нагрузочного тестирования отдать предпочтение?

Вероятно, многие из вас слышали о таком средстве тестирования производительности как Load runner. Наличие большого числа Web-протоколов объясняется желанием разработчиков охватить большой спектр технологий и уровней «захвата» данных. Выбирая этот инструмент для проведения нагрузочного тестирования нужно определиться, что для нас важнее: нетребовательность к ресурсам или удобство создания, поддержки и использования скрипта. Оба критерия для нас важны при проведении нагрузочных испытаний, поэтому продолжим поиск подходящего для нас средства проведения тестирования производительности.

Помимо платных утилит для проведения тестирования производительности рынок предлагает и ряд бесплатных. Под обзор попал такой из бесплатных инструментариев как Apache JMeter. К сожалению, этот инструмент имеет достаточно много проблем и ограничений: он может не поддерживать необходимые протоколы; в нём отсутствуют удобные средства мониторинга; выдаваемые им результаты требуют дополнительной обработки. А поскольку специалисты «Логрокон» отвечают не только за качество услуг, но и за сроки их оказания - такому инструменту как Apache JMeter мы не отдали предпочтение для помощи в проведении работ по тестированию производительности интернет-магазина.

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

Тестирование «у себя» вызывает определенные трудности:

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

Однако с этими проблемами помогает справиться облачная служба Microsoft Azure , при использовании которой можно выделить очевидные преимущества перед тестированием «у себя» и использованием других доступных средств:

• Быстрый выход качественного продукта на рынок
• Цена. Отсутствие и устранение капитальных расходов при доступе к тестовому окружению в облаке, которое масштабируется лучше, чем собственное.
• Использование знакомых инструментов
• Лучшее тестирование с “бесконечным” облаком
• Изолирование продакшн-серверов . Предотвращение влияния процесса разработки и тестирования и тестовых приложений на серверы работающие в коммерческой эксплуатации в компании
• Доступ из облака к существующим мощностям в компании
• Размещение в любом месте без лок-ина

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

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

Безусловным преимуществом для выбора Microsoft Azure при тестировании производительности интернет-магазина AdvantShop является тот факт, что сервер приложений и сервер БД развернуты в Azure - это существенно упрощает развертывание инфраструктуры нагрузочного тестирования.

Средства Microsoft Azure позволяют выполнять нагрузочное тестирование с помощью Visual Studio Team Services (ранее сервис назывался Visual Studio Online), либо с помощью Virtual Machine.

Нагрузочное тестирование с помощью Visual Studio Team Services (VSTS) позволяет автоматически создавать и конфигурировать всю необходимую инфраструктуру в облаке, разворачивая контроллер и необходимое количество агентов с определенными настройками. Результаты прогона того или иного теста всегда остаются в облачной базе VSTS, и к ним в любой момент можно получить доступ. Помимо доступного развертывания инфраструктуры нагрузочного тестирования стоит обратить внимание на мониторинг приложений, поскольку при проведении нагрузочных испытаний тестировщик обращается к нему снова и снова. VSTS позволяет прямо в процессе нагрузочного тестирования динамически подгружать необходимые счетчики производительности из телеметрии Application Insights . Возможности Application Insights выходят далеко за рамки снятия метрик, настроенных в Performance Monitor непосредственно на серверах приложения. Имея доступ непосредственно к коду приложения, можно передавать в Application Insights данные об отслеживании событий, метрик, трассировки, зависимостей и тому подобное. Посредством такого подхода можно вычислить, к примеру, как часто пользователи выбирают определенный компонент, как часто они достигают определенной цели или как часто возникают те или иные ошибки.

И все-таки при выборе между VSTS и развертыванием Virtual Machine мы отдали предпочтение более знакомой нам классической инфраструктуре с агентами и контроллером, хотя средства VSTS ничем не уступают. При этом подходе помимо имеющихся серверов IIS и DB необходимо создать виртуальные машины для контроллера и агентов тестирования. На отдельную виртуальную машину имеет смысл вынести Visual Studio, поскольку при использовании VS локально можем столкнуться с проблемой нехватки ресурсов для обеспечения необходимой нагрузки на приложение.

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

При развертывании VM для контроллера

• TCP порт 445 для удаленного сборка счетчиков производительности
• UDP порт 1434 для SQL Browser и TCP 1433 для подключения к SQL серверу
• TCP порт для подключения к Test Controller`y 6901
• Remote Destop.

После настройки VM подключаемся к ней через RDP и устанавливаем TestController. Затем запускаем Test Controller Configuration Tools и указываем аккаунт, с которым подключались к виртуальной машине, отмечаем галочку Configure test controller for load testing. В строке SQL Server instance указываем полное DNS-имя VM (не localhost, а, к примеру, adv5controller.cloudapp.net\SQLExpress чтобы была возможность сохранять результаты теста при запуске VS с другой VM).

Загружаем и устанавливаем дистрибутив SQL Server Express по ссылке на UI.

Запускаем SQL Server Configuration Manager и включаем Pipe и TCP/IP протоколы. В настройках TCP/IP включаем все доступные IP адреса Enabled и для IPAll устанавливаем статический порт 1433.

В настройках Firewall`a разрешаем подключения на следующие порты:

• исходящие подключения на агент (порт 6910)
• входящие подключения к службе контроллера 6901
• входящие подключения к службе RPC для сбора счетчиков производительности – порт 445
• подключения к студии (фреймворку LoadTest), исходящий порт 6915
• входящие подключения на TCP порт 1433 и UDP 1434

Возвращаемся в Test Controller Configuration Tools и нажмаем Apply settings. Начнется процесс конфигурирования контроллера тестирования. В последнем сообщении будет warning, на который не стоит обращать внимания.

При развертывании VM для агента в настройках открываем следующие порты:

• TCP порт 445 для удаленного сбора счетчиков производительности
• TCP порт для подключения к Test Agent`y 6910
• Remote Desktop

После настройки VM подключаемся к ней через RDP и устанавливаем TestAgent.

В настройках Firewall`a следует разрешить подключения на следующие порты:

• Входящие подключения к службе контроллера 6910
• Исходящие подключения к контроллеру тестирования 6901
• Входящие подключения к службе RPC для сбора счетчиков производительности – порт 445

Запускаем Test Agent Configuration Tools, в настройках указываем свой аккаунт и прописываем строку подключения к контроллеру. После нажатия Apply Settings запустится процесс конфигурирования агента тестирования.

После успешного его завершения отобразится окно статуса подключения агента

Перейдем к настройке виртуальной машины с Visual Studio .

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

После настройки VM подключаемся к ней по RDP и в настройках Firewall’a прописываем следующие подключения:

• Открываем порт 6915 для входящих соединений
• Открываем порт 6901 для исходящих на контроллер
• Исходящие порты UDP 1434 и TCP 1433 для подключения к базе SQL
• Исходящий 445 для подключения к RPC

Создаем новое решение Web performance And Load Test Project. Добавляем в него UnitTestProject1. В SolutionItems добавляем новый файл типа TestSettings и открываем его. На вкладке Roles устанавливаем RemoteExecution и прописываем вручную DNS имя виртуальной машины контроллера.

В меню Load Test выбераем вкладку Manage Test Controller и проверяем, что студия может подключиться к контроллеру:

Затем создаем новый Load Test, на вкладке Counter Sets добавляем для снятия метрик машину, на которой установлено тестируемое приложение и выбираем хотя бы один из доступных по умолчанию наборов счетчиков.

Внутри созданного нагрузочного теста добавим необходимые счетчики производительности для сервера приложения. Для этого два раза нажимаем на созданный нагрузочный тест, правой кнопкой мыши добавляем Add counters в созданном ранее Counter Set’e. Аналогичную процедуру проделаем с сервером БД.

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

После проведения подготовительных мероприятий и создания необходимых скриптов нагрузки была разработана методика тестирования и план подачи нагрузки для интернет-магазина AdvantShop.

Цель первого прогона: определение максимального числа одновременно работающих пользователей при сохранении времен отклика в пределах значения х4 от единичного прогона (в данном случае 5 секунд)

Для определения максимального числа одновременно работающих пользователей были определены следующие параметры сценария нагрузки: нагрузка плавно подается на протяжении 10 часов для фиксированного числа пользователей, начиная со значения 500 пользователей и увеличивается каждые 30 минут на 500 пользователей до значения 10 000 одновременно работающих пользователей.

По итогам этого теста можно заключить, что по истечении 1 часа 30 минут приложение начинает деградировать. Сопоставив эти данные с графиком количества активных виртуальных пользователей, делаем вывод, что времена откликов начинают превышать значение 5 секунд при одновременной работе 1 500 пользователей. Однако на протяжении всего теста, продолжительностью 10 часов, не было зафиксировано таймаутов, что свидетельствует о возможности приложения выдерживать нагрузку до 10 000 одновременно работающих пользователей с увеличением времени отклика.

Проведя второй тест с условиями одновременной работы 1 500 пользователей (по итогам предыдущего теста) на протяжении 3 часов, мы получили следующий график времен отклика, который говорит о том, что приложение интернет-магазин AdvantShop выдерживает нагрузку в 1 500 виртуальных пользователей без деградации.

Мониторинг утилизации ресурсов позволяет сделать вывод, что имеет смысл пересмотреть конфигурацию сервера БД с целью снижения CPU, однако и текущая конфигурация обеспечивает одновременную бесперебойную работу 1 500 пользователей.

Средствами облачной службы Microsoft Azure было проведено нагрузочное тестирование интернет-магазина AdvantShop, так же развернутого в облаке. Приняв во внимание рекомендации по оптимизации работы приложения, коллеги из AdvantShop выпустят новую версию приложения. А благодаря тому, что инфраструктура нагрузочного тестирования была развернута в облаке, мы обеспечили себе возможность в любой момент повторить нагрузочные испытания с минимальным временем на подготовку и развертыванием стенда с новой конфигурацией – достаточно перенастроить и запустить VM облаке.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Если хочется чуть более серьезного - можно попробовать

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

Apache Bench

Наверное, один из самых простых в использовании и популярных тестов для проверки нагрузки на сайт. Утилита подходит как для простого, так и продвинутого тестирования:

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

# Лог теста выдает намного больше информации

Из этого отчета самыми важными данными будут:

• Requests per second - количество запросов в секунду. К примеру если страница состоит из 20 частей (CSS, картинки и HTML), то в нашем примере сервер способен обработать около 40 одновременных пользователей в секунду.
• Time per request (mean) - среднее время на выполнение группы параллельных запросов (в нашем случае 50);
• Time per request (mean, across all concurrent requests) - среднее время на выполнение одного запроса.

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

Httperf

Этот тест с открытым исходным кодом был разработан в 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)

В этом отчете стоит сфокусироваться на:

• Connection rate - реальная скорость создания новых соединений. Она показывает способность сервера обрабатывать соединения, то есть в нашем случае до 1055 соед./с, но не более 1022 одновременных соединений.
• Connection time - время “жизни” успешных соединений между инициализацией и закрытием. Опять же показывает производительность сервера при обработке большого количества соединений.
• Request rate - скорость обработки запросов. То есть, количество запросов, которые сервер способен выполнять за секунду, показывает отзывчивость веб-приложения.

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

Tsung

Это мощная, продвинутая, мультизадачная и мультипоточная утилита. Инструмент может использоваться для нагрузки серверов 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

# Указывается предпочтительный браузер

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

• Session - общее количество пользователей и количество одновременных сессий в секунду, которые веб-сервер обработал.
• Request - время отклика веб-сервера, его способность и скорость обработки одновременных запросов. К примеру 200 запросов/с значит, что в среднем 10 пользователей сможет одновременно получить зайти на веб-страницу, состоящую в общем из 20 компонентов (CSS, картинки и HTML). А это более 400 000 посетителей за 12 часов.
• Connect - время, требуемое на подключение, то есть отзывчивость веб-сервера .

Дополнительные графики позволят оценить нагрузку на веб-сервер за все время тестирования, отследить возникшие ошибки и динамику.

Другие утилиты

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

Самое главное

Apache Bench, Httperf и Tsung отлично подходят для тестирования нагрузки на большие и маленькие сайты. Но только tsung сможет выжать все соки из веб-сервера и показать на что он способен в условиях, приближенных к реальности. Не забывайте, что сначала все тесты нужно провести для одного пользователя, чтобы проследить зависимость и иметь точку отсчета.

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

Первым в череде тестов проводится стресс-тест (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.

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

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