Некоторые предложения, не относящиеся к настройке доставки сообщений, поскольку, похоже, это не ваше [основное] узкое место:
- Вы упоминали, что храните данные в сильно нормализованной базе данных.Это неизменно означает один или несколько справочных данных или поисков PK, которые создают несколько дополнительных поездок в базу данных для извлечения этих данных.Чтобы избежать или уменьшить это, создайте локальный кеш со всеми вашими справочными данными и обновляйте кеш по мере необходимости.В памяти поиск будет значительно быстрее, чем поездка в БД.
- Если вы чувствуете, что у вас недостаточно ОЗУ для кэширования всех ваших декодировок и справочных данных, используйте дисковый кэш (например, EHCache, который будет выполнять ОЗУ, диск или переполнение) или легкую локальную БД, такую как HyperSonic или H2, котораявсе равно даст вам лучшее время поиска, чем поездка в Oracle (если вы не на том же хосте, и даже тогда ....)
- В конечном счете, если каждое сообщение требует много обращений к БД, выможет принести пользу от переноса обработки сообщения на саму БД, где вы можете реализовать этот процесс на PL / SQL или Java.
- Если ваша запись в базу данных для одного обработанного сообщения включает в себя несколько вставок / обновлений, сделайтеОбязательно используйте подготовленный оператор дозирования.Это отправит несколько вставок / обновлений за один вызов в БД.
- Говоря о подготовленных операторах, убедитесь, что ваша конфигурация JBoss DataSource *1013* для Oracle имеет подготовленный оператор-кэш-размер установлен на некоторое число, достаточно высокое, чтобы обрабатывать все ваши подготовленные операторы, созданные во время обработки (а не значение по умолчанию, равное нулю или без кэширования).
- Анализатор XML, который вы используете, может налагать больше накладных расходов, чемнеобходимо даже (или особенно) для небольших сообщений.Если вы используете JAXB, убедитесь, что вы не воссоздаете демаршаллер более одного раза (или больше, чем необходимо).В качестве альтернативы попробуйте Парсер Pull / Streaming .Если вы используете синтаксический анализатор DOM, необходимая дополнительная память может вызывать много мусора.
- Глупая вещь, но стоит упомянуть, если вы выполняете много регистрации для каждого сообщения, это будет стоитьвремя, поэтому выключите его.
- Использование JBoss MQ в качестве промежуточного буфера элегантно, но, вероятно, это не самый быстрый способ хранения ваших сообщений для отложенной обработки, поскольку постоянство является более сложным и обобщенным для всех видовТипы сообщений JMS.На этом примечании, если JBoss MQ все равно сохраняется в Oracle, то кажется невероятным, что пользовательская процедура сохранения не будет быстрее.Если JBoss MQ сохраняет данные в HyperSonic (как это происходит по умолчанию), вы все равно можете превзойти хранилище сообщений JMS с помощью некоторого пользовательского кода.Это также будет означать, что вам потребуется новый механизм для извлечения сообщения из БД для обработки, но, как и в случае хранилища JMS, пользовательский процесс может превзойти более обобщенную процедуру, реализованную в JBoss MQ.
- Хранение промежуточных сообщений в БД также может дать большую гибкость запроса, чтобы определить, где сообщения не должны обрабатываться последовательно.(Возможно, например, сообщения от разных клиентов не требуют последовательной обработки).Конечно, вы также можете сделать это с помощью JBoss MQ, поместив соответствующие заголовки в промежуточные сообщения.Это позволило бы вам распараллеливать, используя разные селекторы в разных слушателях / обработчиках сообщений.
Один быстрый элемент при обмене сообщениями .....
Вы не упомянули, если вы былииспользование bean-компонентов, управляемых сообщениями, с WebSphere MQ, но если это так, во Inbound Configuration есть настройка, называемая pollingInterval , которая, если цитировать из документов, означает:
Если у каждого прослушивателя сообщений в сеансе нет подходящего сообщения в своей очереди, это максимальный интервал в миллисекундах, который истекает до того, как каждый прослушиватель сообщений попытается снова получить сообщение из своей очереди.Если часто случается, что подходящее сообщение не доступно ни для одного из прослушивателей сообщений в сеансе, рассмотрите возможность увеличения значения этого свойства.Это свойство имеет значение только в том случае, если значение TRANSPORT имеет значение BIND или CLIENT.
Значение по умолчанию pollingTime равно 5000 мс.Ваше текущее время обработки сообщений составляет
(3,5 * 60 * 1000/2000)
= 105 мс на сообщение.
Если вы введете паузу в 5000 мс здесь и там, это серьезно снизит вашу пропускную способность, поэтому вы можете рассмотреть это путем измерения постоянной разницы между временем постановки в очередь сообщения и временем, котороевы получаете сообщение в вашем приемнике сообщений JBoss.Время постановки в очередь может быть определено из следующих заголовков сообщений:
- JMS_IBM_PutDate
- JMS_IBM_PutTime
В общем, ваша лучшая ставка будет иметь значениекак распараллелить.
Удачи.
// Николай