Производительность WebSphere MQ - PullRequest
3 голосов
/ 01 февраля 2012

У меня на компьютере 1 работает MQ server 7.1.У меня есть приложение Java, работающее на компьютере 2, которое использует JMS для записи сообщений в очередь на компьютере 1. Приложение Java обрабатывает сотни сообщений в секунду (данные поступают из другого места).В настоящее время для записи сообщений в очередь требуется около 100 мс для 200 текстовых сообщений (средний размер 600 байт) или 2000 сообщений в секунду.Это разумная производительность.Каковы некоторые из вещей, которые можно сделать, чтобы улучшить производительность дальше.то есть быстрее?

Ответы [ 2 ]

8 голосов
/ 01 февраля 2012

В WebSphere MQ Performance Reports имеется ряд подробных рекомендаций.Они опубликованы как SupportPacs.Если вы начнете с целевой страницы SupportPac , все нужные вам файлы называются MPxx и доступны для каждой платформы и для каждой версии.

Как вы увидите из SupportPacs, WMQ выходиткоробки настроены на баланс скорости и надежности в широком диапазоне размеров и типов сообщений.Существует значительная свобода для настройки через конфигурацию и через дизайн / архитектуру.

С точки зрения конфигурации, существуют буферы для постоянных и непостоянных сообщений, возможность уменьшить целостность записи на диск с тройной записи на одноразовую.запись, настройка размеров и номеров файлов журналов, мультиплексирование соединений и т. д. и т. д. Из этого можно сделать вывод, что чем больше QMgr настроен на конкретные характеристики трафика, тем быстрее вы сможете его использовать.Обратная сторона этого заключается в том, что настроенный QMgr будет иметь тенденцию плохо реагировать, если обнаружится трафик нового типа, выходящий за рамки спецификаций настройки.отдельные шпиндели.Когда постоянное сообщение записывается, оно отправляется как в очередь файлов, так и в файлы журнала.Если обе эти файловые системы конкурируют за одинаковые головки чтения / записи на диске, это может привести к снижению производительности.Вот почему WMQ может иногда работать медленнее на высокопроизводительном ноутбуке, чем на виртуальной машине или сервере примерно того же размера.Если на ноутбуке есть физический вращающийся диск, на котором обе файловые системы WMQ выделены, а на сервере есть SAN, то никакого сравнения нет.

С точки зрения дизайна, большая производительность может быть получена за счет параллелизма.Отчеты о производительности показывают, что добавление большего количества клиентских подключений значительно повышает производительность, вплоть до того, что оно затем выравнивается и в конечном итоге начинает снижаться.К счастью, наибольшее количество клиентов до того, как оно отвалилось, ОЧЕНЬ велико, и сервер веб-приложений обычно останавливается до того, как это делает WMQ, только из-за необходимого количества потоков Java.интервал фиксации.Если приложение таково, что за один раз можно отправлять или получать много сообщений, это повышает производительность.Постоянное сообщение в syncpoint не нужно сбрасывать на диск до тех пор, пока не произойдет COMMIT.Написание нескольких сообщений за одну единицу работы позволяет WMQ быстрее возвращать управление программе, буферизировать записи и оптимизировать их гораздо эффективнее, чем писать по одному сообщению за раз.

В статье «Мыши и слоны» содержится дополнительное углубленное обсуждение параметров настройки.Он является частью серии developerWorks Mission: Messaging , в которой содержатся некоторые другие статьи, которые также касаются настройки.

1 голос
/ 13 января 2014
...