Вторник, 26.09.2017, 08:38
Приветствую Вас Гость | RSS
Главная | Блог | Регистрация | Вход
Форма входа
Логин:
Пароль:
Поиск

Меню сайта

Категории раздела
Техническое [24]
Все о мейнфреймах и не только о них, но все-таки крепко связанное с техникой и инженерными моментами.
Разговорчики [24]
Обо всем остальном, не относящемся к технике.

Календарь
«  Ноябрь 2013  »
ПнВтСрЧтПтСбВс
    123
45678910
11121314151617
18192021222324
252627282930

Архив записей

Наш опрос
О регистрации на сайте с помощью соцсетей.
Всего ответов: 12

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql MVS OS zOS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere history сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург пример Assembler LHI vs XR instruction to clear GPR z Seies CPU performance семинар впечатление доступность ЦБ цены аутсорсинг BMC CMS ZVM санкции Rockwell история z13 мобильность DB2 Java Coupling Facility Parallel Sysplex WebSphere AS MVT ОС ЕС ссср Tape VTL Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа

Статистика

Главная » 2013 » Ноябрь » 19 » 117000 TPS на EC12 - IMS 13 released

117000 TPS на EC12 - IMS 13 released
16:52
Недавно упоминалось, что в сентябре вышла IMS 13. Чтобы релиз получился с некоторой изюминкой, команда IMS решила замутить что-нибудь этакое. Естественно надо показывать свои сильные стороны, поэтому было принято решение пробить предыдущий потолок результатов performance test системы в 46,000 транзакций в секунду и удвоить результат, достигаемый на одном instance IMS и на одной машине.

Тестовая нагрузка представляет собой небольшой набор приложений по работе с карточным процессингом. Безусловно логика достаточно сильно упрощена. Реализованы функции авторизации карты (CCCK), проверки лимита (CLCK), дебита/кредита счета (DEBIT), отслеживание утеряных или украденых карт (LOST). Естественно логирование и чекпоинты никто не отменял.

Тест симулирует 150 миллионов банковских счетов (выпущенных карточек), около 3 миллионов POS-терминалов и 270 тысяч записей о потеряных картах. По характеру работы с диском транзакции распределены следующим образом:
Транзакция
Доля
Тип доступа
LOST0.01%
Read / Write
CCCK
33.33%
Read Only
CLCK
33.33%Read Only
DEBIT
33.33%Read / Write


Для экспериментов был собран вот такой стенд:
IMS13 стенд

Как видно продакшн 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К+ уровне.
IMS13 TPS and checkpoints

Гораздо больше подробностей можно найти в опубликованной статье. Там рассматриваются проблемы, с которыми IMS performance team столкнулась и как их преодолевали. Так же там гораздо больше дополнительных метрик и подробная методика расчета теста. Ну и еще расшарены конфиги софта на стенде.

Категория: Техническое | Просмотров: 1181 | Добавил: art | Теги: IBM, IMS | Рейтинг: 5.0/1 |


Всего комментариев: 8
5  
Вот жаль, что ДБ2-шная лаборабория ничего похожего не делает.
Ну, оно, наверное, понять можно.

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

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

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

3  
тут можно только пояснить, наверное, роль чекпоинта.
Чекпоинт фиксирует точку, с которой будет восстанавливаться система после сбоя.
Чем чаще чекпоинт - тем меньше надо читать журнал транзакций и тем меньше надо делать откатов незавершённых и накатов завершённых транзакций.
То есть, чем чаще чекпоинт - тем быстрее востановление после сбоя, но как чётко видно - чекпоинт довольно тяжёлая операция.
Меня всегда удивляет большая открытость и честность команды ИМС, проявляющаяся даже вот в этом частном случае.
Ведь можно было для достижения красивых показателей не длать чекпоинты вообще, кто бы заметил то? Тест на время восстановления после сбоя не проводился ведь.
Нет, эти ребята стараются делать как можно ближе к реальному режиму эксплуатации, а не гнать рекорды.
По поводу логика сильно упрощена, ну не знаю, при авторизации карты, после выполнения всех проверок, если карта заблокирована, то выполняется запись о попытке доступа.
Дебитовая/кредитовая операция тоже полноценная, с выполнением проводки и измиенением сальдо, вполне пригодно потом для формирования выписки по счёту для передачи в следющую систему.
Я не вижу никакого упрощения - четыре основные операции, без которых процессинг невозможен, реализованы в полной мере. Без воспомогательных систем, правда.
Да, нету сопряжение с системой выпуска карточек, с главной бухгалтерской книгой, или что там есть в банке.
Но всё для этого в наличии, и реализовать можно.
То есть процессинг готовый, бери и используй.

8  
я тебе так скажу: эти ребята просто строят максимально реалистичный стенд. для этого, я думаю, взяли живую систему, залили игровыми данными (а может и нет), и после этого поставили опыт. так что чекпойнт обоснован, в реальных системах без него никак, вот он и присутствует.
у нас, когда одну из систем принимали, явным образом включали в ТЗ и чекпойнты, и остановы на регламенты, и вообще максимальную похожесть на реальную жизнь.

1  
Отличный материал, и исходная статья хороша. Жаль, наши банкиры вряд ли поймут...

2  
А им и не в таких терминах это надо рассказывать. надо говорить не о пиковой нагрузке, а о стоимости одной транзакции.
С другой стороны я бы не сказал, что этот результат релевантен только для финансовой индустрии. Так вышло, что большая часть потребителей системы там. Резон экономить ресурсы есть у всех.

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]


Яндекс.Метрика