Что такое tps нагрузка

Chirkov.net: блог

Субъективный взгляд на мир: мысли о работе и, иногда, о жизни…

Рубрикатор:

Свежие мысли:

Комментарии:

Поиск

Персональное:

Облако меток:

Реальная производительность ПЦ

Почти все вендоры проводять нагрузочные тестирования своих процессинговых систем на топовых серверах и хвастаются заоблачными показателями производительности в транзакциях в секунду. Сами по себе эти числа вызывают недоверие, ведь у некоторых, демонстрирующих на стенде производительность в тысячи TPS (transactions per second), реальные клиенты затыкаются на самом мощном оборудовании со 100-200 TPS (см.предыдущую запись). Расхождение реальных и «маркетинговых» цифр обусловлено методикой тестирования. Воссоздать реальную среду достаточно сложно (если не невозможно), да и пытаясь ее воссоздать модель можно реализовать с разной степенью реалистичности:

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

Собственно вернутся к этой теме меня заставил разговор с коллегой, который посетил China Union Pay. Как известно, на сегодня это уже крупнейшая (по количеству карт) платежная система, в рамках которой функционируют более 2,4 млрд.карт. Так вот во время его визита на демо-экранах в кабинетах мигали всякие там цифры и одна из них привлекла его внимание. Цифра колебалась в интервале 480-520 и оказалось, что это реальные TPS хоста China Union Pay. Товарищ не постеснялся и спросил о максимуме. Китайцы ответили, что максимально фиксируемые ими значения реальных транзакций составляли не более 800 TPS. Отсюда вопрос, если даже у китайцев нагрузка не достигает 1000 TPS, то на кого рассчитаны релизы про 3000-5000 TPS? Давайте считать честно 🙂

PS на вопрос на чьей платформе работает процессинговый центр китайцы сказали, что это внутренняя разработка, а не покупное решение…

4 комментария

Небольшое замечание. CUP недавно (ноябрь 2010 года) провели ребрейдинг и стали просто «Union Pay». Готовятся к выходу за пределы Китая?

Китай — не очень хороший показатель. Удельное использование карт (на время, на карту, на человека, на терминал) в Китае, прямо скажем, очень низкое.

Так чтобы Вы почувствовали разницу: в Китае в 2009 году было совершено 3.5 миллиарда платежей с помощью карт, а в США — 55 миллиардов.

Поэтому хоть у CUPа карт и много — нагрузка на совокупные хостовые мощности по сравнению с американской даже близко не сравнима и сравнима в ближайшие 20-30 лет не будет — даже при их миллиарде населения.

Вот для таких рынков как США и Западная Европа и нужны TPS в 3-5К — потому что там это имеет экономический смысл.

Я сам не вендор — занимаюсь аналитикой — мне можно верить 🙂 А то, что вендоры — «красавцы» — это факт. Причем все — думаю, что и Ваши маркетологи «поджигают» когда надо 🙂

Все-таки приятно читать в своем блоге не только собственные умные мысли:)

Приватбанк зафиксировал 560 реальных причем далеко не на самом TOPовом железе
http://www.plusworld.ru/daily/page1_19948.php
ПЦ ПриватБанка, полностью построенный на линейке продуктов TranzWare компании «Compass Plus », достиг рекордной для банковского сектора производительности, зафиксировав пиковую транзакционную нагрузку в 560 бизнес транзакций в секунду (TPS).
При этом в пиковую минуту средняя загрузка держалась на уровне 191 TPS, а в пиковый час на уровне 175 TPS. Данные показатели были достигнуты на оборудовании средней мощности и довольно простой конфигурации, где в качестве сервера базы данных используется IBM Power 770, в котором процессинговой системе TranzWare Online было предоставлено 21 ядро Power7 3.1GHz, а в качестве серверов приложений используются 3 сервера HP Proliant BL460c G6 2xQuadCore Intel Bloomfield 2933 MHz.

Вставить свои 5 копеек:

(c) Андрей Чирков

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

Источник

