rps что это такое
Rps что это такое
Смотреть что такое «RPS» в других словарях:
RPS — is a three letter abbreviation that may refer to:* Racial Preservation Society, a defunct British pressure group * Reactor Protective System, a set of safety components in a nuclear power plant * Redundant Power System, a series of Cisco UPS… … Wikipedia
RPS — (от англ. Role Play Strategy) стратегия с ролевыми элементами. Как правило представляет собой стратегию с возможностью найма и прокачки героя по тому же принципу, что и в RPG. Содержание 1 Представители 1.1 Heroes of Might and Magic 1.2 … Википедия
rps — abreviatura 1. Revoluciones por segundo … Diccionario Salamanca de la Lengua Española
rps — abbrev. revolutions per second … English World dictionary
RPS — Die Abkürzung RPS steht für: rps (engl. revolutions per second), dt. Umdrehungen pro Sekunde, siehe dazu Rpm (Einheit) Rights Protection System Rock Paper Scissors (dt. Schere, Stein, Papier), ein Glücksspiel Referenzpunktsystem (Messtechnik)… … Deutsch Wikipedia
Rps — Real Private Server Pour les articles homonymes, voir RPS. Le Real Private Server (ou serveur privé réel) est un type de serveur informatique lancé en janvier 2008 par l hébergeur français OVH et dont la particularité est l absence de disque dur… … Wikipédia en Français
RPS — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français
RPS — abbreviation Usage: often not capitalized revolutions per second * * * revolutions per second. Also, r.p.s. * * * abbrev Royal Photographic Society * * * r.p.s. or rps (no periods), revolutions per second. * * * (also r.p.s.) abbr. revolutions… … Useful english dictionary
rps — abbreviation revolutions per second … New Collegiate Dictionary
rps — revolutions per second. Also, r.p.s. * * * … Universalium
RPS — Redundant Power Supply (Academic & Science » Electronics) Rock Paper Scissors (Community » Sports) *** Redundant Power System (Computing » Networking) * Rounds Per Second (Governmental » Military) * Rounds Per Second (Community » Law) * Ring… … Abbreviations dictionary
Rps что это такое
блок дистанционной обработки
—
[Е.С.Алексеев, А.А.Мячев. Англо-русский толковый словарь по системотехнике ЭВМ. Москва 1993]
Тематики
инспектор по радиологической защите
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
переключение радиосистемы на резерв
Функция RPS обеспечивает m резервных радиостволов для n STM-N сигналов, предназначенных для предотвращения потерь сигнала, обусловленных изменениями параметров радиостволов как из-за аварий оборудования, так и из-за временного ухудшения или потери сигнала, вызванных влиянием условий распространения радиоволн (например, влияние дождя или многолучевости) в пределах радиорелейного участка (резервирования), состоящего из ряда регенераторных ретрансляционных секций (МСЭ-R F.750-4).
[http://www.iks-media.ru/glossary/index.html?glossid=2400324]
Тематики
радиоизотопный энергоисточник
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
Служба радиологической защиты (США)
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
система аварийной защиты ядерного реактора
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
система радиационной защиты
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
Тематики
Синонимы
служба параметров кольца
СПК
Концептуальный элемент управления сетью, представляющий собой функциональный логический объект, который содержится в одном узле или группе узлов, подключенных к кольцевой сети с маркерным доступом, и отвечает за инициацию набора операционных параметров в станциях конкретной сети.
[ГОСТ 29099-91]
Тематики
Обобщающие термины
Синонимы
экран для ограничения распространения пламени
—
[Я.Н.Лугинский, М.С.Фези-Жилинская, Ю.С.Кабиров. Англо-русский словарь по электротехнике и электроэнергетике, Москва, 1999 г.]
Тематики
эталонная точка линии на общем выходе элемента сети с DWDM
(МСЭ-T G.698.1).
[http://www.iks-media.ru/glossary/index.html?glossid=2400324]
Тематики
Полезное
Смотреть что такое «RPS» в других словарях:
RPS — is a three letter abbreviation that may refer to:* Racial Preservation Society, a defunct British pressure group * Reactor Protective System, a set of safety components in a nuclear power plant * Redundant Power System, a series of Cisco UPS… … Wikipedia
RPS — (от англ. Role Play Strategy) стратегия с ролевыми элементами. Как правило представляет собой стратегию с возможностью найма и прокачки героя по тому же принципу, что и в RPG. Содержание 1 Представители 1.1 Heroes of Might and Magic 1.2 … Википедия
rps — abreviatura 1. Revoluciones por segundo … Diccionario Salamanca de la Lengua Española
rps — abbrev. revolutions per second … English World dictionary
RPS — Die Abkürzung RPS steht für: rps (engl. revolutions per second), dt. Umdrehungen pro Sekunde, siehe dazu Rpm (Einheit) Rights Protection System Rock Paper Scissors (dt. Schere, Stein, Papier), ein Glücksspiel Referenzpunktsystem (Messtechnik)… … Deutsch Wikipedia
Rps — Real Private Server Pour les articles homonymes, voir RPS. Le Real Private Server (ou serveur privé réel) est un type de serveur informatique lancé en janvier 2008 par l hébergeur français OVH et dont la particularité est l absence de disque dur… … Wikipédia en Français
RPS — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français
RPS — abbreviation Usage: often not capitalized revolutions per second * * * revolutions per second. Also, r.p.s. * * * abbrev Royal Photographic Society * * * r.p.s. or rps (no periods), revolutions per second. * * * (also r.p.s.) abbr. revolutions… … Useful english dictionary
rps — abbreviation revolutions per second … New Collegiate Dictionary
rps — revolutions per second. Also, r.p.s. * * * … Universalium
RPS — Redundant Power Supply (Academic & Science » Electronics) Rock Paper Scissors (Community » Sports) *** Redundant Power System (Computing » Networking) * Rounds Per Second (Governmental » Military) * Rounds Per Second (Community » Law) * Ring… … Abbreviations dictionary
Как оценить ёмкость сервиса и не упасть под нагрузкой
Рано или поздно любому растущему сервису приходится оценивать свои технические возможности. Сколько посетителей мы в силах обслужить? Какова ёмкость (она же capacity) системы? Не добрались ли мы до предела и не упадём ли, если привлечём ещё несколько тысяч пользователей? Сколько дополнительных вычислительных ресурсов заложить в бюджет на следующий год, чтобы соответствовать планам роста?
Ответы можно получить аналитическим путём, адресовав вопросы опытному разработчику/DevOps/SRE/админу. Достоверность оценки зависит от огромного числа факторов: начиная с темпов наполнения системы функциональностью и графа взаимосвязей между компонентами и заканчивая временем, которое эксперт с утра провёл в пробке. Чем сложнее система — тем больше сомнений в адекватности аналитической оценки.
Меня зовут Максим Куприянов, вот уже пять лет я работаю в Яндекс.Маркете. Сегодня я расскажу читателям Хабра, как мы учились оценивать ёмкость наших сервисов и что из этого вышло.
Выходим на позицию
Структура компонентов Маркета довольно сложна, так что мы решили оценить ёмкость только самых крупных и дорогих в масштабировании сервисов. При этом ежедневное количество запросов на них должно явно зависеть от размера дневной аудитории Маркета (daily active users, DAU). Почему именно от DAU? Да потому что аналитики, строя прогнозы на месяцы и годы вперёд, всегда подсчитывают будущий размер аудитории, а мы этим приятным обстоятельством как раз и воспользуемся.
Теперь поговорим о том, без чего точно не построить объективные оценки: о метриках работы сервиса. Если число запросов на сервис зависит от DAU — значит, нам точно понадобится метрика «число запросов в секунду» (requests per second, RPS). Кроме того, чтобы оценить качество работы сервиса, нужно знать процент ошибок и времён ответа (таймингов запросов). Ошибкой будем считать ответ с HTTP-кодом от 500 и выше. Ошибки из диапазона 4xx клиентские и в нормально работающей системе обычно ничего не говорят о проблемах сервиса. Что касается таймингов, то тут у нас принято рассчитывать и хранить 80-й, 95-й, 99-й и 99,9-й перцентили времён ответа, но конкретный набор может немного отличаться от сервиса к сервису.
Итак, у нас есть метрики частоты запросов, процента ошибок и набор перцентилей времени ответа. А ещё мы знаем DAU сервиса на каждый день и на будущие периоды (в виде прогноза). Учитывая, что усреднённые паттерны поведения пользователей не слишком меняются день от дня, допустим следующее: зная RPS в наиболее активный период рабочего дня (пиковое RPS), мы можем спрогнозировать пиковое RPS на будущие периоды, при условии, что у нас есть прогноз DAU. И наоборот: если мы знаем, сколько запросов в секунду выдерживает система, не нарушая договорённости по времени ответа и проценту ошибок, то можем оценить, какой объём аудитории сможем обслужить, т. е. знаем ёмкость системы.
Отлично, мы определились с задачей: зафиксировать в виде договорённостей тайминги ответа и процент ошибок и найти максимальное RPS, которое система выдержит при этих условиях. Как будем решать?
Стреляем по мишени
Вот классический подход к решению задачи: собираем тестовый полигон, берём access-логи системы из production-окружения, делаем из них патроны и обстреливаем систему, повышая частоту запросов, пока полигон не покажет значимую деградацию по таймингам ответа и/или ошибкам. В этот момент останавливаемся и фиксируем частоту запросов (то самое RPS). Победа? Как бы не так. И вот почему:
Имитируем реальность
Общая идея такова: скопируем часть трафика с балансеров на площадку, где соберём полный аналог production-окружения в миниатюре и, регулируя объём копируемого трафика, станем искать точку деградации. Идея красивая, и мы в Маркете так делаем, чтобы протестировать новую функциональность и сравнить поведение новых версий со старыми. Мой коллега Евгений в подробностях рассказывал об этом — см. раздел о теневом кластере. Но тут тоже есть очевидные сложности:
Тестируем прямо в production
И вот мы наконец добрались до вкусного. Для каждого тестируемого компонента мы поднимаем в production отдельный экземпляр, частоту запросов на который регулируем с балансировщика с высокой точностью. В прошлый раз читатели нас спрашивали: «Хватает ли возможностей HAProxy? Не возникала ли необходимость писать что-то своё?». Так вот, это тот самый редкий случай, когда не хватило и пришлось писать.
При этом есть отдельный сервис, который пристально наблюдает за метриками нагружаемого экземпляра и, когда показатели приближаются к критическим величинам, прикрывает вентиль на балансировщике, уменьшая частоту запросов. Если же сервис работает в допустимых границах — вентиль, наоборот, открывается. Конечно, пороги таймингов и ошибок при нагрузке живого сервиса заметно более консервативны (обычно на 5–10%), чем на полигоне, ведь мы не хотим ухудшать взаимодействие с пользователями. Таким образом, нагружаемый экземпляр всегда работает на пределе возможностей. Эти показатели мы фиксируем. А дальше уже арифметика: мы знаем количество ядер сервиса под нагрузкой на каждый момент, знаем DAU за вчерашний день. Из этого считаем утилизацию, резервы по ёмкости и варианты поведения системы при отключении той или другой локации. Всё это ложится в базу, откуда строятся красивые графики. На основании этих данных при снижении ёмкости ниже заложенного порога срабатывают алерты.
Давайте посмотрим на графики
Вот так мы регулируем подачу трафика на тестируемый инстанс. Шаг может быть любым кратным 1 RPS. На графике для иллюстрации смоделирован подъём с трёхминутным интервалом: сначала от 650 до 1K RPS с шагом 50, а потом от 200 до 1K с шагом 100. Напомню, это настоящий пользовательский трафик, на который клиенты получали ответы.
Здесь показано RPS на три инстанса: один под нагрузкой и два контрольных. Для испытуемого искусственно задали верхний предел — 600 RPS. Сервис может и больше, но становится слишком неустойчивым и зависимым от внешних воздействий. Хорошо видно, что в первой половине дня запросы на сервис в среднем более тяжёлые и инстанс не может на приемлемых условиях достичь пиковой ёмкости, но ближе к вечеру всё приходит в норму. Всплески и пропуски на графике — это рестарты инстансов для выкладки релизов и прочих обновлений (все они под балансировкой, никто не пострадал). А ступенчатые корректировки RPS на испытуемом — как раз работа алгоритма, который ищет предел возможностей.
Хорошо видна частота запросов на сервис и нагрузка, которую может выдержать один инстанс.
А тут мы пересчитываем всё в проценты утилизации. На графике видно, что сервис был довольно сильно нагружен и при отключении одной из локаций возникли риски уйти за SLA. Но сейчас уже всё в порядке: в сервис добавили ресурсы, утилизация вернулась в приемлемые границы.
Таким образом, нагрузочное тестирование в production позволяет быстро оценить ёмкость системы и спрогнозировать потребление ресурсов на будущие периоды. При этом система фактически не добавляет заметных расходов и можно спокойно работать со stateful-сервисами, так как мы не порождаем новый трафик, а лишь аккуратно перераспределяем тот, что есть. Ну и напоследок: для работы, как правило, не требуется изменять код само́й подопытной системы, что позволяет тестировать даже legacy-приложения.
Рефлексируем
В Маркете эта методика работает уже не первый год, и мы можем поделиться наблюдениями и рекомендациями:
Методология и практика нагрузочного тестирования. Опыт Miro
Меня зовут Дмитрий Винокуров и я работаю инженером по нагрузочному тестированию в Miro. Я хочу рассказать о личном опыте и опыте нашей команды в развитии направления нагрузочного тестирования (для краткости НТ). В статье я расскажу самые основы НТ, как на эти основы ложится наш процесс и на какие конкретные шаги он делится. Наш опыт местами может быть специфическим, но по большей части он будет применим ко многим компаниям, разрабатывающим веб-приложения и не только.
Новичкам статья полезна будет тем, что содержит введение в нагрузочное тестирование и базовый план действий, а опытным людям покажет пример того, как делают НТ в другой компании, и даст возможность почерпнуть что-то новое для себя или наоборот даст повод поделиться своим опытом, поэтому буду рад комментариям и примерам из вашего опыта.
Описываемый подход основывается на нашем опыте и множестве просмотренных и прочитанных материалов. Подобный доклад делался на конференции DUMP в Екатеринбурге 14 мая 2021 г., эта статья представляет собой значительно дополненный и переработанный вариант выступления.
Автор арта на «обложке» — Orest Terremoto.
Содержание
О Miro и об авторе
Наша компания разрабатывает веб-приложение Miro — онлайн платформу для совместной работы с множеством интеграций. В основе используется бесконечная интерактивная доска, на которую можно добавлять текст, схемы, изображения, стикеры, таблицы, эмоджи, майндмапы, связывать с тикетами в Jira, создавать канбаны и многое другое. Приложение содержит удобные инструменты для проведения мозговых штурмов, воркшопов, планирования проектов, дизайна новых продуктов и сервисов, фасилитации Agile встреч, презентаций и многого другого.
Цель Miro — дать возможность распределённым командам работать так эффективно, как будто они находятся в одном помещении.
Что особенно важно относительно темы статьи — Miro поддерживает совместную работу в реальном времени большого числа пользователей, в этом самая основа нашей платформы. Это причина, почему нам особенно нужно нагрузочное тестирование. Когда люди собираются у одной оффлайн доски в офисе — они не испытывают никаких задержек в коммуникации и в работе с доской, так же и у нас, только в намного больших масштабах.
В прошлом году внезапно множество людей перешло на удалёнку по известным причинам и им понадобились инструменты для удалённой работы, подобные нашему. Количество зарегистрированных пользователей в Miro с начала 2020 до весны 2021 выросло в 8 раз, другие метрики росли схожим образом. Поэтому нам понадобилось срочно развивать все имеющиеся наработки по нагрузочному тестированию. Причём это не краткосрочная задача, а, учитывая перспективы рынка, весьма долгоиграющая. Что получилось и что ещё предстоит — об этом и будет статья.
Сам я уже около 12 лет занимаюсь разработкой ПО и последние несколько лет — разработкой инструментов автоматизации тестирования. Ещё я активно участвую в работе над публичной базой знаний по НТ вместе с соответствующим сообществом, ссылки про это и многое другое будут в конце статьи.
Что такое нагрузочное тестирование?
Нагрузочное тестирование — это тип тестирования, в котором мы проверяем, соответствует ли наша система поставленным нефункциональным требованиям к производительности при работе под высокой нагрузкой в различных сценариях. Это намного сложнее, чем unit тестирование, где всё просто работает или нет. При нагрузочном тестировании снимается целый ряд метрик, и даже задача проверки на соответствие требованиям уже является непростой. Существенные трудности состоят также в том, как воспроизвести поведение пользователей с прода, как воспроизвести сам прод, в том числе базу, и как поставить тестирование так, чтобы ручная работа была минимальной.
Тестирование вообще — это способ узнать об ошибках не от конечных пользователей, а раньше, и тем самым избежать потерь, репутационных и прочих. Нагрузочное тестирование — это способ подготовиться к высоким нагрузкам заранее и сделать так, чтобы большое число запросов от множества пользователей было благом, а не головной болью. Причин для бурного роста может быть множество и отказываться от подготовки к таким сценариям значит существенно повышать риск выхода из строя вашей системы в тот момент, когда она стала особенно нужна людям.
Что нужно для нагрузочного тестирования?
Итак, мы определились, НТ нам нужно, теперь перед его проведением необходимо наличие ряда ресурсов:
Этапы нагрузочного тестирования
Мы собрали то, что необходимо для НТ. Перейдём к плану действий.
С чего начинали нагрузочное тестирование в Miro
К росту нагрузки мы начали готовиться задолго до пандемии и вот что у нас было:
С какими препятствиями столкнулись при развитии нагрузочного тестирования в Miro
НТ, особенно для сложной системы, — задача непростая. Чем глубже мои коллеги погружались в неё, тем больше возникало сложностей.
Роли, которые в Miro решили воспитывать в инженерах команды нагрузочного тестирования
Итак, мы столкнулись с рядом трудностей в проведении НТ и конечно можно было подумать «а давайте просто наймём больше QA инженеров» и действительно надо было нанимать людей специально для НТ, но вопрос на самом деле шире. QA инженеров нанять недостаточно, учитывая сложность этого направления необходимо было строить многопрофильную команду. Причём часть ролей отводилась будущим сотрудникам, а часть — имеющимся.
Так почему нам было недостаточно просто QA? Главная причина — прогнозируемый уровень сложности задач по НТ. У нас несколько десятков команд, все разрабатывают компоненты, которые должны работать в соответствии с требованиями по производительности в составе сложной системы. Но у каждой компании свой масштаб разрабатываемых систем. Кому-то может хватить просто одного человека, который умеет в JMeter, и может даже особо большого кластера для подачи нагрузки не понадобится. Кому-то нужно будет значительно больше, чем надо было нам. Всё зависит от уровня сложности системы.
С ростом скорее всего происходит более узкая специализация, но у нас для инженеров НТ было решено развивать следующие роли:
Некоторые общие принципы работы QA в Miro
В нашей компании есть QA гильдия, объединяющая QA инженеров из разных функциональных команд и инженеров, разрабатывающих и отвечающих за общие инструменты обеспечения качества. И раз НТ у нас — это часть QA, а для QA уже были сформулированы и применялись ряд принципов, то и к НТ они были применены.
Вот ключевые из этих принципов:
Распределённая команда нагрузочного тестирования в Miro
Если ранее я рассказывал об опыте коллег, то в описываемом далее я принимал уже непосредственное участие. В компанию вместе со мной были взяты люди, которые занимались уже только НТ. И вот какую команду мы строили и какими задачами занимались.
Процесс нагрузочного тестирования в Miro
Шаг 1/6. Детализация требований
Мы рассмотрели, что такое НТ и посмотрели на то, как устроена распределённая команда НТ в Miro. Теперь пройдёмся по этапам НТ, наложенным на наш процесс. Начнём с самого важного этапа.
Ещё раз подчеркну, что к формулировке требований стоит подойти особенно ответственно. Без чёткого понимания, чего вы хотите от тестируемого приложения, дальше двигаться нельзя.
Источники требований
Выбор модели нагрузки
Различают две модели нагрузки:
Выбор типа теста
Для разных требований нужны разные тесты. Вот основные примеры типов тестов:
Декомпозиция требований
«Cистема должна отвечать быстро при высокой нагрузке» – это плохое требование, слишком расплывчатое и оставляющее больше вопросов, чем определённости в том, как его проверять.
Более конкретное требование — «система должна обеспечивать столь же комфортный опыт использования как сейчас при росте нагрузке в X3 пользователей». Здесь указано, что такое «высокая нагрузка» — указано «X3 пользователей» и указано что опыт работы с системой должны быть «столь же комфортным как сейчас». Здесь есть на что опираться — на текущие показатели работы с системой.
Детализация означает конвертацию пользователей в RPS, основываясь на существующем и ожидаемом профилях использования. Такая конвертация уместна только для Stateless протоколов, как самые распространённые HTTP и HTTP, а для Stateful число подключенных клиентов может быть очень важно, как например для FTP, протокола работы с MySQL или некоторых банковских протоколов. Ещё один важный момент — не доверяйте средним значениям времён ответа, используйте персентили, т.к. среднее зачастую является плохой метрикой.
Вот примеры конкретных требований, которые могли быть получены из высокоуровнего и других источников данных:
Метрики
Есть очень хорошая книга по SRE от Google, где среди прочего описаны «4 золотых сигнала»:
Естественно, метрики всех четырёх типов тесно взаимосвязаны. Повышение трафика и соответственно насыщения со временем приведёт к росту времени ответа и ошибок. Резко упавшее время ответа может говорить о том, что у нас отказала БД и время ответа упало из-за того, что все запросы просто быстро завершаются с ошибкой.
Некоторые добавляют и другие показатели. Например, стабильность, которая показывает как долго система может работать без остановки и как быстро восстанавливается после проблем. Это сложный показатель и скорее его стоит отнести не к типам метрик, а к выводу отчёта после целого теста на стабильность. Подобная ситуация с доступностью и масштабируемостью. Есть ещё понятие критического ресурса, как компонента, от которого сильнее всего зависит качество работы всей системы.
APDEX
Индекс производительности приложений Application Performance inDEX (APDEX) может быть использован для преобразования ряда времён ответов в одно число, если определены диапазоны удовлетворительных, допустимых и недопустимых времён.
Значения APDEX легки в сравнении, но тяжелы в интерпретации.
Шаг 2/6. Подготовка тестового окружения
Сценарий готов, далее нужно подготовить целевую систему, которую тестовый сценарий будет проверять.
Тестовое окружение состоит из двух частей:
Шаг 3/6. Подготовка сценария
Мы определились с тем, что требуется от системы и как пользователи с ней работают, теперь это поведение нужно смоделировать в тестовом сценарии.
Эскиз на человеческом языке
Перед началом разработки хорошей практикой является создание эскиза сценария на «человеческом языке». Это поможет выразить, какое поведение пользователей планируется моделировать без траты времени на погружение в детали инструментов НТ. И инструмент тоже поможет подобрать, если такой вопрос стоит. А ещё, при составлении отчёта, такой эскиз поможет ревьюерам понять моделируемое поведение пользователей, не погружаясь в код.
Как было показано ранее, на этапе детализации требований мы разделяем активность пользователей на отдельные RPS. Иногда бывает нужно ещё объединять запросы в подобие подсценария.
Вот пример такого эскиза сценария:
Выбор инструмента
В данный момент у нас используется три инструмента для НТ:
Исследование
Ещё один шаг перед написанием кода — исследование того, как реальный фронтенд взаимодействует с бэкендом с помощью инструментов разработчика в браузере и попробовать несколько простых взаимодействий вручную, например через Postman.
Но иногда проще начать сразу с кода.
Данные
Было бы идеально тестировать на базе, подобной проду, и сбрасывать её перед каждым тестом, но это очень редко возможно из-за колоссальных объёмов данных и необходимости использования сложных инструментов чистки реальных данных. Поэтому у нас есть свой инструмент генерации данных, который умеет создавать в нужном объёме и в разумный срок основные бизнес-сущности: пользователей, команды, организации, доски разного размера, проекты и строить связи между ними. Этот генератор использует то же API, что и основное веб-приложение, и каждый сеанс генерации данных представляет собой немного хаотичный пример НТ. На выходе получается подробный лог и набор файлов, которые можно подключать к НТ сценариям.
Советы по коду
При написании кода может быть полезно следовать таким рекомендациям (известным, впрочем, и в других областях):
Шаг 4/6. Запуск теста и измерения
Целевая система готова, переходим к самому интересному — запуску теста и снятию метрик. Как я говорил ранее, НТ — это не функциональное тестирование, поэтому мы не просто снимаем ряд булевых показателей типа работает/не работает, а получаем целый ряд разнообразных метрик. Как разбираться в них — большая тема, здесь я затрону только некоторые моменты из неё.
Какие метрики снимать — есть базовый набор и есть специальные для каждого теста, это надо решать ещё при подготовке сценария и тестового окружения.
В ходе собственно выполнения теста у нас используются:
Шаг 5/6. Анализ
Паттерны
Давайте предположим, что сценарий выполнился и у нас множество метрик. На что стоит обратить внимание в первую очередь? Вот некоторые примеры. Первые три могут говорить или не говорить о неполадках, а последние вероятнее всего говорят о проблеме:
Пример
Разберём простейший пример, который может научить нескольким полезным вещам:
Шаг 6/6. Отчёт
Самое главное сделано. Остаётся подвести итоги и зафиксировать полученные в ходе нагрузочного тестирования знания. Особо хочу отметить, что НТ — это операция, требующая весьма существенных затрат труда, времени и прочих ресурсов. Поэтому вы явно захотите получить максимум пользы, потратив всё это.
Чтобы извлечь максимум пользы из проведённого НТ — нужен хороший отчёт. Каковы же критерии хорошего отчёта? НТ делается НТ инженерами не только и не столько для себя, а много для кого и для разных людей польза от отчёта зависит от наличия развёрнутых ответов на соответствующие вопросы:
Ещё один очень важный момент. Серьёзный подход требует регулярного НТ. Оно невозможно без автоматизации построения отчётов и степень этой автоматизации зависит от частоты проведения тестирования.
Результаты внедрения нагрузочного тестирования в Miro
Я рассказал о том, какие этапы НТ есть и как мы работаем на каждом из них.теперь перечислю, чего мы добились благодаря внедрению НТ в таком виде:
Планы в отношении нагрузочного тестирования в Miro
Несмотря на то, что было сделано многое, ещё больше предстоит. Вот планируемые направления развития:
Пожелания читателям
Напоследок пожелаю следующее:
Полезные ссылки
В ходе работ по НТ мной и моими коллегами были в том числе использованы источники из базы знаний, создание которой было инициировано русскоязычным QA Load сообществом и в которой я один из мейнтейнеров, также мы многое почерпнули и из самого чата этого сообщества. Ссылки: