tps нагрузка что это
[обновлено] Как нагрузочное тестирование процессинга обошлось нам в €157 000 и почему никого не уволили
К исследованию побудили два фактора: появление у нас собственного процессинга карт и предстоящая крупная распродажа одного из популярных в РФ онлайн-ритейлеров.
Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.
Как оказалось, мы не одиноки – ни один из наших банков-партнеров еще полгода назад не знал своего настоящего «потолка» и решал проблемы по мере поступления. По сути, они просто добавляли новые мощности прямо во время распродаж, хотя и не всегда успешно.
Будущие жертвы
Система карточных платежей (Mastercard в нашем случае) соединяет между собой множество внешних организаций, у каждой из которых свой зоопарк систем. Под нагрузку карточных платежей попадают практически все они, поэтому сразу посмотрим на всех участников.
Ниже представлена упрощенная схема взаимодействия нескольких организаций для обеспечения возможности оплатить какой-то товар картой через сервис Яндекс.Денег:
Все ключевые участники эксперимента на одной схеме. Яндекс.Танк – это отличный инструмент Яндекса для нагрузочного тестирования и комфортного анализа производительности.
Яндекс.Деньги принимают данные пластиковой карты у пользователя (в случае с тестом передается уже заполненный шаблон формы), а дальше происходит следующее:
Заполненная форма с данными карты передается на серверы фронтенда, которые ее обрабатывают и передают данные в бэкенд, а в дальнейшем – в отвечающее за работу со счетами ядро.
Платежный сервис блокирует сумму операции на счете пользователя и параллельно отправляет информацию об операции в банк-эквайер, который далее передает сведения в Mastercard и НСПК.
При масштабных онлайн-распродажах таких оплат может быть сотни в секунду, поэтому достанется всем звеньям платежной цепочки. Чтобы ни у кого не было претензий, мы заранее договорились с парой дружественных банков о том, что в определенные даты будут «боевые стрельбы» и что их сотрудники будут во всеоружии на местах.
Забегая вперед, после проведения первого эксперимента из 17 000 операций оказалось, что банки используют горизонтальную модель масштабирования платежных шлюзов, добавляя новые мощности по мере необходимости. В обычной жизни они успевают отреагировать на постепенный рост нагрузки, но в стрессовом режиме этого оказалось недостаточно.
Тут есть один тонкий момент. Дело в том, что все банки и Mastercard зарабатывают на выставляемых друг другу комиссиях за переводы. Сделать такую комиссию нулевой для тестов было практически невозможно. По нашим оценкам, совокупная цифра должна была составить 0,7% по отдельному коду категории оплаты MCC.
Величина комиссии являлась минимально возможной согласованной цифрой на момент проведения эксперимента с точки зрения всех принимающих участие сторон.
Запомните этот момент – в конце статьи будет с чем сравнить.
А не расстрелять ли нам процессинг
При тестировании производительности платежных сервисов неизбежно возникает ряд нюансов и ограничений, которые вынудили нас выйти с экспериментом на продакшн:
Производительность ключевых микросервисов (например, связанных с шифрованием карточных данных) ограничена лицензией.
Расположение микросервисов тоже ограничено лицензией. То есть сервер с купленной лицензией нельзя даже перенести в тестовую среду.
В качестве подготовительных действий, мы также отключили дополнительную защиту платежа 3DSecure (SMS-коды), сняли лимиты на число и сумму операций на каждом этапе платежа, а также договорились со службами безопасности участников, чтобы они не били тревогу.
Тем важнее становился проект для Яндекс.Денег, так как кроме практической пользы можно было сделать нечто полезное для всей российской банковской отрасли – результаты и методика исследования могут пригодиться не только нам. Кроме того, мне лично всегда было любопытно, как поведет себя наш процессинг, если его как следует «расстрелять».
Радиус поражения
Как вы понимаете, никто не согласовал бы команде даже потенциальную остановку сервиса. Даже на несколько секунд.
Поэтому расстрел предстояло сделать бережным и прогнозируемым:
В качестве нагрузочной операции выбрали пополнение счета кошелька с банковской карты, которая привязана к другому кошельку. Эта достаточно простая операция влечет за собой массу транзакций между Яндекс.Деньгами, банком-эквайром, платежной системой и НСПК. Что и требуется для эксперимента.
Участвующий в эксперименте банк предоставил отдельный терминал для проведения платежей с оговоренным кодом MCC. На этом этапе каждая тестовая операция начинает стоить реальных денег, так как к MCC привязана определенная комиссия.
MCC код (Merchant Category Code) — представляет собой 4-значный номер, присваиваемый платежными системами VISA, Mastercard и др. для классификации деятельности торговой точки в операции оплаты по банковским картам. Для владельца такой торговой точки важно получить как можно более выгодный MCC и платить меньшую комиссию платежной системе.
Все эти меры гарантировали хороший уровень отказоустойчивости платежного сервиса для пользователей даже при пиковых нагрузках.
Общая схема эксперимента: многопоточное пополнение кошельков с банковских карт других кошельков.
Для эксперимента мы согласовали уровень подаваемой интенсивности в 20 RpS (Requests per Second, число запросов в секунду). Для достижения большей производительности можно добавлять новые модули, но в схеме эксперимента присутствовал только один.
Яндекс.Деньги сотрудничают с несколькими банками-партнерами, но на масштабный эксперимент с реальными деньгами согласился только один из них.
На графике виден рост производительности на модуле процессинга при росте входной интенсивности, с провалом в центре как раз в момент проседания производительности нашего процессинга.
Кроме того, тесты вызвали некоторые проблемы в нашем бэкенде и ядре системы, создав массу блокировок по карточным счетам. Блокировки – это нормальная ситуация для любой карточной операции, так как перед реальным списанием деньги просто блокируются на счету пользователя и запись об этом попадает в общий файл Mastercard.
Такой файл каждый банк-эквайер ежедневно получает от Mastercard каждый раз в одно и то же время по согласованию и далее его разбирает. Так вот, после экспериментов файл с обычным размером 20 МБ увеличился в 5 раз и стал весить 104 МБ. На отработку такого списка потребовалось больше ресурсов, то есть пришлось переписать отдельные модули микросервисов, которые обрабатывали файл блокировок.
Что ж, мы немного оптимизировали запросы к БД, снизив нагрузку на процессор, и выпустили больше карт для снижения числа блокировок на одну карту.
Продолжаем обстрел
Вторая волна эксперимента проходила уже более ровно и спокойно, несмотря на более чем вдвое возросшее число обрабатываемых платежей.
График уже более равномерный, что говорит об успешности принятых мер. RpS равняется 20, так как это максимальное согласованное для эксперимента значение.
После окончания потока в 24 778 операций объем блокировок для каждой карты продолжил расти, что приводило к замедлениям при проведении платежей: перед каждым списанием процессингу приходилось считывать заново весь список блокировок конкретной карты. Решение — увеличить число карт с 50 до 10 050, что позволило для каждой сократить список блокировок с 200 до 1 при аналогичном количестве операций.
Следующая волна тестов принесла 50 000 операций, а списания подгрузились в базу процессинга за 40 минут, после чего нужно было их еще и обработать. Файл блокировок продолжал угрожающе расти с каждым экспериментом. А ведь ключевая БД процессинга работает на Oracle с ограничением в 4 ГБ на файл. До предела еще далеко, но становилось некомфортно.
В ходе отдельного эксперимента мы оценили производительность обработки списаний. За сутки провели тесты с интенсивностью 15 блокировок в секунду и последующим потоком списаний. Файл со списаниям пришел к нам в 18:00 следующего дня с задержкой в 1,5 часа, и наш процессинг обработал все 1 135 000 записей за 2 часа 10 минут. Для контраста, обычный разбор среднестатистического списка блокировок занимает десяток минут.
Проблемы возникли также с производительностью антифрод-машины и фронтенд-балансировщика запросов. Дело было в том, что балансировщик не проверял логическую доступность сервиса на узле, ограничиваясь только его присутствием в сети.
Кульминацией стал эксперимент на двое суток с суммарным числом операций 1 400 000, во второй день которого одновременно происходили две вещи:
Проходили тестовые стрельбы с платежами.
Две эти операции нагрузили процессинг по полной в рамках существующих лицензионных ограничений 20 RpS.
Боевые стрельбы закончились через два дня на отметке 3 157 800 проведенных операций. Однако как следует отпраздновать успех и полюбоваться цифрами нам не дали.
Привет от Mastercard
Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р.
При заказе терминала под тестовые операции мы указали неверный MCC код, из-за чего и получилось невероятная комиссия.
А вот и причина безобразия – мы выбрали не тот код MCC для терминала эквайринга, через который проходили все тестовые стрельбы. Поэтому за операцию на 1 р. платили 4 р. комиссии. Узнать об этой проблеме в ходе эксперимента не представлялось возможным, так как Mastercard выставил счет через неделю.
Недоразумение обошлось нам в 2 месяца напряженной работы по ручному урегулированию вопроса с Mastercard. Фактически мы подняли логи всего эксперимента, по которому выполнялся поиск и изменение операций в Mastercard. Лишнее подтверждение, что без подробных логов никуда.
Несмотря на давность эксперимента и незначительные финансовые убытки от его проведения, опыт однозначно положительный. Более того, подобные боевые стрельбы стали регулярными, а полученные данные позволи серьезно увеличить производительность карточных операций.
Конечно же, все персонажи и числа в статье были творчески переосмыслены из соображений безопасности, но фантазировали мы не слишком бурно и сохранили соотношения полученных по эксперименту данных.
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
С каждым днем в мире становится все больше и больше инструментов для проведения нагрузочного тестирования. Собственно, и сам интерес к этой теме начинает возрастать.
Основная задача инструмента нагрузочного тестирования — подать заданную нагрузку на систему. Но кроме этого есть еще одна, не менее важная задача — предоставить отчет о результатах подачи этой нагрузки. Иначе мы проведем тестирование, но ничего не сможем сказать о его результате и не сможем достаточно точно определить, с какого момента началась деградация системы.
В настоящий момент наиболее популярными инструментами тестирования являются Gatling, MF LoadRunner, Apache JMeter. Все они обладают возможностями как генерации готовых отчетов по проведенному тестированию, так и отдельных графиков или сырых данных, на основе которых строится уже сам отчет.
Прежде чем писать любой отчет, нужно понять, для кого мы его пишем и какую цель преследуем. Нет никакого смысла добавлять множество графиков времени отклика приложения в отчет по каждой операции, если ваша цель — определить, есть ли утечки памяти, зафиксирована ли нестабильная работа во время теста надежности, или если вам нужно сравнить два релиза между собой в рамках регрессионного тестирования. Для ответа на эти вопросы вам хватит всего пары графиков, если, конечно, вы не зафиксировали проблемы и не хотите в них разобраться. Поэтому, прежде чем создавать отчет, подумайте, а точно ли вам нужно добавить все графики в него или лишь наиболее показательные и дающие ответ на цель тестирования. Также набор графиков и их анализ для отчета зависят от выбранной модели нагрузки — закрытой или открытой, так как разные модели дадут разные фигуры на графиках.
Мы в Тинькофф активно используем инструмент Gatling, поэтому на его примере расскажем, как создать отчет вашей мечты и куда следует смотреть при его анализе. Также сразу хочу заметить, что почти все графики, описанные в статье, можно получать в режиме онлайн с помощью связки вашего инструмента с Grafana. Это наиболее удобный инструмент для создания отчетов «на лету», с помощью сконфигурированного заранее дашборда. Более того, это позволяет более быстро создать почти любой график на основе отправленных вами данных. Уже сейчас есть готовые дашборды почти для всех инструментов нагрузочного тестирования. Графики для других инструментов — MF LoadRunner и Apache JMeter — тоже будут приведены, их анализ строится по аналогии с Gatling.
Основные метрики
Индикаторы
Показывают количественное и процентное распределение времени отклика запросов по группам. Графики этого типа удобно использовать, чтобы дать быструю предварительную оценку результатам тестирования без более глубокого анализа остальных графиков.
Пороги для перехода из группы в группу задаются заранее на основе экспертной оценки или SLA (нефункциональных требований). Например, может быть три группы:
В Gatling вы сами можете настроить пороги для перехода из группы в группу и их количество в файле gatling.conf. Графики такого типа лучше строить на основе методики. APDEX (Application Performance Index)
Также можно добавить индикатор с количеством/процентами ошибочных запросов.
Метод 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 (миллисекунды) — время задержки (чаще всего под этим понимают Network Latency). Этот параметр показывает время между окончанием отправки запроса до получения первого ответного пакета от системы.
С помощью этого параметра можно измерять также задержки на сетевом уровне, если параметр будет расти. Желательно, чтобы он стремился к нулю. Этот и следующий тип графиков в основном используются при глубоком анализе и поиске проблем производительности. Этого графика из коробки нет в Gatling. В MF LoadRunner этот график называется Average Latency Graph в блоке Network Virtualization Graphs если у вас установленные агенты мониторинга.
| В Apache JMeter этот график присутствует лишь в расширенном наборе и называется Response Latencies Over Time |  |
Аналогично метрике выше можно выделить параметр 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 |  |
Обычно измеряется в rate (штук в секунду) — график показывает рост количества ошибочных запросов. Также удобно измерять значение в процентах от общего числа запросов. По этому графику отслеживается выход за пределы SLA по количеству или проценту ошибок.
Если наложить график Response Time, можно увидеть, как увеличение ошибок влияет на рост времени ответа приложения.
Gatling по умолчанию не имеет отдельного графика, отображающего лишь ошибки. В Gatling он совмещен с графиком VU и сразу показывает, как рост нагрузки сказывается на росте числа ошибок, и помогает обнаружить порог, с которого идет превышение SLA или вообще появляются ошибки. В Apache JMeter также нет отдельного графика, он совмещен с графиками количества транзакций.
| HTML Gatling Report |  |
| В MF LoadRunner этот график называется Errors per Second |  |
HTTP responses status
Возможно также выводить на график распределения количества ошибок по кодам ответа приложения — удобно использовать для классификации ошибок.
Например, если на предыдущем графике вы получили 100%, вы начинаете анализировать, а какие именно 50x ошибки из-за того, что сервер не отвечает, или 403 из-за того, что неверный пул и пользователи не могу авторизоваться, если, например, вы используете HTTP-протокол.
Изначально в бесплатной версии Gatling этого графика нет, он есть лишь в платной версии Gatling FrontLine. Чтобы график появился в бесплатной версии, необходимо перенастроить logback.xml так, чтобы логи собирались в graylog, и уже в нем строить нужный график.
| В MF LoadRunner этот график называется HTTP Responses per Second |  |
| В Apache JMeter этот график называется Response Codes per Second из расширенного пакета |  |
Измеряется обычно в битах в секунду. График показывает пропускную способность приложения, а именно какой объем данных был отправлен и обработан приложением в единицу времени.
Обычно его используют для глубокого анализа проблемы приложений. В Gatling этот график содержится лишь в FrontLine, в бесплатной версии его нет.
| Этот график есть из коробки в MF LoadRunner, он называется Throughput |  |
| В Apache JMeter график называется Bytes Throughput Over Time из расширенного пакета |  |
Большинство графиков можно получить, используя отчет HTML Based Gatling Reports после теста или же настроив связку мониторинга Graphite-InfluxDB-Grafana. Для отображения можно использовать готовый дашборд из библиотеки дашбордов https://grafana.com/grafana/dashboards/9935.
При анализе и составлении своих дашбордов для Gatling следует учитывать, что результаты в InfluxDB хранятся агрегированные и подходят только для предварительной оценки результатов НТ. Рекомендуется после теста повторно загрузить simulation.log в базу данных и уже по нему строить итоговый отчет и выполнять поиск проблем производительности системы.
Матричное описание метрик
Всё, что мы описали выше, представлено в виде маленькой таблички, суммирующей все эти знания.