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

Меню сайта

Календарь
«  Июнь 2010  »
ПнВтСрЧтПтСбВс
 123456
78910111213
14151617181920
21222324252627
282930

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

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

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql zOS MVS OS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere z/VM Share history GitHub OS/VS S/379 сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург видео Выступления Dis нагрузка пример Assembler VM/ESA НИЦЭВТ Docker Sie Kubernetes OpenShift Environment RedBook RedHat рынок 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 Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа Москва

Статистика

Главная » 2010 » Июнь » 29 » Новый материал про IMS
Новый материал про IMS
19:13
Уважаемые коллеги!
На сайте - новая коротенькая статья про IMS, конспект обзора от IDC. Оригинал расположен тут. Решение сильно сократить объем материала вызван большим количеством "воды" в исходном тексте. Приятно осознавать, что ведущая аналитическая фирма отдает должное перспективам дальнейшего применения IMS и списывать его в утиль пока не собирается.
Конспект написан Костырко Александром, студентом 1 курса факультета ИУ МГТУ им. Баумана. Чтобы не путать его с тем Костырко Александром, который ведет этот сайт, автор данной статьи будет обозначаться впредь как Костырко Александр SE (second edition). Данная статья - его дебют в области технических статей в общем и на мейнфреймовскую тематику в частности. Критика приветствуется, а адекватная реакция родителя-редактора сайта не гарантируется, по понятным причинам)))
Просмотров: 2304 | Добавил: akost
Всего комментариев: 9
1 cicser  
Прочитал. Интересно. Особенно понравился этот абзац:
"...IMS Customer Experiences
How Many IMS Administrators Does It Take to Drive over 70 Mil l ion
Banking Transactions per Day for over 820 Banks?
In this case, the answer is 10. Fiducia, a major IT service provider in Germany with 45
years of experience in the field, provides IT services to over 820 banks representing a
total of 10,217 branches; 101,500 workstations; 6,548 local servers; and 22,832
ATMs. It supports 63 million accounts, 5.5 million of which are directly managed
online by customers. The underlying data engine is a configuration of eight IMS
instances deployed on two Parallel Sysplex configurations of System z systems with
total processing power of 55,000 MIPS. These systems drive an average of 2,750
banking transactions per second. In addition to the eight main systems, four others
provide supporting operations. DB2 for z/OS and another relational DBMS are linked
to IMS for query and reporting support. These systems are linked together and
accessible by a variety of means, including IMS Connect for TCP/IP, DB2, and CICS..."
Конечно, будет самонадеяно заявлять, не зная деталей конфигурации, но выдать
2750 транзакций в секунду на 55000(!) MIPS - не так уж и впечатляет. Конечно,
не все они под ims'ом, но, как видим, и другие системки там живут. Жаль нет
ссылки какой процент транзакций от всего объема вообще в какой системе
обрабатывается. Опять же, ims'ов аж 8 экземпляров разделяют эту нагрузку.
Почему? Не в том ли дело, что один экземпляр не в силах переварить ее?
Это к вопросу об архитектуре ims.

6 ggv  
- ну заявленные финансовые транзакции выполняет только IMS, другие подсистемы их не выполняют
- нет, не потому, одна отдельно стоящая IMS система на Z старшей серии в полной комплектации способна выполнять до 44000 финансовых транзакций в секунду.
Это к вопросу об архитектуре IMS.
И всегда, на одинаковом железе, IMS TM работает быстрее CICS, при выполнении одинаковой работы - в силу своей архитектуры, которая была описана в теме про IMS

7 evgeni77  
Привет всем фанатам мэйнфреймов! Нас мало но мы в тельняшках.

Я тут пошукал немножко по поводу циферей. Связался непосредственно с архитектором Fiducia (Вольфганг Штраус). Вот что он мне поведал:

We use IMS DB/DC. Our Databases that are connected are FF, some HALDBs, DB2 (I guess 60 percent) and ORACLE (not much). We don't use CICS as a transaction manager! CICS is only used for some ISC connections to business partner.. 2750 trans/sec average is a very high number. This value includes DL/I, Oracle and DB2 reads and updates. Our normal transaction mix.I know the theoretical laboratory values. They are funny but I think in reality there are so much differnt parameters where much time is spent (MQ, DB2, APPC, IP, mid tier server Mid, many DB updates in a transaction (incluedes also DB2 queries and updates) that 300-400 transaction/sec per system is a high value.

На счет цифр - в общем то как я и ожидал - толку от них никакого. А вот почему эта крупнейшая компания выбрала именно IMS TM я еще спросил в догонку.
Вот еще информация от человека из нашей лаборатории:

These the are the highest numbers I've come across from a customer: 7000 trans/sec - a trans ranged from 4 to 35 DB calls. 110 million trans a day (mostly within a 16 hour period). Approx 1/2 billion DB calls a day.

Ну вот. А в лабораторных условиях мы конечно добивались куда более смешных показателей (44000t/s). Транзакции конечно мерять можно, но ссылаться на эти цифры я бы не стал. Это как спросить меня сколько я кружек пива выпью.


8 akost  
О! Женя! Наконец-то! ты видишь, во что превратилось тихое обсуждение короткого конспекта тут? Прям готовый маркетинговый материал, благодаря Григорию и Остапу. В среду продолжим обсуждение (с применением твоих цифр) под телятину и красное вино уже в реальном, а не в виртуальном пространстве.

9 evgeni77  
Здравствуйте Александр! Ну, с конспектом все в порядке, основная контроверсия там с комментариями cicsera.

Желаю вам продуктивной, но душевной посиделки! smile


2 cicser  
Еще один хороший пример:
"...When Processing Debit Card Transactions, Seconds Count
One of North America's largest retail banking operations handles over 40 million retail
banking transactions per day, including drive-through banking, ATMs, debit card
purchases, online applications, and interactions with other institutions around the
world, meeting service levels of a few seconds. The workload is handled by IMS
deployed in a Parallel Sysplex configuration of 12 IMS systems, receiving card
transactions through a front-end CICS system. These are the elements of the
environment for two key banking applications: one handles the online transaction
processing, and the other operates in the background maintaining and balancing the
accounts. The former application uses IMS Fast Path, while the latter is a full-function
High Availability Large Database (HALDB) implementation. The total amount of data
managed is in the 40 terabyte range, with plenty of room for expansion..."
То есть, на фронте КИКС (бизнес-транзакции), а через DBCTL идет работа с базой данных ims.
Конфигурация, с точки зрения производительности/цены почти идеальная. Но эти 40лямов
транзакций выполняет кикс (а-ля сервер приложения), а чего все лавры ай-эм-эсу (последнюю
триграмму не трактуйте буквально)?

5 ggv  
Потому как традиционно сервера приложений масштабируются не в пример легче, чем базы данных, особенно это применимо к OLTP базам данных.
Вот так и здесь - нет большой заслуги в выполнении этого количества приложений - есть бОльшая заслуга в проведении соответсвующих этим приложениям транзакций в базе данных.
Так понятнее?

3 cicser  
Кстати, 40 лямов транзакций за день - это 463 транзакции в секунду.
При неравномерном распределении нагрузки - до 1500 транзакций в секунду.
Для таких систем это довольно средний показатель.

4 akost  
Нашим совместным решением с автором конспекта было именно НЕвключение в статью маловразумительных примеров. Именно потому, что каждая конкретная установка строится так или иначе не потому, что CICS хорош или IMS крут, а потому, что учитываются масса факторов, включая унаследованное ПО, опыт разработчиков и проч.

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


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