Pull to refresh

Comments 83

Разъясните, пожалуйста, что такое RpS?

3 157 800 операций — это за сколько дней?
RpS — Request per Second — число запросов в секунду, метрика использования сетевого ресурса. В нашем случае, один запрос был равен одному переводу с карты на счёт.

3 157 800 операций было проведено за двое суток эксперимента.
Мы обычно используем термин tps — transaction per second
rps != tps, обычно rps в лучшем случае равен tps или всегда меньше (а порой на порядок).

«Хозяйке на заметку»: если общаться не только внутри IT, а ещё из бизнесом — rps проще объяснить и " продать", чем tps (хотя и то и то, весьма сложно объяснимо, обычно все хотят мерять «пользователями» — что совершенно неверно с точки зрения нагрузочного тестирования).
Да и «запросы», по-хорошему, «транзакциями» называть не стоит (легко будет запутаться, если читать литературу, пользоваться инструментами, например newrelic), если речь только про название, а не суть.

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

Всё конечно весьма условно, но по опыту, в такой терминологии жить гораздо проще. ;)
Спасибо!
Мы чаще тестируем только одну систему, все остальные на заглушках, так что tps отличается от rps только если часть транзакций принимаются но не обрабатываются, то есть после достижения макс.перф, так что мы rps называем tps.
В данном случае, конечно, все эти ньюансы надо учесть.
+поправили в статье — спасибо!
Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.

Да, это ужасно интересно!
Какая прекрасно мелкая, нелепая и дорогая ошибка. Человеческий фактор во всей красе, надо полагать.
Без него никуда. Я помню как-то несколько лет назад Гугл пропал для всей России на несколько часов. Оказалось тоже кто-то опечатался: подключили новый, ускоренный, канал но ошибка в таблицах роутинга привела к тому, что вместо разрешения обоих каналов они оба оказались запрещены (где-то «или» с «и» перепутали).

Думаю там убытки сравнимые были…
> Как нагрузочное тестирование процессинга обошлось нам в €157 000 и почему никого не уволили

Я то подумал проблема была у вас и с интересом читал что же вы не правильно сделали, а оказывается банка-эквайринг ошибся(
вообще поток слабоват, в начале статьи писали про сотни операций в секунду. Все таки хорошо, если бы можно было на полноценной тестовой системе всё это повторить, было бы и дешевле и можно было бы больше чем 20tx/sec послать. Которыми в общем то мало кого удивишь…
Вы сильно удивитесь, когда начнете узнавать реальные цифры производительности российских банков-эммитентов. Действительно думаете, что по карточке среднего российского банка идет поток в 20 транзакций в секунду?

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


Например, среднее время ответа (запрос + валидация + перевод) какой-либо операции (например, оплата по карте), сколько транзакций в секунду в час пик, а сколько ночью.


Я иногда присутствую при нагрузочном тестировании и мне интересна чужая статистика для сравнения.


Спасибо заранее.

В Qiwi, правда, по кошельку тестируем от 100 до 200 транзакций в секунду на магазин. AliExpress умеют устраивать красивые акции с эффектным ростом оборота. :) image

Как можно читать этот график, если на нем нет оси Y?


Иллюстрация в тему

Число оплат за 5 минут. Y раскрыть не могу, NDA же. :)

Так Y не обязательно должно быть в настоящих числах, может быть и в у.е.
Главное видеть, сколько было до, и насколько это линия подскочила.
Сейчас это может быть так: было 90 у.е, стало 99, а шкала от 90 до 100

AliExpress умеют устраивать красивые акции с эффектным ростом оборота. :)

