Полное руководство по тестированию сайтов и веб-приложений

LoadUI Pro

LoadUI – это особенный инструмент для нагрузочного тестирования. В
основном предназначен для веб-сервисов, работающих на Linux, Windows и Mac OS,
и позволяет пользователям оценивать масштабируемость, скорость и
производительность API. В результате пользователи могут просмотреть поведение
производительности API, и уже после внедрять ПО в продуктив.

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

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

Плюсы

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

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

• LoadUI Pro Small – Фиксированная лицензия: $
  4,999 / год
• LoadUI Pro Medium – Фиксированная лицензия: $ 9,999 / год
• ReadyAPI – Фиксированная или плавающая лицензия (детали запрашиваются
  у поставщика)

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

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

Load Testing Tools:

LoadNinja

LoadNinja – is revolutionizing the way we load test. This cloud-based load testing tool empowers teams to record & instantly playback comprehensive load tests, without complex dynamic correlation & run these load tests in real browsers at scale. Teams are able to increase test coverage. & cut load testing time by over 60%.

NeoLoad:

NeoLoad is the enterprise-grade load testing platform designed for Agile and DevOps. NeoLoad integrates with your continuous delivery pipeline to support performance testing across the complete software lifecycle — from component to full system-wide load tests.

Load Runner:

Load runner is HP tool used to test the applications under normal and peak load conditions. Load runner generates load by creating virtual users that emulate network traffic. It simulates real time usage like a production environment and gives graphical results.

Read more about Loadrunner here.

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

Тестирование производительности

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

Объемное тестирование

Тестирование поведения системы при увеличении объема данных

Тестирование стабильности

Проверка работоспособности системы в течение длительного времени эксплуатации, в том числе с большими объемами данных и высокой нагрузкой

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

Проверка работоспособности и надежности серверной части системы

Стресс тестирование

Проверка корректности работы системы в режиме перегрузки и сбоев

Подбор оборудования

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

K6

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

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

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

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

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

Плюсы

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

Минусы

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

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

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

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

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

Glossary

Before we begin, let’s clarify some relevant terms and concepts:

• Latency is a measure of how fast a server responds to requests from the client. Typically measured in milliseconds (ms), latency is often referred to as response time. Lower numbers indicate faster responses. Latency is measured on the client side, from the time the request is sent until the response is received. Network overhead is included in this number.
• Throughput is how many requests the server can handle during a specific time interval, usually reported as requests per second.

• Percentiles are a way of grouping results by their percentage of the whole sample set. If your 50th percentile response time is 100ms, that means 50% of the requests were returned in 100ms or less. The graph below shows why it’s useful to look at your measurements by percentile:

  The graph above shows the latency of a web server over a period of time. Even though the mean (average) response time is fairly consistent, there’s a large spike in the 99th percentile line. This means that 1% of our users’ requests performed even worse than this 99th percentile measurement, while the average remained relatively stable. For this reason, it’s worth looking at percentiles to get a more accurate feel for what your users are really experiencing.

LoadRunner

Micro-Focus Loadrunner (ранее известный как HP Loadrunner) – это
довольно сложный инструмент нагрузочного тестирования программного обеспечения,
который обнаруживает проблемы с производительностью, наверное, прежде всего в энтерпрайз-приложениях.
LoadRunner может применяться для тестирования программного обеспечения ERP,
устаревших системных приложений, а также технологий Web 2.0.

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

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

Плюсы

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

Минусы

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

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

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

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

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

Prerequisites of load testing:

The chief metric for load testing is response time. Before you begin load testing, you must determine —

• Whether the response time is already measured and compared — Quantitative
• Whether the response time is applicable to the business process — Relevant
• Whether the response time is justifiable — Realistic
• Whether the response time is achievable — Achievable
• Whether the response time is measurable using a tool or stopwatch — Measurable

An environment needs to be set up before starting the load testing:

Hardware Platform	Software Configuration
Server Machines Processors Memory Disk Storage Load Machines configuration Network configuration	Operating System Server Software

Strategies of load Testing:

There are many numbers of ways to perform load testing. Following are a few load testing strategies-

• Manual Load Testing: This is one of the strategies to execute load testing, but it does not produce repeatable results, cannot provide measurable levels of stress on an application and is an impossible process to coordinate.
• In house developed load testing tools: An organization, which realizes the importance of load testing, may build their own tools to execute load tests.
• Open source load testing tools: There are several load testing tools available as open source that are free of charge. They may not be as sophisticated as their paid counterparts, but if you are on a budget, they are the best choice.
• Enterprise-class load testing tools: They usually come with capture/playback facility. They support a large number of protocols. They can simulate an exceptionally large number of users.

Определяемся с требованиями к производительности

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

