Передовые методики и рекомендации по настройке для обработки больших объектов в WebSphere Enterprise Service Bus

Шаблоны проектирования и настройка

Обеспечение оптимальной производительности систем обработки больших объектов является проблемой, с которой часто сталкиваются пользователи промежуточного программного обеспечения. Как правило, «большими» объектами, требующими особого внимания, могут считаться объекты объемом свыше 1 МБ. Цель настоящей статьи — предоставить необходимую информацию и рекомендации по успешному использованию продукта WebSphere Enterprise Service Bus (ESB) V7 для эффективной обработки больших объектов в 64-разрядной производственной среде.

Мартин Росс, специалист по анализу производительности ПО, IBM

Мартин Росс — специалист по анализу производительности WebSphere Enterprise Service Bus (г. Херсли, Великобритания); он работает с этим программным продуктом с 2006 года. Закончил Саутгемптонский университет по специальности «Программирование».



31.10.2012

Введение

Обеспечение оптимальной производительности систем обработки больших объектов является проблемой, с которой часто сталкиваются пользователи промежуточного программного обеспечения. Как правило, «большими» объектами, требующими особого внимания, могут считаться объекты объемом свыше 1 МБ. Цель настоящей статьи — предоставить необходимую информацию и рекомендации по успешному использованию продукта WebSphere Enterprise Service Bus (ESB) V7 для эффективной обработки больших объектов в 64-разрядной производственной среде.


Важные замечания

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

Ограничения JVM

Главные преимущества 64-разрядной архитектуры относятся к управлению памятью и доступности. Увеличенная ширина шины данных позволяет поддерживать объем адресуемой памяти больше 4 ГБ, обычно доступных в 32-разрядной архитектуре. Хотя объем динамической памяти (кучи) Java зависит от типа операционной системы, обычно для 32-разрядной JVM он ограничивается примерно 1,4 ГБ. Поддержка увеличенного объема памяти, которую обеспечивает 64-разрядная архитектура, несколько ослабляет ограничения на размер динамической памяти Java, который при выполнении операций с большими объектами может стать ограничивающим фактором в 32-разрядной системе.

Как правило, для обработки больших объектов следует применять 64-разрядные JVM.

Размер бизнес-объектов, находящихся в оперативной памяти

Следует отметить, что размер бизнес-объектов (BO) может быть значительно больше, чем их представление на шине. Это может быть обусловлено несколькими причинами, в частности, различием в схемах кодировки символов, изменениями, вносимыми при прохождении сообщения по системе, а также копиями BO, создаваемыми во время транзакций для исправления ошибок и восстановления изначальных параметров.

Количество параллельно обрабатываемых объектов

Доступное время отклика, как правило, обратно пропорционально количеству параллельно выполняемых задач обработки объектов, хотя современные аппаратные средства SMP (симметричная мультипроцессорность) позволяют в некоторой степени ослабить эти ограничения. Для достижения наилучшего времени отклика системы можно ограничить количество одновременно обрабатываемых сообщений — это особенно актуально при обработке больших объектов данных из-за возможных нагрузок на динамическую память Java.

Ограничение количества одновременно обрабатываемых сообщений может быть достигнуто за счет:

  • ограничения количества пользователей, создающих рабочую нагрузку;
  • настройки соответствующего пула потоков для ограничения количества параллельных потоков.

Сеть

Пропускная способность сети может послужить ограничивающим фактором при обработке больших сообщений. Если рассмотреть простую клиент-серверную модель, в которой клиент отправляет сообщения-запросы небольшого размера и получает ответы объемом 50 МБ по локальной сети 1 Гбит/с, то теоретически максимальная пропускная способность может быть рассчитана так:

Пропускная способность сети (1000 Мбит/с) /размер сообщения (400 Мбит) = 2,5 сообщения в секунду

Это равняется достижимому времени отклика 400 мс исходя из одного клиентского потока.

На самом деле номинальная скорость передачи данных сетевого адаптера (NIC) на прикладном уровне не достигается из-за передачи служебных данных нижних уровней (TCP/IP и т. д.) Как правило, максимальная пропускная способность составляет 70% от скорости передачи данных NIC.

При обработке сообщений с помощью многоуровневой конфигурации (рисунок 1) сетевая нагрузка на среднем уровне в два раза больше, чем нагрузка на стороне клиента или поставщика услуги — это приводит к уменьшению достигаемой пропускной способности, описанной в приведенном выше сценарии, наполовину.

Рисунок 1. Многоуровневая конфигурация
Multi-tiered configuration

Шаблоны проектирования приложения

В данном разделе приведен ряд шаблонов проектирования, позволяющих увеличить производительность обработки больших сообщений.

Разбивка входящих данных

Технология разбивки входящего сообщения подразумевает разбивку большого сообщения на множество мелких для их отдельной передачи на обработку.