О, да, распродажи и подготовка к ним — это уйма других интересных историй :) Производительность карточных авторизаций крайне важна и для нашего бизнеса, и для исследований. Хотя бы потому что нагрузки там значительно больше и финансовые риски выше, особенно в преддверии распродаж. Такие акции — как раз интересны взрывным ростом интенсивности, когда график улетает в потолок. Мы на регулярной основе исследуем на боевой среде latency и throughput возможностей нашей системы по карточным авторизациям, чтобы гарантировать поддержку на уровне сотен операций в секунду (точно не меньше 500 TpS). Причем такие эксперименты не требуют от нас финансовых затрат, там мы давно всё учли :).
500 — огонь. А в чем была разница с тестированием из статьи? Почему там всего 20 тогда?
Так от 500 TpS — это про авторизации карточных операций, а операций по картам собственной эмиссии — от 20 TpS. Кроме того для авторизаций карточных операций проводились эксперименты по нахождению конкретно максимума производительности, а в текущей статье мы описали stress и volume тестирование для операций по своим эмитированным картам.
Спасибо, если я правильно понимаю, вы симулируете ситуацию, когда магазин получает платежей от Qiwi клиентов с throughput 100-200 TpS? А какой в этом случае получается response time? Когда пользователь видит, что покупка успешна, она действительно успешна, или «запрос принят и сейчас обрабатывается»?

А график, насколько я вижу, содержит тот самый пик при тестировании? Или же это Shopping Festival 11.11, а стрелочка показывает обыкновенный «размер» выручки в каждый день?
Спасибо, если я правильно понимаю, вы симулируете ситуацию, когда магазин получает платежей от Qiwi клиентов с throughput 100-200 TpS

Да.
А какой в этом случае получается response time?

Норма — в пределах 2-3 секунд.
Когда пользователь видит, что покупка успешна, она действительно успешна, или «запрос принят и сейчас обрабатывается»?

Успешна. Причем онлайн обновляется баланс клиента и, по умолчанию, баланс компании, которая принимает платеж.
Или же это Shopping Festival 11.11, а стрелочка показывает обыкновенный «размер» выручки в каждый день?

Все верно, это Ali 11.11. Только не выручки, а числа оплат. Графики с тестов не такие эффектные. :)
без оси y этот график не представляется важным или несущим хоть какую-то информацию… ну понятноже, иначе как соотношение понять
Я иногда присутствую при нагрузочном тестировании и мне интересна чужая статистика для сравнения.

Я бы с радостью рассказал о них подробнее, но пока это тайна.
160 в секунду. И это год назад.
работая в одном из вендоров процессинга — в принципе, какие-то цифры есть…
Но насчёт «среднего российского банка» — думаю вы правы, 20tps вполне реальная ситуация.
В рамках проведённого эксперимента в первую очередь нам было важно провести именно stress и volume тестирование, оценить влияние на систему в ходе постоянного длительного накопления операций. Мы не пытались выяснить максимальную производительность, поэтому и стреляли не до отсечки. Кроме того предметом исследования являлись не авторизации карточных операций, а операции по картам собственной эмиссии на одном из сегментов процессинга. Каждый такой сегмент использует готовое платное решение от стороннего производителя. Мощности одного такого сегмента ограничены, а их увеличение требует привлечения дополнительных денежных средств.
20tps это очень много для эквайера/платежного шлюза. Сервисов, которые выдают больше 1tps можно по пальцам пересчитать. И если они возникают банки действительно руками увеличивают мощности. Условно должно произойти чудо, чтобы трафик Али или Киви пошел через тебя.

Спасибо огромное, материал и опыт просто бесценные.
Безумству храбрых поем мы песню.

Так вы заплатили все-таки 157 000 евро или отсудили свою правоту?
Так вы заплатили все-таки 157 000 евро или отсудили свою правоту?


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

Как то непонятно


Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию)… Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р… Поэтому операции проводились не по оговоренной ставке. Грубо говоря, за операцию на 1 р. мы платили 4 р. комиссии.

Как с 1 р. за операции при комиссии в 4 р. сумма выросла более чем в 75 раз?


Спустя сутки НСПК присылает файл блокировок в банк-эквайер и Яндекс.Деньги, после чего список блокировок разбирается в наших микросервисах и происходит списание денег со счета пользователя.

Такой файл каждый банк-эквайер ежедневно получает от Mastercard каждый раз в одно и то же время по согласованию и далее его разбирает.

Mastercard и НСПК присылают файлы, но в одном моменте один, в другом другой...


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

НСПК не за бесплатно работает

Как то непонятно. Как с 1 р. за операции при комиссии в 4 р. сумма выросла более чем в 75 раз?