Определение: Транзакций в секунду (TPS)

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

Два примера, когда термин TPS был упомянут в СМИ:

Как рассчитать количество транзакций в секунду (TPS)

Чтобы рассчитать TPS, вы должны знать промежуток времени между блоками, средний размер транзакции и размер блока. Время между блоками – это среднее время, необходимое для создания нового блока в цепочке. Данный показатель для биткоина равен 10 минутам. Средний размер транзакции вам придется рассчитать. Размер блока – это размер блока в цепочке. Размер блока биткоина – 1 МБ.

Например, размер блока равен 1 МБ со средним размером транзакции в 1 Кб и временем между блоками в 30 секунд.TPS в таком случае будет равняться 33 (1 МБ/1 кб)/30 секунд=33).

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

С появлением Ethereum 2.0 дела у второй по величине крипто монеты и сети пойдут намного лучше.

Другие крипто монеты с более высоким значением TPS, чем у биткоина – Ripple (1500 транзакций), Bitcoin Cash (60 транзакций), Litecoin (56 транзакций) и Dash (48 транзакций).

TPS биткоина и фиатные деньги

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

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

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

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

Помимо Segwit, также существует Lightning Network. Он представляет собой автономное решение проблемы масштабируемости и низкого TPS. Сеть позволяет проводить транзакции вне блокчейна.

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

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

Подписывайтесь на Bybit в соц.сетях:

Источник

Что такое tps нагрузка

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

На сегодня в промышленности приняты следующие типы характеристик нагрузки, генерируемой приложением базы данных: «легкая», «средняя», «тяжелая» и «очень тяжелая». Категория «легкая» приравнивается к рабочим нагрузкам, которые доминируют в операциях, подобным транзакциям дебит/кредит, определенным в оценочных тестах TPC-A. Нагрузками «средней» тяжести считаются транзакции, определенные стандартом теста TPC-C. Тяжелыми рабочими нагрузками считаются нагрузки, которые ассоциируются с очень большими приложениями, такими как Oracle*Financials. Такие нагрузки по крайней мере в 5-10 раз тяжелее, чем принятые в тесте TCP-A, а некоторые являются даже еще более тяжелыми.

Основным классом приложений, которые попадают в категорию «очень тяжелой» нагрузки, являются системы поддержки принятия решений. Из-за очень больших различий в природе запросов к системе поддержки принятия решений, администраторы баз данных или самой СУБД сталкиваются с очень большими проблемами по обеспечению широкомасштабной, полезной оптимизации. Запросы к системе поддержки принятия решений часто приводят к формированию существенно большего числа запросов к нижележащей системе из-за необходимости выполнения многонаправленных соединений, агрегатирования, сортировки и т.п. Тест TPC-D был специально разработан для оценки работы приложений поддержки принятия решений.

Что такое TPC

В компьютерной индустрии термин транзакция (transaction) может означать почти любой вид взаимодействия или обмена информацией. Однако в мире бизнеса «транзакция» имеет вполне определенный смысл: коммерческий обмен товарами, услугами или деньгами. В настоящее время практически все бизнес-транзакции выполняются с помощью компьютеров. Наиболее характерными примерами систем обработки транзакций являются системы управления учетом, системы резервирования авиабилетов и банковские системы. Таким образом, необходимость стандартов и тестовых пакетов для оценки таких систем все больше усиливается. До 1988 года отсутствовало общее согласие относительно методики оценки систем обработки транзакций. Широко использовались два тестовых пакета: Дебет/Кредит и TPI. Однако эти пакеты не позволяли осуществлять адекватную оценку систем: они не имели полных, основательных спецификаций; не давали объективных, проверяемых результатов; не содержали полного описания конфигурации системы, ее стоимости и методологии тестирования; не обеспечивали объективного, беспристрастного сравнения одной системы с другой.

Чтобы решить эти проблемы, и была создана организация TPC, основной задачей которой является точное определение тестовых пакетов для оценки систем обработки транзакций и баз данных, а также для распространения объективных, проверяемых данных в промышленности.

