Сo-location как путь к высокой производительности Java EE приложений

Введение

Спецификация JDBC API, разработанная в рамках Java Community Process (JCP), определяет только лишь набор интерфейсов и базовых классов, которые в свою очередь должны быть реализованы разработчиками того или иного драйвера. Можно выделить четыре подхода к разработке драйверов JDBC:

1. JDBC Driver - Type 1 (JDBC ODBC Bridge)
   
   Данный подход подразумевает, что код, написанный на языке Java, обращается к коду, реализованному на одном из нативных языков, поддерживаемых Microsoft, который уже в свою очередь общается с базой данных.
   
   
2. JDBC Driver - Type 2 (Part Native Driver)
   
   Данный подход подразумевает, что код, написанный на языке Java, обращается к коду, реализованному производителем СУБД на нативном языке, который уже в свою очередь общается с базой данных.
   
   
3. JDBC Driver - Type 3
   
   Данный подход подразумевает, что код, написанный на языке Java, обращается к коду, реализованному производителем сервера приложений, который уже в свою очередь общается с базой данных. В данном случае драйвер взаимодействует с программным обеспечением промежуточного слоя. Данный тип драйвера отличается особой гибкостью, поскольку не требует установки никакого кода на клиентской стороне и один драйвер может обеспечивать связь с несколькими типами СУБД.
   
   
4. JDBC Driver - Type 4 (Thin Driver)
   
   Данный подход подразумевает, что реализованный производителем СУБД код драйвера, написанный на языке Java, напрямую взаимодействует с базой данных. Другими словами данный тип драйвера представляет собой чисто Java-библиотеку, транслирующую JDBC-запросы напрямую в специфичный протокол базы данных.
   

В мире распределенных систем наиболее используемым типом драйвера является JDBC Type 4, в то время как в мире мейнфреймов (IBM z Systems) принят другой подход. Целью данной статьи является продемонстрировать какие именно преимущества с точки зрения обеспечения высокой производительности можно получить, просто выбрав правильный тип драйвера.

• Бенчмарк
  
  
• Профиль нагрузки
  
  
• Данные
  
  
• Анализ
  
  
• Потребление процессорных ресурсов
  
  
• Полученные значения
  
  
• Выводы

Как настроить сквозную аутентификацию в WebSphere Application Server, z/OS и DB2

По умолчанию команды операционной системы из приложений, развернутых на сервере WebSphere Application Server for z/OS, выполняются от имени пользователя, под которым запущен servant. Под этим же пользователем осуществляется соединение с базами данных, например DB2 или IMS по JDBC Type 2. Но можно настроить сервер приложений таким образом, чтобы обеспечить сквозную аутентификацию: пользователь вашего приложения аутентифицируется на сервере и под этим же именем соединяется с базой данных и выполняет команды в операционной системы: создает файлы в USS (например с логами), работает с наборами данных, а так же запускает на выполнение пакетные задания (JOB'ы).

Процесс сквозной аутентификации

Выглядит процесс следующим образом. При обращении к странице, находящейся в защищенной зоне, будет запрошен логин и пароль пользователя, если настроена, например, BASIC аутентификация по паролю.

Введенные данные проверяются с помощью сервера защиты z/OS (IBM предлагает продукт Resource Access Control Facility (RACF)) и если они верны, то открывается запрошенная страница.

При этом действия в операционной системе будут выполняться под тем пользователем, под которым произведена аутентификация.

И под ним же будут выполняться запросы в СУБД DB2: см результат выполнения запроса SELECT CURRENT SQLID FROM SYSIBM.SYSDUMMY1: ROOT.

Правильная платформа для Java EE приложения или как Линукс оказался в 3 раза медленее z/OS

Ваш покорный слуга написал еще одну статью на Хабрахабр - Правильная платформа для Java EE приложений: как z/OS + DB2 оказались в 3 раза быстрее Linux + Oracle.

Краткое резюме: очень быстро мигрировали Java EE приложение, использующее Hibernate, на мейнфрейм и провели сравнительное тестирование, с одной стороны данное приложение на zLinux + Oracle (2 LPAR), с другой - оно же на z/OS + DB2 (1 LPAR). Вариант на z/OS + DB2 работал быстрее в 3 раза. Конфигурация выбрана исходя из требований заказчика, для которого выполняли тестирование, но в принципе соответствует реальным практикам, почему-то именно так и разворачивают - на Linux стараются вынести каждую подсистему на свою виртуальную машину, на z/OS - весь стек разворачивается вместе, тем самым используются примущества операционной системы, в частности Cross-Memory Services - механизм, позволяющий из одного адресного пространства (WebSphere Application Server) обратиться к другому (DB2) с помощью нескольких машинных команд, минуя планировщик ОС. Преимущества подхода перед типичным кодом межпроцессной коммуникации (IPC), содержащем сотни, а то и тысячи машинных инструкций, да к тому же выполняющем обращения к ядру, очевидны любому инженеру, знакомому с операционными системами чуть глубже, нежели на уровне "интерфейс унылый/интерфейс неунылый".

Отдельно отмечу, что исключительно расчетная часть на Java под z/OS выполнялась быстрее на 25%, что является отдельным приветом сторонникам мнения "Java на мейнфрейме тормозит и вообще".

P.S. Очень распространенное заблуждение, что zLinux выполняется только на z/VM. В данном случае и z/OS и zLinux выполнялись на LPAR'ах, VM в тесте не участвовала.

UPD: Хабраэксперты не подкачали, адекватные комментарии и претензии затерялись в ворохе: "Мы веруем в Линуха святого, а вы говорите, что он в чем-то хуже? Вы все врети, вы - сурковскаяпропаганда!!!" Грамотность аудитории оставляет желать лучшего, но это - уже наша недоработка. Основная претензия - разнесение подсистем на линуксе по разным LPAR'ам, но кто виноват, что линуксоиды так деплоят. В целом интерес к теме прослеживается и это не может не радовать.

UPD2: С нетерпением жду реакции анонимных аналитиков с ЛОРа.

Понравилось сообщение - подпишитесь на блог