• Desktop-приложения (актуально и для современных мобильных и веб-приложений). В таком софте обычно важны скорость запуска, время отклика на нажатия клавиш (никто не хочет ждать десять секунд после нажатия на пункт меню), время выполнения распространенных операций. Например, в текстовом редакторе при открытии файла можно и подождать секунду-другую, но вот ждать столько же, пока на экране появится набранный символ, — это нонсенс.
• Server-side приложения — всевозможные СУБД, API (REST-, SOAP-, RPC-серверы) и так далее. Тут список требований к скорости работы может быть просто огромный, начиная от времени ответа на запрос для одного клиента и заканчивая временем отклика при условии, что у нас есть одновременно 1k клиентов к REST API и все они что-то делают.
• *aaS, всевозможные облака. Производительность облака может измеряться совсем иначе, чем, например, REST API сервиса. Тут в зависимости от типа облака все может сильно и очень сильно меняться. В случае с perfomance SaaS (software-as-a-service) требования почти такие же, как и к любому высоконагруженному веб-приложению. А вот если ты тестируешь IaaS (infrastructure-as-a-service), то требования могут быть совсем другими, например: запуск X виртуальных инстансов не должен занимать больше Y времени, а вот временем, сколько она будет выключаться, иногда можно и пренебречь.

Тут как и с любыми требованиями — нужно отталкиваться от того, что в итоге должно получиться, и не забывать про здравый смысл. Ведь если твой REST API отправляет ответ за одну секунду, а WEB UI потом десять секунд отображает результат, то оптимизировать бэкенд нужно не в первую очередь. Пользователи будут более благодарны за быстрый UI.

Жизненный цикл продукта и тестирование

Все чаще в наше время используются итеративные процессы разработки ПО, в частности, технология RUP — Rational Unified Process (Рис. 1). При использовании такого подхода тестирование перестает быть процессом «на отшибе», который запускается после того, как программисты написали весь необходимый код. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов. В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл.

Рис. 1. Жизненный цикл продукта по RUP

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

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

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

В первой фазе — Начало — основное внимание уделяется задачам анализа. В итерациях второй фазы — Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений

В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику.

Рис. 2. Итерации жизненного цикла программного продукта

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

Load Testing Basics

Load testing is the practice of sending simulated HTTP traffic to a server in order to measure performance and answer some important questions, such as:

• Does the server have enough resources (CPU, memory, etc.) to handle the anticipated load?
• Does the server respond quickly enough to provide a good user experience?
• Is our application running efficiently?
• Do we need to scale up our server hardware, or scale out to multiple servers?
• Are there any pages or API calls that are particularly resource intensive?

Load testing is performed by running load testing software on one machine (or a cluster of machines) to generate a large amount of requests to a web server on a second machine (or other more complex web serving infrastructure). There are many such tools available, and we’ll look at some specific software later on. For now, we’ll discuss load testing in terms that will be relevant no matter what software you choose.

A common use of load testing software is to find the maximum requests per second that a server can handle. This is done by sending as many requests as possible to a server and seeing how many it can return successfully.

This is useful as a first step to understanding your server’s maximum capacity, but it doesn’t give us much information about latency and the actual day-to-day performance that your users will experience. A heavily loaded server may be able to return a thousand responses per second, but if each response takes ten seconds, your users will likely be unhappy.

The graph below shows a view of the relationship between throughput (responses per second) and latency:

This is just an example, and every setup will have a unique response profile, but the general trend is that higher load (more requests per second) results in higher latency. To get a more real-world idea of our server’s latency at a given load, we’ll need to test multiple times at different request rates. Not all load testing software is capable of this, but later on we’ll discuss , a command line load testing tool that can perform this function.

What is a reasonable latency target?

Though website load times in the 2–5 second range are common, the portion of that time attributed to web server latency is typically around 50–200 milliseconds. What is right for you and your site depends on too many factors (your audience, market, purpose of the site, is the site user-facing or an API service, etc.) to give a more concrete target number, but keep in mind most studies show that every little bit of speed counts, and even “imperceptible” improvements lead to better results when viewed in the aggregate.

Now that we have a general understanding of load testing, let’s discuss a specific plan to explore the performance of our server.

Анализ результатов

Результатами для анализа как правило являются замеры времен отклика по операциям (счетчики, установленные в скрипте), количество успешно выполненных операций в течении теста и метрики использования серверного оборудования.
Чаще всего имеет смысл анализировать результаты времен отклика по значению 90 персентелей. Например, если среднее время отклика по какой либо тестируемой операции 10 секунд, по 90 процентам — 25 секунд и максимум, скажем, равен 39 секундам то это означает что 90 процентов времен отклика по данной операции не превышает 25 секунд и только 10 процентов времен распределяются в диапазоне от 25 секунд до 39 секунд

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

