Правильная платформа для Java EE приложений: как z/OS + DB2 оказались в 3 раза быстрее Linux + Oracle

    Введение


    В настоящее время все больше и больше корпоративных приложений разрабатываются на основе переносимых кроссплатформенных технологий, таких как Java Enterprise Edition. В состав данной платформы входит набор программных интерфейсов, позволяющих разработчикам абстрагироваться от конкретных СУБД и механизмов очередей сообщений. Это позволяет развернуть приложение практически на любой платформе, в том числе и на мейнфрейме.

    В сообществе специалистов по информационным технологиям распространено представление, что мейнфреймы – это очень надежная, но уступающая по производительности привычным решениям на основе процессоров Intel и операционной системе Linux платформа. В данной статье мы хотели бы поделиться результатами тестирования производительности одной и той же банковской платежной системы, работающей на IBM zEnterprise EC12, но в одном случае использующей Linux и СУБД Oracle, а в другом – операционную систему z/OS и СУБД DB2.

    Что мы тестировали


    Тестируемая банковская платежная система представляет собой приложение, построенное на платформе Java EE 6. Для организации бизнес-логики используются компоненты EJB. Взаимодействие с СУБД осуществляется посредством технологии JPA, в качестве провайдера при этом выступает Hibernate. Приложение активно использует очереди сообщений, взаимодействуя с ними посредством технологии JMS. В обоих вариантах развертывания системы в качестве сервера приложений использовался WebSphere Application Server 8.5.5 Network Deployment, при этом встроенный в него механизм Service Integration Bus (SIBus) применялся для управления очередями сообщений.

    Все обрабатываемые платежи можно разделить на два типа: срочные и несрочные. Срочные платежи проводятся сразу же после их считывания из входной очереди. В процессе же обработки несрочных платежей можно выделить три последовательные фазы. Первая фаза – фаза приема – платежи считываются из входной очереди системы и регистрируются в базе данных. Вторая фаза – фаза многостороннего взаимозачета – выполняется в однопоточном режиме. На данной фазе осуществляется проводка всех принятых до этого несрочных платежей, при этом учитываются взаимные обязательства участников системы. Третья фаза – фаза рассылки уведомлений – запускается автоматически после завершения второй фазы. На данной фазе осуществляется формирование и рассылка информационных сообщений (квитанций) для всех участвующих в многостороннем взаимозачете счетов. Каждая фаза представляет собой одну или нескольких транзакций включающих в себя сложную последовательность действий, выполняемых сервером приложений и СУБД.

    Важно отметить, что для разработчиков данной платежной системы основной платформой является операционная система Linux и СУБД Oracle. Однако благодаря использованию JPA и Hibernate удалось очень быстро осуществить миграцию приложения на DB2 z/OS путем замены используемого диалекта на org.hibernate.dialect.DB2390Dialect. Для миграции базы данных существует утилита IBM Data Movement Tool.

    Описание тестового стенда Linux + Oracle


    Архитектура тестового стенда соответствует принятым в мире Linux лучшим практикам. На мейнфрейме zEnterprise EC12 модель H89 было выделено два логических раздела (LPAR), на одном, содержащем 10 центральных процессоров (CP) и 25 ГБ ОЗУ, был развернут сервер приложений WebSphere Application Server с установленной на нем платежной системой, а на другом, содержащем 10 CP и 158 Гб ОЗУ, – СУБД Oracle. Связь между тестируемым приложением и СУБД осуществлялась посредством технологии JDBC Type 4.



    Используемые версии программного обеспечения:

    — SUSE Linux Enterprise Server 11 SP3;
    — WebSphere Application Server 8.5.5 Network Deployment;
    — Oracle DB 11gR2.

    Описание тестового стенда z/OS + DB2


    Стенд на базе операционной системы z/OS представлял собой один выделенный на мейнфрейме zEnterprise EC12 модель H89 логический раздел (LPAR), содержащий 32 Гб ОЗУ и 10 центральных процессоров (CP) плюс 10 процессоров, используемых для работы Java-приложений и СУБД DB2 (zIIP). На данном логическом разделе было развернуто все необходимое программное обеспечение: СУБД DB2 и сервер приложений WebSphere Application Server for z/OS. Связь между тестируемым приложением и СУБД DB2 осуществлялось посредством технологии JDBC Type 2 с помощью обращения к нативным библиотекам клиента СУБД без использования сетевых соединений.



    Используемые версии программного обеспечения:
    — z/OS 2.1;
    — WebSphere Application Server 8.5.5 for z/OS;
    — DB2 z/OS v11.

    После подготовки и настройки каждого тестового стенда были выполнены серии тренировочных тестов и тюнинг развернутых приложений.

    Проведение тестирования и результаты


    Профиль нагрузки при проведении испытаний повторял профиль нагрузки реально работающей системы. На вход подавалось 2 млн. несрочных платежей, объединенных в пакеты по 500, 1000 и 5000 платежей. Данные пакеты в виде электронных сообщений подавались на вход системы непрерывным потоком (один пакет в одном сообщении). Параллельно на вход системы подавались электронные сообщения, содержащие срочные платежи (один платеж в одном сообщении). Перед проведением тестов в каждую базу данных было загружено требуемое число участников платежной системы и информация о проведенных ранее платежах.

    В процессе выполнения тестов были получены следующие результаты:



    Гарантированное время обработки срочного платежа – важнейший показатель уровня предоставления сервиса платежной системой – на инсталляции с z/OS и DB2 оказалось в 3 раза меньше, чем на инсталляции с Linux и Oracle.

    Чем можно объяснить полученные результаты? Стоит отметить саму концепцию монолитной системы, реализованную в z/OS, – выполнение множества задач на едином образе операционной системы и наличие оптимизированных способов взаимодействия между ними. Помимо уникального по своим характеристикам планировщика задач в состав z/OS входят т.н. cross-memory services – технология, позволяющая передать управление из адресного пространства одной подсистемы напрямую адресному пространству другой всего лишь с помощью нескольких специальных команд процессора, без обращения к планировщику операционной системы. В других операционных системах реализации стека межпроцессного взаимодействия (Inter-Process Communication, IPC) занимают сотни, а то и тысячи машинных команд, включающих вызовы функций ядра операционной системы. Именно посредством cross-memory services осуществляется взаимодействие WebSphere Application Server for z/OS с СУБД DB2 z/OS при использовании JDBC Type 2.

    Так как рассматриваемая платежная система изначально разрабатывалась без привязки к конкретной СУБД, механизм multiversion concurrency control (mvcc), применяемый в СУБД Oracle, приложением не использовался. При этом известно, что реализация mvcc в Oracle не является бесплатной, за удобство приходится платить аппаратными ресурсами. В случае с DB2 все эти ресурсы были потрачены непосредственно на выполнение полезной работы. Следует отметить, что разработка данной СУБД ведется в тесном сотрудничестве с командой разработки процессоров System z, что обеспечивает более эффективное использование ею всех возможностей платформы (не все возможности процессоров System z доступны на Linux).

    Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux. Это веский аргумент в пику имеющемуся среди специалистов по информационным технологиям убеждению, что Java плохо работает на z/OS и что не следует использовать данную операционную систему для запуска Java-приложений.

    Интересно так же замерить время выполнения каждого этапа обработки несрочных платежей:



    На каждой фазе инсталляции на z/OS и СУБД DB2 выигрывает по времени более чем в 3 раза.

    Отдельно были проведены стресс-тесты обработки срочных платежей, подаваемых в систему непрерывным потоком. Целью тестирования было измерить максимальное количество транзакций в секунду, обрабатываемых платежной системой в соответствующей инсталляции.



    При интерпретации результатов важно учитывать, что каждому срочному платежу соответствует свое платежное сообщение, которое в процессе обработки проходит через несколько очередей, каждый раз порождая новые транзакции в СУБД. Таким образом, число транзакций, выполняемых в СУБД за секунду, в несколько раз больше, чем представлено в таблице.

    Заключение


    Проведенное нагрузочное тестирование наглядно показало, что использование родных для мейнфрейма операционной системы и СУБД в качестве платформы для работы корпоративных приложений не только гарантирует высочайшую надежность решения (с чем обычно никто не спорит), но и обеспечивает рекордные показатели производительности. В нашем случае выигрыш в производительности оказался трехкратным.

    Благодаря тому, что тестируемое приложение построено на переносимой платформе Java EE, процедура миграции на операционную систему z/OS была осуществлена в кратчайшие сроки. Так же всего за один день была проведена миграция схемы данных из СУБД Oracle в СУБД DB2 z/OS. При этом заметим, что команда разработчиков платежной системы не имела большого опыта работы с мейнфреймами, что не помешало ей с помощью сотрудников российского офиса IBM подготовить и успешно провести тестирование.

    В заключение хочется порекомендовать разработчикам корпоративного программного обеспечения присмотреться к мейнфреймам. Инвестиции в обучение работе с операционной системой z/OS и СУБД DB2 не будут напрасны, потому что вы сможете предложить вашим заказчикам решения на надежной отказоустойчивой и, как мы смогли продемонстрировать, очень быстрой платформе.
    IBM 83,75
    Компания
    Поделиться публикацией
    Комментарии 43
    • +5
      1. Используете систему виртуализации
      2. Linux поставлена в неравные условия, ведь фактически запускается и работает на 2-х 10-ти ядерных машинах, а не на одной 20-ти ядерной, следовательно, не может пользоваться вычислительной мощностью сполна.
      3. SUSE linux, как и любой бинарный дистрибутив будет значительно проигрывать по скорости операционке, которая не только под вендора заточена, но еще и под конкретное железо
      4. DB2 так же имеет заточку под вендора.

      Так что связка z/OS+DB2 по-любому работает быстрей, а вот то, что НАСТОЛЬКО, это действительно открытие.

      • +6
        С тем же успехом можно было написать 10 и 110 крат.
        Вместо анализа производительности содержание какого-то маркетингового буклета. Начальные условия систем (наполнение, исторические фрагментации и т.д.) неизвестны. Анализ запросов к БД отсутствует. ПО отличается судя по названиям. «После подготовки и настройки каждого тестового стенда были выполнены серии тренировочных тестов и тюнинг развернутых приложений.» — вообще прекрасно.
      • 0
        LPAR B и C взаимодействуют по сети? Входящие запросы тоже через этот же сетевой интерфейс валились? А решение на z/OS ходит в базу DB2 локально.
        • +3
          Этож блог компании IBM, естественно тут будет такой маркетинг без доказательств)
          • +2
            Поставили Oracle и Linux на мейнфрейм, в котором для Linux предусмотрена прослойка zLinux и померили, по сути, насколько тормозит zLinux.
            Вы же сами и написали в самом начале — «мейнфреймы – это очень надежная, но уступающая по производительности привычным решениям на основе процессоров Intel и операционной системе Linux платформа».
            Давайте по-честному, поставьте Oracle и Linux на железо с Intel и сравните показатели. Ставлю пиво, что Linux с Intel выиграют.
            • +1
              Чтобы совсем по-честному, надо на Solaris Sparc.
              • 0
                Вне контекста данного теста, а «правды для».

                Linux for z — это нативная версия Linux, скомпилированная под архитектуру System z, никакой отдельной «прослойки» (zLinux) там нет. Все бинарные пакеты, включая Oracle, также скомпилированы под эту архитектуру.

                Linux for z, как и любая ОС на архитектуре System z может исполняться и в «железном» режиме, и под управлением гипервизора z/VM.
              • 0
                > Помимо уникального по своим характеристикам планировщика задач в состав z/OS входят т.н. cross-memory services – технология,
                > позволяющая передать управление из адресного пространства одной подсистемы напрямую адресному пространству другой

                DOS вроде такое уже умел.
                • 0
                  DOS — это который MS-DOS или этот?
                  • 0
                    MS-DOS, конечно
                    • 0
                      MS-DOS — это однозадачная операционная система, речь же идет о коммуникации двух одновременно работающих приложений (у каждого свое адресное пространство, в мире мейнфреймов именно этот термин обычно и используется).
                • +1
                  гавно, а не анализ. Я бы даже сказал, что анализа нету. Потому что не показано, во что именно упирается каждый из бенчмарков.

                  Разное железо, непонятные юзкейсы, непонятная методика подсчета.

                  <тут было совсем грубо, но я убрал>
                  • +2
                    потому что это не анализ, а реклама IBM
                  • 0
                    Как единственный пока представитель нашей небольшой z-команды на Хабре постараюсь ответить на все комментарии.

                    Во-первых, отвечу на претензии вида «разное железо». В тестах использовалось два идентичных по параметрам мейнфрейма, количество ресурсов, выделямых на каждый вариант развертывания приложения, определялось организаторами тестирования. Как видите в варианте с Oracle'ом памяти выделено даже больше, совокупное число процессоров было одинаковым.

                    Во-вторых, отвечу на претензии вида «разные названия ПО». Если честно претензия непонятна, естественно СУБД использовались разные, от разных производителей. Сервер приложений был одним и тем же — WebSphere Application Server 8.5.5, просто версия под распределенные системы называется «Network Deployment», а версия для z/OS — «for z/OS». Тестировалось одно и то же прикладное решение, основанное на платформе Java EE.

                    В-третьих, хотя пассаж про «прослойку zLinux» уже прокомментировали, немного дополню. И Linux, и z/OS работали под управлением аппаратно-микропрограммного гипервизова Processor Resource and System Manager (PR/SM). Никакой дополнительной виртуализации для Linux не использовалось.

                    Самое существенное высказанное замечание — в случае z/OS использовалась ее сила — colocation, а в случае Linux — СУБД и сервер приложений были разнесены на разные LPAR'ы и взаимодействовали по сети (в тесте использовалась реальная сеть 10 Gb). Возможно сравнение с вариантом «все подсистемы в рамках одного образа Linux» было бы интереснее с технической точки зрения, но это был бы синтетический тест. Почему-то на практике специалисты по Linux так решения для промышленной эксплуатации не разворачивают. Они стараются разносить СУБД, сервер приложений, а был бы еще и MQ, то и его, по разным образам операционной системы. Почему они так делают я сказать не могу.

                    По поводу сравнения разных дистрибутивов Linux. Дело не в дистрибутиве, а в том, что при любом дистрибутиве Linux остается Linux'ом со всеми его плюсами и минусами. z/OS как проприентарная (я все же употребил это страшное слово!) система адресно затачивается под железо. Упрекать за это — все равно, что причитать: «ага, ваш боксер победил, потому что тренировался, а наш — нет!» Linux же разрабатывается сообществом как кроссплатформенное решение. В этом его сила, и… слабость. В данной статье эта слабость наглядно продемонстрирована.
                    • 0
                      > Возможно сравнение с вариантом «все подсистемы в рамках одного образа Linux» было бы интереснее с технической точки зрения, но это был бы синтетический тест.
                      Почему синтетический?
                      Задача тестов, обычно, на практике определить лучшую конфигурацию по какому либо критерию, а Вы таким заявлением отсекаете конфигурацию, которая потенциально могла работать лучше (или хуже) других основываясь на субъективном утверждении «так решения для промышленной эксплуатации не разворачивают».

                      Даже если сейчас не разворачивают, то может быть результаты такого тестирования показали бы преимущества такого подхода по сравнению с разносом всего по разным образам? Или наоборот, не показали бы.
                      • 0
                        Я с вами согласен, но на принятие решение о выборе конфигурации влияет множество факторов, не только скорость работы. Тестирование — процесс не бесплатный, а довольно затратный. Тестируется не просто сферический конь в вакууме, а конфигурация, которая может удовлетворить заказчика. Заказчик естественно выбирает исходя из имеющихся лучших практик. В мире линукс такой лучшей практикой является разнесение компонентов стека по разным образам операционной системы.

                        Для меня, как технического специалиста, архитектора, безусловно интересны все варианты, но к сожалению возможности не безграничны. Сам был бы рад и надеюсь мы еще сможем протестировать и DB2 + Linux vs DB2 + z/OS, и другие варианты, ну и конечно же поделиться ими с сообществом.
                    • +1
                      а где сравнение Linux+DB2 и Linux+Oracle?
                      • 0
                        Я согласен, данное сравнение было бы интересно, но мы — авторы статьи — занимаемся мейнфреймами, может быть коллеги, занимающиеся распределенными системами, порадуют читателей таким материалом.
                        • 0
                          ну тогда где сравнение z/OS+DB2 и Linux+DB2?
                          • +1
                            вы, пардон, рекламой занимаетесь.
                            • –4
                              Лет пять назад, если мне не изменяет память, я точно так же хейтил Microsoft и тролил их евангелистов, ну как тролил, искренне считал, что искрометно тролю. Потом вырос.

                              Я понимаю, что данная статья задевает чувства многих людей, которые искренне любят Линукс и открытые исходники, но числа есть числа, с другой стороны — только невнятные предположения. При этом ненавидеть IBM линукс-сообществу наверное не стоит, корпорация вкладывает миллиарды долларов в развитие данной операционной системы.
                              • +3
                                мне наплевать и на линукс и на зэтос и на что угодно.

                                Претензия к автору у меня простая: я анализа в посте не вижу. Поэтому я делаю вывод, что бенчмарки сделаны хз как, а их результаты приведены в рекламных целях.
                                • –1
                                  Всеми данными, которыми можно было поделиться мы поделились. Начинать публиковать планы выполнения запросов нам никто не позволит, да и если честно, не думаю, что это так важно, т.к. очень специфичная для конкретного приложения информация. А вот архитектурно значимые вещи: выбор операционной системы, СУБД, топологии развертывания и их влияние на работу приложения определенного класса — OLTP — продемонстрированы. Первый комментатор правильно отметил, что использование родной для платформы операционной системы вместе с таковой же СУБД очевидно даст лучшие результаты по производительности, это всем понятный факт. Но вот настолько лучшие, думаю, для многих оказалось сюрпризом. Можно конечно от этого отмахнуться и списать на «вы все врети», но это какой-то не инженерный подход.
                                  • +2
                                    Представим на секунду такую ситуацию: вы нашли сценарий, в котором вы втрое уделываете Linux+Oracle и написали о нем. При этом вы позиционируете, что ваше решение втрое быстрее конкурента.

                                    При этом проблема может быть:
                                    1. в планах выполнения запросов
                                    2. в любой настройке проигравшей конфигурации
                                    3. в методике
                                    4. в чем угодно еще


                                    Без анализа это все гроша ломаного не стоит. Вопросов миллион.

                                    Например, по методике. Совершенно непонятно, на каком уровне загрузки системы вы меряете ваше время отклика. Насколько были утилизированы диск, память, проц?
                                    • 0
                                      Очень важно, что мы и хотим донести до аудитории — мы не нашли кейс, нам принесли реальное бизнес-приложение, решающее реальную бизнес-задачу — банковскую платежную систему. Данная система до этого разрабатывалась исключительно на Oracle и Linux. С нашей помощью была осуществлена миграция данной системы на z/OS + DB2, после чего были проведены сравнительные испытания, результатом которых мы и делимся.

                                      Все данные телеметрии, собранные при проведении тестов у нас имеются (больше сотни страниц), есть все необходимые графики. По понятным причинам мы не можем выложить это в публичный доступ. Если вам или кому-нибудь другому данная информация действительно интересна, то прошу написать мне личное сообщение, в котором указать, какую компанию вы представляете, после чего можем встретиться в нашем офисе и пообщаться.
                                      • +2
                                        Ладно фиг с ними с данными телеметрии. Интересуют конфигурации ПО. Например, в том же Oracle как было сконфигурировано использование памяти AMM или в ручную, если в ручную то как именно? Использовались ли Large Pages? В том же hibernate, про DB2 сказано, что был использован org.hibernate.dialect.DB2390Dialect, а что было для Oracle? и т.д. Есть гарантия, что в обоих случаях над конфигурациями сидели DBA, а не в одном случае была установка по-умолчанию, а в другом тонкий тюнинг от DBA?
                        • 0
                          А какая виртуальная машина Java использовалась в обоих случаях? Извините, если пропустил.
                          • 0
                            IBM JDK под соответствующую ОС.
                            • 0
                              вот и ещё одно «горлышко»
                              • 0
                                В чем же оно заключается?
                                • 0
                                  вы уверены, что реализация IBM JDK одинаково производительна на разных ОС?
                                  • –1
                                    Если вы имеете ввиду, что IBM добавляет какие-то закладки в свою JDK на Linux, чтобы та тормозила, то уверен, что такого нет. Верить в такие закладки — это все равно, что верить в слив данных Интелом в АНБ о том, какой код выполняется на их процессорах и что он делает.

                                    Конечно коллеги, разрабатывающие Java для z/OS по максимуму используют возможности аппаратуры. Я как-то писал об этом в личном блоге большую статью. По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место».
                                    • 0
                                      Если вы имеете ввиду, что IBM добавляет какие-то закладки в свою JDK на Linux, чтобы та тормозила

                                      а что, производительность может отличаться только когда целенаправленно «закладки» делают?

                                      По сути быстрая Java — это одно из конкурентных преимуществ платформы, а не «узкое место»

                                      но и про это в статье ни слова нет
                                      • –2
                                        Цитата из статьи:

                                        Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux. Это веский аргумент в пику имеющемуся среди специалистов по информационным технологиям убеждению, что Java плохо работает на z/OS и что не следует использовать данную операционную систему для запуска Java-приложений.
                          • –2
                            Коллеги, кто действительно заинтересовался темой, приходите на семинар 26 и 27 марта z13 Technical Enablement Roadshow, где мы расскажем про новый мейнфрейм. Семинар будет исключительно технический, приедут коллеги из Монпелье, Франция. В кулуарах можно будет обсудить и Linux vs z/OS, а так же другие темы.
                            • 0
                              «А газету в кислоту» ©
                              Без учёта СУБД Оракл — единственный достоверный показатель. Как раз по нему и отличия не грандиозные.
                              А DB2 оттуда тоже выкинута?
                              • 0
                                Я не понял о чем вы говорите, если честно. Откуда «оттуда»?
                                • 0
                                  Оттуда-же где про Оракл — 41.75 без учёта DB2?
                                  • 0
                                    Да, речь идет о времени работы исключительно расчетной части приложения.
                              • 0
                                Еще не очень понял, все таки Suse Linux или zLinux?
                                • 0
                                  www-03.ibm.com/systems/z/os/linux/getstarted.html
                                  Самые популярные дистрибутивы — SUSE и RedHat, специальные сборки под процессор мейнфрейма, обычно именуются s390. Выше Евгений Хабаров хорошо расписал этот момент.
                                  • 0
                                    В данном случае использовался SUSE Linux Enterprise Server for System z

                                    zLinux — это «жаргонное» название Linux-дистрибутивов, скомпилированных для платформы System z, т.к. полное официальное название не очень удобно для повседневного использования.
                                  • 0
                                    Del

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое