Комментарии 83
3 157 800 операций — это за сколько дней?
3 157 800 операций было проведено за двое суток эксперимента.
«Хозяйке на заметку»: если общаться не только внутри IT, а ещё из бизнесом — rps проще объяснить и " продать", чем tps (хотя и то и то, весьма сложно объяснимо, обычно все хотят мерять «пользователями» — что совершенно неверно с точки зрения нагрузочного тестирования).
Да и «запросы», по-хорошему, «транзакциями» называть не стоит (легко будет запутаться, если читать литературу, пользоваться инструментами, например newrelic), если речь только про название, а не суть.
RPS — это прежде всего, то что породило запросы к сервису (как правило внешние), а TPS — это то, что уже происходило внутри и пораждало запросы (транзакции) к другим сервисам, базам данных, да даже просто другим участкам кода и в принципе много чего ещё можно измерять, в зависимости от возможностей вашего мониторинга.
Всё конечно весьма условно, но по опыту, в такой терминологии жить гораздо проще. ;)
Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.
Да, это ужасно интересно!
Думаю там убытки сравнимые были…
Я то подумал проблема была у вас и с интересом читал что же вы не правильно сделали, а оказывается банка-эквайринг ошибся(
Мне интересно, или даже любопытно, у вас есть какие-нибудь числа по поводу пиковой нагрузки в такого рода случаях?
Например, среднее время ответа (запрос + валидация + перевод) какой-либо операции (например, оплата по карте), сколько транзакций в секунду в час пик, а сколько ночью.
Я иногда присутствую при нагрузочном тестировании и мне интересна чужая статистика для сравнения.
Спасибо заранее.
![image](https://habrastorage.org/files/b61/567/258/b615672582154d4684dd9238cc6cc2a8.png)
Как можно читать этот график, если на нем нет оси Y?
AliExpress умеют устраивать красивые акции с эффектным ростом оборота. :)
О, да, распродажи и подготовка к ним — это уйма других интересных историй :) Производительность карточных авторизаций крайне важна и для нашего бизнеса, и для исследований. Хотя бы потому что нагрузки там значительно больше и финансовые риски выше, особенно в преддверии распродаж. Такие акции — как раз интересны взрывным ростом интенсивности, когда график улетает в потолок. Мы на регулярной основе исследуем на боевой среде latency и throughput возможностей нашей системы по карточным авторизациям, чтобы гарантировать поддержку на уровне сотен операций в секунду (точно не меньше 500 TpS). Причем такие эксперименты не требуют от нас финансовых затрат, там мы давно всё учли :).
А график, насколько я вижу, содержит тот самый пик при тестировании? Или же это Shopping Festival 11.11, а стрелочка показывает обыкновенный «размер» выручки в каждый день?
Спасибо, если я правильно понимаю, вы симулируете ситуацию, когда магазин получает платежей от Qiwi клиентов с throughput 100-200 TpS
Да.
А какой в этом случае получается response time?
Норма — в пределах 2-3 секунд.
Когда пользователь видит, что покупка успешна, она действительно успешна, или «запрос принят и сейчас обрабатывается»?
Успешна. Причем онлайн обновляется баланс клиента и, по умолчанию, баланс компании, которая принимает платеж.
Или же это Shopping Festival 11.11, а стрелочка показывает обыкновенный «размер» выручки в каждый день?
Все верно, это Ali 11.11. Только не выручки, а числа оплат. Графики с тестов не такие эффектные. :)
Я иногда присутствую при нагрузочном тестировании и мне интересна чужая статистика для сравнения.
Я бы с радостью рассказал о них подробнее, но пока это тайна.
Но насчёт «среднего российского банка» — думаю вы правы, 20tps вполне реальная ситуация.
У нас 130
Спасибо огромное, материал и опыт просто бесценные.
Безумству храбрых поем мы песню.
Как то непонятно
Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию)… Нам выставили счет в €157 890 в качестве комиссии за проведенные операции, что немного не вписывалось в оговоренные 0,7% с 125 000 р… Поэтому операции проводились не по оговоренной ставке. Грубо говоря, за операцию на 1 р. мы платили 4 р. комиссии.
Как с 1 р. за операции при комиссии в 4 р. сумма выросла более чем в 75 раз?
Спустя сутки НСПК присылает файл блокировок в банк-эквайер и Яндекс.Деньги, после чего список блокировок разбирается в наших микросервисах и происходит списание денег со счета пользователя.
…
Такой файл каждый банк-эквайер ежедневно получает от Mastercard каждый раз в одно и то же время по согласованию и далее его разбирает.
Mastercard и НСПК присылают файлы, но в одном моменте один, в другом другой...
Дело в том, что все банки и Mastercard зарабатывают на выставляемых друг другу комиссиях за переводы.
НСПК не за бесплатно работает
Вообще не ясен смысл статьи, если честно. Статья о том как мы накосячили с MCC в проде? Почему нельзя было в тестовой среде это сделать?
Подскажите, а вы проводили эксперимент одновременно с работой обычных клиентов? От них не было жалоб на какие-нибудь задержки в обслуживании?
Да, эксперимент проводился вместе с работой обычных клиентов на той же среде. При этом наши экспериментальные операции фактически ничем не отличались от аналогичных пользовательских. И самое приятное для нас — никто из них не пострадал. Все было сделано более, чем аккуратно.
А ведь ключевая БД процессинга работает на Oracle с ограничением в 4 ГБ на файл.Что это за ограничение и откуда взялось?
Нагуглил вот это:
http://alldba.ru/index.php/38-subd/index.php?option=com_content&view=article&id=64&Itemid=164
Oracle Database XE может быть установлена на любой компьютер с любым количеством процессоров (одна база данных на машину), но с ограничением в 4Гб пользовательских данных, использует не более 1Гб оперативной памяти и только один из имеющихся процессоров.
Собственно пруф
Что это за ограничение и откуда взялось?
Гипотезы интересные, но в нашем случае всё несколько иначе :) На момент проведения эксперимента все блокировки приходили в виде xml-файла, загружающего в поле Oracle типа CLOB, максимальный размер которого 4 Гб. Мы уже переписали этот механизм и результаты проведённого эксперимент тут сыграли не последнюю роль.
А так как он чей-то родственник начальничка повыше, за него сверху заступились и убыток «списали».
Ну в прочем как обычно в большинсте компаниях на постсоветском пространстве.
За коррупцию вообще молчу, это поголовно.
ИМХО.
Только мне не понятно, кто тот самый ответственный человек допустивший такую оплошность.
Если бы это был рядовой или руководитель низшей планки — он бы уже давно был уволен, как минимум.
Эта «счастливая» статья напоминает пару месяцев назад историю как devops случайно удалил не ту базу и как они потом восстанавливали старую базу при посторонней помощи. И всю эту историю выложили в паблик.
PS. сотрудники яндекса всегда минусуют критику? И это называется «единственная европейская компания на территории РФ зародившаяся и ныне живая»?
"Это был рядовой или руководитель низшей планки" только блин не из Яндекса. Это так сложно понять?
я не очень понимаю, а что бы это улучшило? Увольнение сотрудника за оплошность — это вообще как-то дико, на мой взгляд, звучит. Можно уволить за саботаж, за то, что не работает, за обнаружившуюся непроходимую тупость, постоянно приводящую к убыткам, можно по политическим мотивам. А за единичную ошибку — вы это как потом объясните его коллегам?
Лучше наказания относительно рядового работника за первую ошибку только коллективная ответственность. Лучше для развала команды и ухода всех более-менее разумных работников, разумеется.
Если же серьёзно, то такого рода ошибки, зачастую, не вина исполнителей, а вина их руководителей, которые не смогли/не успели отладить процессы. И за систематические проблемы такого рода нужно увольнять не исполнителей, а их начальников. К сожалению, это происходит куда реже.
"Или вы хотите, чтобы Яндекс уволил сотрудников банква-экваера за то, что те затупили? :D"
Насколько я понял, ошиблись сотрудники Яндекс.Денег.
Проглядывает жуткая не технологичность процессинга — обмен файлами транзакций, ежесуточный их разбор…
Планируется ли переход на блокчейн или что-то подобное?
обмен файлами транзакций, ежесуточный их разбор
;) добро пожаловать в реальный мир…
Что это за новомодный тренд пытаться засунуть блокчейн во все щели!
Вопрос насчет вашей системы логирования на основе эластика: сколько ГБ логов туда попало за день при максимальной нагрузке(если не секрет конечно)?
Почему графики как у JMeter? Использовалась та же библиотечка?
В общем, хотелось бы, чтобы системы были более совершенны и дарили пользователям только радость)
Как только они научатся быстрее шифровать — будет легче.
Приведенные цифры мало о чем говорят без этого.
[обновлено] Как нагрузочное тестирование процессинга обошлось нам в €157 000 и почему никого не уволили