Работой TPC руководит Совет Полного Состава (Full Council), который принимает все решения; каждая компания-участник имеет один голос, а для того, чтобы провести какое-либо решение, требуется две трети голосов. Управляющий Комитет (Steering Committee), состоящий из пяти представителей и избираемый ежегодно, надзирает за работой администрации TPC, поддерживает и обеспечивает все направления и рекомендации для членов Совета Полного Состава и Управляющего Комитета. В составе TPC имеются два типа подкомитетов: постоянные подкомитеты, которые управляют администрацией TPC, осуществляют связи с общественностью и обеспечивают выпуск документации; и технические подкомитеты, которые формируются для разработки предложений по оценочным тестам и распускаются после того, как их работа по разработке завершена.

TPC определяет и управляет форматом нескольких тестов для оценки производительности OLTP (On-Line Transaction Processing), включая тесты TPC-A, TPC-B, TPC-C, TPC-D и TPC-E. Как уже отмечалось, создание оценочного теста является ответственностью организации, выполняющей этот тест. TPC требует только, чтобы при создании оценочного теста выполнялись определенные условия. Хотя упомянутые тесты TPC не представляют собой тесты для непосредственной оценки производительности баз данных, системы реляционных баз данных являются ключевыми компонентами любой системы обработки транзакций.

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

Тест TPC-A определяет пропускную способность системы, измеряемую количеством транзакций в секунду (tps A), которые система может выполнить при работе с множеством терминалов. Одной из неопределенностей старого теста Дебет/Кредит, которая часто использовалась поставщиками систем, была возможность подгонки соотношений между объемами таблиц СЧЕТ/ФИЛИАЛ/КАССИР, позволяющая обойти узкие места в подсистемах ввода/вывода и блокировок. В тесте TPC-A (а также в тесте TPC-B) соотношение межу количеством строк в таблицах СЧЕТ, ФИЛИАЛ и КАССИР строго специфицировано и для каждого сообщаемого в отчете уровня tpsA (tpsB) размер базы данных как минимум должен быть следующим:

СЧЕТ 100000 * tpsmin

Количество терминалов 10 * tpsmin,

где tpsmin должно быть больше, чем приводимый в отчете рейтинг системы. Таким образом, для системы, выполняющей 2000 транзакций в секунду, таблица СЧЕТ должна содержать 200 миллионов записей и т.д. Кроме того, должно быть гарантировано, что представленная в отчете скорость транзакций на специфицированной системе должна устойчиво поддерживаться минимально в течение 8-часового периода непрерывной работы системы (хотя реально измерения на тесте могли проводиться и в течение только одного часа). Тест TPC-A требует наличия внешней памяти для хранения информации об истории всех транзакций, накапливающейся в течение 90 дней в предположении о сохранении установившейся скорости работы в течение 8-часового рабочего дня.

Тест TPC-A может выполняться в локальных или региональных вычислительных сетях. В этом случае его результаты определяют либо «локальную» пропускную способность (TPC-A-local Throughput), либо «региональную» пропускную способность (TPC-A-wide Throughput). Очевидно, эти два тестовых показателя нельзя непосредственно сравнивать. Спецификация теста TPC-A требует, чтобы все компании полностью раскрывали детали работы своего теста, свою конфигурацию системы и ее стоимость (с учетом пятилетнего срока обслуживания). Это позволяет определить нормализованную стоимость системы ($/tpsA).

TPC-B измеряет пропускную способность системы в транзакциях в секунду (tpsB). Поскольку имеются существенные различия между двумя тестами TPC-A и TPC-B (в частности, в TPC-B не выполняется эмуляция терминалов и линий связи), их нельзя прямо сравнивать. На рис. 2.2 показаны взаимоотношения между TPC-A и TPC-B.

