Недавно упоминалось, что в сентябре вышла IMS 13. Чтобы релиз получился с некоторой изюминкой, команда IMS решила замутить что-нибудь этакое. Естественно надо показывать свои сильные стороны, поэтому было принято решение пробить предыдущий потолок результатов performance test системы в 46,000 транзакций в секунду и удвоить результат, достигаемый на одном instance IMS и на одной машине.
Тестовая нагрузка представляет собой небольшой набор приложений по работе с карточным процессингом. Безусловно логика достаточно сильно упрощена. Реализованы функции авторизации карты (CCCK), проверки лимита (CLCK), дебита/кредита счета (DEBIT), отслеживание утеряных или украденых карт (LOST). Естественно логирование и чекпоинты никто не отменял.
Тест симулирует 150 миллионов банковских счетов (выпущенных карточек), около 3 миллионов POS-терминалов и 270 тысяч записей о потеряных картах. По характеру работы с диском транзакции распределены следующим образом:
Транзакция
Доля
Тип доступа
LOST
0.01%
Read / Write
CCCK
33.33%
Read Only
CLCK
33.33%
Read Only
DEBIT
33.33%
Read / Write
Для экспериментов был собран вот такой стенд:
Как видно продакшн LPAR имеет в распоряжении 20 процессоров общего назначения. Для эмуляции нагрузки понадобился второй LPAR в 10 процессоров, на котором запустили Workload Simulator (бывший TPNS), грузивший стенд по TCP/IP.
Краткая выдержка из результатов:
Number of IMS instances
1
TPS
117 292
CPU Utilization
73.91%
Average transit time
63 ms
Average DASD (I/O) per second
122 066
Average DASD response time
2.5 ms
IMS logging rate
128.9 MB/s
Measurement duration
15 minutes
Меня лично заинтересовал график влияния чекпоинта на transaction rate. В эти моменты TPS падает, но время требуемое для чекпоинта такой нагрузки вписывается в 0.5 секунды, и затем система снова продолжает молотить на 100К+ уровне.
Гораздо больше подробностей можно найти в опубликованной статье. Там рассматриваются проблемы, с которыми IMS performance team столкнулась и как их преодолевали. Так же там гораздо больше дополнительных метрик и подробная методика расчета теста. Ну и еще расшарены конфиги софта на стенде.
а я вот не понимаю, почему они не делают. да, может, там будет меньше транзакций. зато они будут другие, и запросы другие. почему они не сделают похожий тест, с открытым SQL-запросом, на котором тестировалось, со структурой и размерами базы? неужто так за себя страшно?
ну, финансовые транзакции то будут такими же. неважно, как оно внутрях, гланое, чтобы бизнес-логика отрабатывала. а по поводу вопроса... я полагаю - нет, не страшно. ничуть не страшно. просто стыдно
там даже есть какой-то странный для меня обработчик номера карточки, повидимому, под разные форматы номеров карточек, я этого не понимаю, но оно есть. не похоже на "рекордное" приложение. Больше похоже на живое. Написано на коболе, но закоренелым ассемблерщиком, читать тяжко
тут можно только пояснить, наверное, роль чекпоинта. Чекпоинт фиксирует точку, с которой будет восстанавливаться система после сбоя. Чем чаще чекпоинт - тем меньше надо читать журнал транзакций и тем меньше надо делать откатов незавершённых и накатов завершённых транзакций. То есть, чем чаще чекпоинт - тем быстрее востановление после сбоя, но как чётко видно - чекпоинт довольно тяжёлая операция. Меня всегда удивляет большая открытость и честность команды ИМС, проявляющаяся даже вот в этом частном случае. Ведь можно было для достижения красивых показателей не длать чекпоинты вообще, кто бы заметил то? Тест на время восстановления после сбоя не проводился ведь. Нет, эти ребята стараются делать как можно ближе к реальному режиму эксплуатации, а не гнать рекорды. По поводу логика сильно упрощена, ну не знаю, при авторизации карты, после выполнения всех проверок, если карта заблокирована, то выполняется запись о попытке доступа. Дебитовая/кредитовая операция тоже полноценная, с выполнением проводки и измиенением сальдо, вполне пригодно потом для формирования выписки по счёту для передачи в следющую систему. Я не вижу никакого упрощения - четыре основные операции, без которых процессинг невозможен, реализованы в полной мере. Без воспомогательных систем, правда. Да, нету сопряжение с системой выпуска карточек, с главной бухгалтерской книгой, или что там есть в банке. Но всё для этого в наличии, и реализовать можно. То есть процессинг готовый, бери и используй.
я тебе так скажу: эти ребята просто строят максимально реалистичный стенд. для этого, я думаю, взяли живую систему, залили игровыми данными (а может и нет), и после этого поставили опыт. так что чекпойнт обоснован, в реальных системах без него никак, вот он и присутствует. у нас, когда одну из систем принимали, явным образом включали в ТЗ и чекпойнты, и остановы на регламенты, и вообще максимальную похожесть на реальную жизнь.
А им и не в таких терминах это надо рассказывать. надо говорить не о пиковой нагрузке, а о стоимости одной транзакции. С другой стороны я бы не сказал, что этот результат релевантен только для финансовой индустрии. Так вышло, что большая часть потребителей системы там. Резон экономить ресурсы есть у всех.
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]