В итоге мы провели 3 157 800 операций при комиссии 4 р. за штуку, и общая сумма составила 12 631 200 р. или € 157 890 на момент организации эксперимента.
Странная терминология для процессинга. Обычно процессинг оперирует термином tps (transaction per second). И что это за нагрузка 20 tps? Вон в процессингах идут 1500 tps от которых TSYS загибается — вот это нагрузка!

Вообще не ясен смысл статьи, если честно. Статья о том как мы накосячили с MCC в проде? Почему нельзя было в тестовой среде это сделать?
Вероятно причина в том, что хотели протестировать работу всей структуры в целом.
Надо сказать, что 125 тысяч (с учётом комиссии 0.7 212.5 тысяч) очень небольшая цена за такие данные.
Главное, что бы такое тестирование не вызвало проблемы на проде!
А почему вы 125 000 считаете потерянными? Они же на свои кошельки переводили. Стоимость эксперимента должна была быть 0.7% от 125 000. То есть в районе тыщи рублей.
точно
Я ещё и 0,7% перепутал с коэффициентом 0,7 :)
Подскажите, а вы проводили эксперимент одновременно с работой обычных клиентов? От них не было жалоб на какие-нибудь задержки в обслуживании?
Подскажите, а вы проводили эксперимент одновременно с работой обычных клиентов? От них не было жалоб на какие-нибудь задержки в обслуживании?

Да, эксперимент проводился вместе с работой обычных клиентов на той же среде. При этом наши экспериментальные операции фактически ничем не отличались от аналогичных пользовательских. И самое приятное для нас — никто из них не пострадал. Все было сделано более, чем аккуратно.
Если что-то обошлось в круглую сумму, но никого не уволили — статья про Яндекс.
Для любого, кто видел какой-нибудь процессинг изнутри статья странная примерно вся, но как базовика меня более всего удивило вот это:
А ведь ключевая БД процессинга работает на Oracle с ограничением в 4 ГБ на файл.
Что это за ограничение и откуда взялось?
Это ограничение на размер datafile, но в tablespace может быть много файлов, так что это не повлияет.
Что-то я тупанул — если это ограничение на datafile ASM, то там не 4, а 2, и не GB, а TB, так что вообще не понятно откуда такое число взялось…
Там 32-битная машина, что ли?
Действительно, странно. UTL_FILE ограничений на размер читаемого файл не имеет, external table тоже, sql*loader тем более. Было бы интересно узнать подробнее про это ограничение.
Я по оракл не спец, но тоже заинтересовался, вспонив fat32 :)
Нагуглил вот это:

http://alldba.ru/index.php/38-subd/index.php?option=com_content&view=article&id=64&Itemid=164
Единственное, что приходит в голову с таким ограничением — это Oracle Database Express Edition. Цитата с сайта —
Oracle Database XE может быть установлена на любой компьютер с любым количеством процессоров (одна база данных на машину), но с ограничением в 4Гб пользовательских данных, использует не более 1Гб оперативной памяти и только один из имеющихся процессоров.

Собственно пруф
Что это за ограничение и откуда взялось?

Гипотезы интересные, но в нашем случае всё несколько иначе :) На момент проведения эксперимента все блокировки приходили в виде xml-файла, загружающего в поле Oracle типа CLOB, максимальный размер которого 4 Гб. Мы уже переписали этот механизм и результаты проведённого эксперимент тут сыграли не последнюю роль.
Безотносительно креативности идеи хранить блокировки таким образом, ограничение все таки примерно 8Тб, а никак не 4Гб. Дока.
UFO just landed and posted this here
Что-то мне кажется, потому никого не уволили так как решение принимал какой-то начальник, важный начальничек.
А так как он чей-то родственник начальничка повыше, за него сверху заступились и убыток «списали».
Ну в прочем как обычно в большинсте компаниях на постсоветском пространстве.
За коррупцию вообще молчу, это поголовно.
ИМХО.
Равнять совок и Яндекс не стоит. Яндекс — единственная европейская компания на территории РФ зародившаяся и ныне живая. Нет в них совка, так уж получилось.
единственная европейская компания на территории РФ

откуда дровишки?