Результатом тестирования может явиться решение о дальнейшей доработке Приложения, настройке (tuning) программного обеспечения или об изменении аппаратной конфигурации оборудования для лучшего соответствия бизнес требованиям по производительности.

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

Tags:

View the discussion thread.

blog comments powered by DISQUS

How to do Load Testing

The load testing process can be briefly described as below —

1. Create a dedicated Test Environment for load testing
2. Determine the following
3. Load Test Scenarios
4. Determine load testing transactions for an application
   • Prepare Data for each transaction
   • Number of Users accessing the system need to be predicted
   • Determine connection speeds. Some users may be connected via leased lines while others may use dial-up
   • Determine different browsers and operating systems used by the users 
   • A configuration of all the servers like web, application and DB Servers
5. Test Scenario execution and monitoring. Collecting various metrics
6. Analyze the results. Make recommendations
7. Fine-tune the System
8. Re-test

Load Ninja

Load Ninja – это относительно несложный в использовании инструмент
нагрузочного тестирования, который позволяет пользователям создавать сложные
нагрузочные тесты без использования каких-либо скриптов. В результате
пользователи могут сократить время тестирования на 50% и заменить эмуляторы
нагрузки реальными браузерами.

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

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

Плюсы

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

Минусы

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

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

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

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

Load Ninja – это отличный инструмент
тестирования программного обеспечения для веб-разработчиков и тестировщиков ПО,
которые хотят реализовать процедуры тестирования без скриптов. Однако из-за
цены наиболее подходит  для среднего и
крупного бизнеса.

WebLOAD

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

Плюсы

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

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

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

Уровни тестирования

Модульное тестирование — это процесс исследования ПО, при котором тестируется минимально возможный компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

Ссылки:

Интеграционное тестирование — это процесс исследования ПО, при котором тестируется интерфейсы между компонентами или подсистемами.

Ссылки:

Википедия. Интеграционное тестирование.

Системное тестирование — это процесс исследования ПО, при котором тестируется интегрированная система на её соответствие требованиям заказчика. Альфа и Бета тестирование относятся к подкатегориям системного тестирования.

Ссылки:

Направления тестирования производительности

В тестировании производительности различают следующие направления:

• нагрузочное (load)
• стресс (stress)
• тестирование стабильности (endurance or soak or stability)
• конфигурационное (configuration)

Возможны два подхода к тестированию производительности программного обеспечения:

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

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

Основная статья: Нагрузочное тестирование

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

Стресс-тестирование

Основная статья: Стресс-тестирование программного обеспечения

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

Тестирование стабильности

Основная статья: Тестирование стабильности

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

Конфигурационное тестирование

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

Матричное описание метрик

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

Тип	VU	Response Time	Requests	Errors	Throughput
VU	Позволяет сравнить планируемую нагрузку с реальной	Показывает, как увеличение пользователей сказывается на росте времени отклика при закрытой модели	Можно увидеть увеличение RPS/TPS/HITS с увеличением количества пользователей, а также уменьшение в связи с выходом пользователей или стабилизацией подаваемой нагрузки	Показывает, при каком числе VU происходит рост ошибок. Не всегда показателен, так как в открытой модели сложно коррелировать графики	Метрики должны полностью коррелировать, так как рост пользователей приводит к росту объема данных, отправляемых ими. Расхождения или резкие выбросы являются поводами для дальнейшего изучения
Response Time		Показывает, как быстро сервер отвечает на наши запросы. Основная метрика	Показывает среднее время, за которое обрабатываются все транзакции или запросы на всем протяжении теста	Можно увидеть, как увеличение ошибок влияет на рост времени ответа приложения	Рост времени ответа часто связан с увеличением количества отправленных данных (Throughput). Если на графике замечен рост Response Time, а Throughput при этом остается прежним, это указывает на проблемы с сетью или с приложением: где-то начинает копиться очередь запросов
Requests			Показывает, сколько запросов выдерживает система в секунду, минуту и т. д.	Позволяет найти значение интенсивности, после которой появляются ошибки. Удобно для определения SLA	Позволяет контролировать рост объема данных и количества запросов. Эти метрики должны коррелировать. Появление проблем может свидетельствовать, что мы отправляем неверные запросы
Errors				Позволяет оценить рост числа ошибок и тип ошибок, которые проявляются под нагрузкой	Можно найти объем данных, при котором приложение начинает генерировать ошибки
Throughput					Показывает, какой объем данных приложение может прокачать через себя за заданный промежуток времени

View the discussion thread.

blog comments powered by DISQUS

Apache Bench

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

Команда выполнила 10 000 запросов в 50 потоков и, кроме всего прочего, показала скорость и обработанное количество запросов:

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

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

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