Введение
В настоящее время все больше и больше корпоративных приложений разрабатываются на основе переносимых кроссплатформенных технологий, таких как 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 не будут напрасны, потому что вы сможете предложить вашим заказчикам решения на надежной отказоустойчивой и, как мы смогли продемонстрировать, очень быстрой платформе.
Автор: marks