Тестовый пакет TPC-C с точки зрения реальных потребностей потребителей сделал огромный шаг вперед по отношению к тестам TPC-A и TPC-B. Хотя по своей сути он также моделирует оперативную обработку транзакций, его сложность по крайней мере на порядок превышает сложность тестов A и B: он использует несколько типов транзакций, более сложную базу данных и общую структуру выполнения. Тест TPC-C моделирует прикладную задачу обработки заказов. Он моделирует достаточно сложную систему OLTP, которая должна управлять приемом заказов, управлением учетом товаров и распространением товаров и услуг. Тест TPC-C осуществляет тестирование всех основных компонентов системы: терминалов, линий связи, ЦП, дискового в/в и базы данных.
TPC-С специфицирует время обдумывания и ввода с клавиатуры, которые обычно программируются в RTU при проведении испытаний.

Рис. 2.2. Типовая среда обработки транзакций и соответствующие оценочные тесты TPC.

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

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

TPC-C Results

Таким образом, рейтинг в 10000 tpmC MQTh предполагает примерно 0.5 терабайт внешней памяти!

Сравнительно недавно (см. ComputerWorld-Moscow, N15, 1995) TPC объявил об отмене тестов TPC-A и TPC-B. Отныне для оценки систем будут применяться существующий тестовый пакет TPC-C, новые тесты TPC-D и TPC-E, а также два еще полностью не разработанных теста. Представленный в первом квартале 1995 года тест TPC-D предназначен для оценки производительности систем принятия решений. Для оценки систем масштаба предприятия во втором квартале 1995 года TPC должен был представить тест
TPC-E и его альтернативный вариант, не имеющий пока названия. Кроме того, TPC продолжает разработку тестовых пакетов для оценки баз данных и систем клиент/сервер. Первые результаты, полученные с помощью этих новых методов, уже начали публиковаться.

Источник

Анализ результатов нагрузочного тестирования

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

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

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

Мы в Тинькофф активно используем инструмент Gatling, поэтому на его примере расскажем, как создать отчет вашей мечты и куда следует смотреть при его анализе. Также сразу хочу заметить, что почти все графики, описанные в статье, можно получать в режиме онлайн с помощью связки вашего инструмента с Grafana. Это наиболее удобный инструмент для создания отчетов «на лету», с помощью сконфигурированного заранее дашборда. Более того, это позволяет более быстро создать почти любой график на основе отправленных вами данных. Уже сейчас есть готовые дашборды почти для всех инструментов нагрузочного тестирования. Графики для других инструментов — MF LoadRunner и Apache JMeter — тоже будут приведены, их анализ строится по аналогии с Gatling.

Основные метрики

Индикаторы

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

Пороги для перехода из группы в группу задаются заранее на основе экспертной оценки или SLA (нефункциональных требований). Например, может быть три группы:

Метод APDEX позволяет использовать индикаторы в регрессионном тестировании для сравнения релизов: так сразу видно, насколько хуже или лучше стал релиз в общем. К сожалению, этого графика нет из коробки в MF LoadRunner и Apache JMeter, но его легко создать с помощью дашборда Grafana.

Таблица с временем отклика

По умолчанию Gatling строит таблицу по перцентилям, среднему и максимальному времени отклика, а также по ошибкам. По ней отслеживается выход за пределы SLA (превышение нефункциональных требований). Обычно в SLA указывают перцентили 95, 99 и процент ошибок. Таким образом таблица позволяет получить быструю оценку результатов тестирования.

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

HTML Gatling Report
MF LoadRunner также создает таблицу сам в блоке Analysis Summary Report и называется Transaction Summary
В Apache JMeter эти данные можно найти в Aggregate Report

График Virtual Users

Обычно измеряется в штуках и показывает, как пользователи заходят в приложение, тем самым иллюстрируя реальный профиль нагрузки. Стоит сразу оговориться, что для MF LoadRunner и Gatling эти графики показывают количество Virtual Users, а для Apache JMeter — количество Thread.

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

HTML Gatling Report
В MF LoadRunner этот график называется Running Vusers
В Apache JMeter график называется Active Threads Over Time и не входит в стандартную поставку, но его можно бесплатно скачать на сайте JMeter-Plugins.org

График Response Time