Если большое сообщение представляет собой набор более мелких бизнес-объектов, то решение состоит в том, чтобы сгруппировать более мелкие объекты в объединенные объекты размером менее 1 МБ. Если для отдельных объектов существуют временные зависимости или требование «все или ничего», то решение становится более сложным.

Модель Claim Check

Модель Claim Check подразумевает уменьшение размеров находящихся в оперативной памяти бизнес-объектов, если посреднику необходимы лишь некоторые атрибуты большого сообщения.

  1. Отделить полезную нагрузку от сообщения.
  2. Извлечь необходимые атрибуты в более мелкий «контрольный» бизнес-объект.
  3. Сохранить полезную нагрузку большего объема в хранилище данных и сохранить «квитанцию на получение» (Claim Check) в качестве ссылки в «контрольном» бизнес-объекте.
  4. Обработать более мелкий «контрольный» бизнес-объект, требующий меньшего ресурса памяти.
  5. В момент, когда снова необходима вся полезная нагрузка, выгрузить больший объем нагрузки из хранилища данных с помощью ключа «квитанция на получение».
  6. Удалить больший объем полезной нагрузки из хранилища данных.
  7. Объединить атрибуты в «контрольном» бизнес-объекте с большим наполнением, учитывая измененные атрибуты в «контрольном» бизнес-объекте.

Размещение сервисов

Наиболее важным решением с точки зрения архитектуры является использование отдельной JVM (выделенный сервер) для обработки больших сообщений, особенно при выполнении транзакций по одновременной обработке сообщений небольшого (высокая пропускная способность /низкое время отклика) и большого размера. Данный метод следует применять, если сообщения большого размера приходят нечасто, но характеризуются относительно продолжительным временем отклика.

В системах, обеспечивающих функционирование нескольких сервисов с одновременной обработкой сообщений большого и малого размеров, «сборка мусора» (GC) и непроизводительная загрузка из-за обработки сообщений большего размера могут оказывать отрицательное воздействие на другие сервисы.

Рассмотрим в качестве примера два сервиса:

  • Сервис А — преимущественно обрабатывает сообщения большого размера
  • Сервис B — преимущественно обрабатывает сообщения малого размера (высокая пропускная способность / низкое время отклика)

Разнесение Сервиса А и Сервиса B по различным JVM дает ряд преимуществ:

  • GC и непроизводительная загрузка на обработку сообщений большего размера на стороне Сервиса А не так критично влияют на высокую пропускную способность и низкое время отклика Сервиса B;
  • Каждую из JVM можно оптимизировать для своей ожидаемой рабочей нагрузки.

Настройка производительности

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

Настройка JVM

В данном разделе приведена информация по настройке JVM.

Что такое «сборка мусора»?

Сборка мусора (GC) — это форма управления памятью JVM. Событием-триггером для GC, как правило, является ошибка выделения ресурсов, которая возникает, когда не удается разместить объект в динамической памяти JVM из-за отсутствия свободного места. GC предназначена для очистки динамической памяти JVM от ненужных объектов, обеспечивая таким образом достаточный объем памяти для объекта, которому до этого было отказано в выделении ресурсов. Если GC была запущена, но для объекта все еще недостаточно свободного объема, то, очевидно, динамическая память JVM заполнена полностью.

«Сборка мусора с учетом поколений» (Generational GC) — это методика, которая наилучшим образом подходит для приложений, создающих множество объектов с непродолжительным временем жизни, что типично для промежуточного программного обеспечения. Динамическая память JVM разделена на три части (область размещенных — Allocate Space, область уцелевших — Survivor Space и хранилище — Tenured Space), и хотя это оптимизирует производительность во многих ситуациях, при обработке больших сообщений необходимо знать, как используется динамическая память JVM. Ограничения, накладываемые на объем динамической памяти JVM, могут послужить ограничивающим фактором на 32-разрядных JVM, поэтому настоятельно рекомендуется не применять методику сборки мусора с учетом поколений для обработки сообщений большого размера. Это не относится к 64-разрядным JVM, так как они обеспечивают поддержку увеличенного объема памяти.

Увеличивать ли размер динамической памяти JVM?

Обработка нескольких больших сообщений, особенно при передаче нескольких параллельных потоков, может привести к переполнению динамической памяти JVM. Увеличение размера динамической памяти JVM в большинстве случаев может решить эту проблему, однако следует придерживаться разумного баланса, чтобы побочные эффекты такого изменения не сказались на производительности.

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

При выполнении сборки мусора все другие потоки JVM временно блокируются. Например, если глобальная сборка мусора в вашей системе обычно длится 3 секунды, в то время как по соглашению об уровне обслуживания (SLA) время отклика составляет 1 секунду, во время этой транзакции длительность отклика в 1 секунду будет превышена.