«европейская» — это у вас синоним «хорошая»?

Ну уж не единственная. Luxoft, например

Вы статью вообще до конца дочитали? Или вы хотите, чтобы Яндекс уволил сотрудников банква-экваера за то, что те затупили? :D
Конечно прочитал.
Только мне не понятно, кто тот самый ответственный человек допустивший такую оплошность.
Если бы это был рядовой или руководитель низшей планки — он бы уже давно был уволен, как минимум.
Эта «счастливая» статья напоминает пару месяцев назад историю как devops случайно удалил не ту базу и как они потом восстанавливали старую базу при посторонней помощи. И всю эту историю выложили в паблик.

PS. сотрудники яндекса всегда минусуют критику? И это называется «единственная европейская компания на территории РФ зародившаяся и ныне живая»?
Я не сотрудник Яндекса, но я минусанул. Причина? Со словами «мне кажется» идёт оголтелое (ака не имеющее доказательств) обвинение в кумовстве, с плавным переводом вопроса в политическую плоскость, с параллельным обобщением на всю индустрию.

"Это был рядовой или руководитель низшей планки" только блин не из Яндекса. Это так сложно понять?

> он бы уже давно был уволен, как минимум.
я не очень понимаю, а что бы это улучшило? Увольнение сотрудника за оплошность — это вообще как-то дико, на мой взгляд, звучит. Можно уволить за саботаж, за то, что не работает, за обнаружившуюся непроходимую тупость, постоянно приводящую к убыткам, можно по политическим мотивам. А за единичную ошибку — вы это как потом объясните его коллегам?

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


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

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

"Или вы хотите, чтобы Яндекс уволил сотрудников банква-экваера за то, что те затупили? :D"


Насколько я понял, ошиблись сотрудники Яндекс.Денег.

Тема "… почему никого не уволили" не раскрыта :-) В результате 2-х месяцев боданий был перерасчет или как?

Проглядывает жуткая не технологичность процессинга — обмен файлами транзакций, ежесуточный их разбор…
Планируется ли переход на блокчейн или что-то подобное?
обмен файлами транзакций, ежесуточный их разбор

;) добро пожаловать в реальный мир…
Зачем тут блокчейн!?!?!? Что в платежной системе банк не доверяет оператору платежный системы? Что есть ситуации кода целые сегменты ПС выплывают на стуки из онланйа?
Что это за новомодный тренд пытаться засунуть блокчейн во все щели!

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

Обмен данными по блокировкам нужен. В некоторых случаях операцию по карте может одобрить платежная система, и банк не будет об этой операции знать пока она ему об этом не скажет.
Классная статья, спасибо!
Вопрос насчет вашей системы логирования на основе эластика: сколько ГБ логов туда попало за день при максимальной нагрузке(если не секрет конечно)?
Сотни миллионов операций во всей системе не сравнимы с единицами миллионов операций процессинга во время нашего эксперимента, поэтому существенной нагрузки на систему логирования на основе эластика мы не заметили.

Почему графики как у JMeter? Использовалась та же библиотечка?

Да, там самая библиотека. В качестве генераторов трафика использовались и phantom (дефолтный для Яндекс.Танка) и jmeter.
Для меня самое большое приключение — это купить билет на КампНоу, когда за 2 дня до матча выбрасывают оставшиеся 10тыс билетов. Сайт пускает в порядке живой очереди, иногда с часовым ожиданием… Платежная система может выбросить на последнем этапе…
В общем, хотелось бы, чтобы системы были более совершенны и дарили пользователям только радость)
Активная работа ритейла подразумевает ещё и активную работу ККМ нового типа. Не будет ли этот момент узким местом?
Гипотетически вполне вероятно ККМ может стать узким местом. Это, кстати, хорошая перспектива для дальнейших исследований, которые нам ещё предстоит провести. Пока у нас такой возможности не было.
Там проблема в фискальных накопителях. Они обрабатывают около 1 чека в три секунды.
Как только они научатся быстрее шифровать — будет легче.
Для полноты картины нужно было бы упомянуть железо, на котором работает процессинг.
Приведенные цифры мало о чем говорят без этого.
Sign up to leave a comment.