Чаще всего измеряется в миллисекундах — показывает время ответа на запросы к приложению. Время отклика не должно превышать SLA. Этот график является основным инструментом для поиска точек деградации при проведении нагрузочного тестирования.

Если на графике видны пики, значит, в этот момент приложение не отвечало по какой-то причине — это может являться отправной точкой для дальнейших исследований. Время отклика должно быть равномерным, без пиков для всех операций на протяжении всей ступени нагрузки, а также коррелировать с увлечением нагрузки. Gatling не содержит график «чистого» (среднего, не агрегированного) времени отклика, в отличие от других инструментов.

Кроме графика времени ответа каждого запроса удобно показывать также линию с суммарным временем ответа (Total Response Time). Если наложить график подаваемой нагрузки (VU/RPS), можно отслеживать корреляцию с увеличением времени отклика от увеличения подаваемой нагрузки (VU/RPS). В Apache JMeter этот график называется Response Times vs Threads.

Далее пойдут графики, на которых может быть множество линий, каждая из которых отображает свой сценарий или запрос. Если у вас сложный тест со множеством операций и нелинейным профилем, советуем отражать в отчете лишь наиболее показательные запросы или группы запросов. Как вариант, можно отражать лишь запросы, превысившие SLA/SLO, чтобы не засорять график и отчет.

В MF LoadRunner график называется Average Transaction Response Time и показывает среднее время для транзакций
Для Apache JMeter график существует в двух вариантах в расширенном пакете с сайта JMeter-Plugins.org и называется Response Times Over Time и, по умолчанию, Response Time Graph. Более наглядный и удобный, на мой взгляд, — первый вариант

Вариации графика

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

В тестировании производительности чаще всего используется 95 и 99 перцентиль для большей наглядности. Однако, если вы все же смотрите среднее время отклика, вам стоит учитывать при этом стандартное (среднеквадратичное) отклонение.

HTML Gatling Report
Для MF LoadRunner график будет называться Transaction Response Time (Percentile)
Также вы можете получить и перцентили для Apache JMeter с помощью графика Response Times Percentiles из этого же расширенного набора

Распределение Response Time

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

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

HTML Gatling Report для каждого запроса
Есть еще один вариант распределения времени выполнения запроса от количества запросов в разрезе успешных и ошибочных запросов для всего теста
Для MF LoadRunner данный график будет называться Transaction Response Time (Distribution) и показывать распределение для транзакций
В Apache JMeter тоже есть этот график в расширенном пакете и называется Response Times Distribution

Latency

В Apache JMeter этот график присутствует лишь в расширенном наборе и называется Response Latencies Over Time

Bandwidth

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

Изменяя этот параметр на инструменте нагрузки можно моделировать различные источники подключений к приложению: мобильная связь 4G или проводная сеть. В бесплатной версии Gatling этого графика нет, он есть лишь в платной версии Gatling FrontLine. Этот график из коробки есть лишь в MF LoadRunner, находится в том же блоке, что и Latency, и называется Average Bandwidth Utilization Graph.

График Request Per Second

Измеряется в штуках в секунду — показывает количество запросов, поступающее в систему за 1 секунду.

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

HTML Gatling Report
В MF LoadRunner график называется Hits per Second
Для Apache JMeter существует график Hits per Second из расширенного пакета

Измеряется в штуках в секунду и показывает количество транзакций (в рамках транзакции может быть множество запросов) за 1 секунду.

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

MF LoadRunner — Transactions per Second
Для расширенного пакета Apache JMeter — Transactions per Second

График Errors

Обычно измеряется в rate (штук в секунду) — график показывает рост количества ошибочных запросов. Также удобно измерять значение в процентах от общего числа запросов. По этому графику отслеживается выход за пределы SLA по количеству или проценту ошибок.

Если наложить график Response Time, можно увидеть, как увеличение ошибок влияет на рост времени ответа приложения.

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

HTML Gatling Report
В MF LoadRunner этот график называется Errors per Second

HTTP responses status

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

Источник