При использовании 32-разрядной JVM (не рекомендуется для обработки крупных объектов) можно максимизировать пространство, доступное для крупных бизнес-объектов, путем выполнения «сборки мусора с учетом поколений». В результате получим «плоскую память», в которой для размещения временных объектов доступно все пространство динамической памяти, а не только область инкубатора (nursery space).

Существует ли альтернативный подход?

Если сервис одновременно обрабатывает несколько больших сообщений, доступный объем динамической памяти JVM может быть быстро заполнен. Ограничение количества потоков Web-контейнера позволяет администратору дополнительно контролировать количество одновременно обрабатываемых сообщений. Это может помочь в решении проблемы исчерпания динамической памяти JVM без необходимости увеличения ее размеров.

Кроме того, в определенный момент времени можно обеспечить обработку одного большого сообщения путем передачи сообщений в WebSphere ESB только одним клиентом — это позволит снизить объем используемой памяти и обеспечить оптимальное время отклика. Последовательное поступление на WebSphere ESB дросселированных входящих клиентских запросов с большими сообщениями может быть обеспечено за счет применения фронтального сервера обработки клиентских запросов, например устройства DataPower.

В разделе «Настройки администрирования» данной статьи приведены параметры и настройки консоли администрирования WebSphere ESB.

Настройки администрирования

В данном разделе приведены соответствующие параметры, условия настройки, рекомендации и информация о работе в Консоли администрирования.

MDB ActivationSpec

Получить доступ к параметрам настройки MDB ActivationSpec можно следующим образом:

Resources > Resource Adapters > J2C Activation Specifications > ActivationSpec Name(Ресурсы > Адаптеры ресурсов > Спецификации активизации J2C > Имя спецификации активизации) Resources > JMS > Activation Specifications > ActivationSpec Name (Ресурсы > JMS > Спецификации активизации > Имя спецификации активизации)

Рисунок 2. Спецификация активизации
Activation Specifications

При обработке больших сообщений следует учитывать два свойства:

Рисунок 3. Параметры спецификации активизации
Activation Specification Properties

maxConcurrency — это свойство отвечает за количество сообщений, которые могут быть одновременно переданы из очереди JMS в потоки MDB.

maxBatchSize — это свойство определяет количество сообщений, которые передаются с уровня сообщений на прикладной уровень за один шаг.

Пулы потоков

Как правило, необходимо настроить перечисленные ниже пулы потоков:

  • Default
  • ORB.thread.pool
  • WebContainer

Максимальный размер этих пулов можно установить в Servers > Application Servers > Server Name > Thread Pools > Thread Pool Name (Серверы > Серверы приложений > Имя сервера > Пулы потоков > Имя пула потоков)

Рисунок 4. Спецификация активизации
Thread Pools

Пул JMS-соединений

Получить доступ к фабрикам соединений JMS (JMS Connection Factories) и фабрикам соединений JMS-очередей (JMS Queue Connection Factories) из Консоли администрирования можно несколькими способами:

Resources > Resource Adapters > J2C Connection Factories > Factory Name (Ресурсы > Адаптеры ресурсов > Фабрики соединений J2C > Имя фабрики)

Resources > JMS > Connection Factories > Factory Name (Ресурсы > JMS > Фабрики соединений > Имя фабрики)

Resources > JMS > Queue Connection Factories > Factory Name (Ресурсы > JMS > Фабрики соединений очередей > Имя фабрики)

Рисунок 5. Фабрики соединений
Connection Factories

Для открытия фабрики соединений из панели администрирования необходимо открыть Additional Properties > Connection Pool Properties (Дополнительные параметры > Параметры пула соединений). Здесь можно установить максимальное количество соединений.

Рисунок 6. Параметры фабрики соединения
Connection Factory Properties

Заключение

Поддержка увеличенного объема памяти, которую обеспечивает 64-разрядная архитектура, несколько уменьшает ограничения на размер динамической памяти Java, который при выполнении операций с крупными объектами данных может стать ограничивающим фактором в 32-разрядной системе.

Увеличение размера динамической памяти JVM в большинстве случаев может решить эту проблему, однако следует придерживаться разумного баланса, чтобы побочные эффекты такого изменения не сказались на производительности.

  • Правильно настройте JVM для обеспечения баланса между интервалами выполнения операций сборки мусора и перерывами между такими операциями.
  • Рассмотрите доступные шаблоны проектирования, позволяющие снизить нагрузки на JVM.
  • Используйте выделенный сервер для обработки больших сообщений.
  • Ограничивайте параллельные или единичные запросы посредством сервера обработки больших сообщений.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=843749
ArticleTitle=Передовые методики и рекомендации по настройке для обработки больших объектов в WebSphere Enterprise Service Bus
publish-date=10312012