Компания IBM
Опубликован: 14.12.2004 | Доступ: свободный | Студентов: 1529 / 139 | Оценка: 4.36 / 3.98 | Длительность: 16:32:00
ISBN: 978-5-9556-0031-4
Специальности: Системный архитектор
Лекция 8:

Дополнительные средства администрирования

< Лекция 7 || Лекция 8: 123 || Лекция 9 >

Вопросы производительности

Кроме выяснения причин ошибок передачи и их устранения, администратор WebSphere MQ должен планировать и рассчитывать схемы передачи данных от одной платформы до другой. Рассмотрим простой пример передачи сообщения, содержащего информацию из строки таблицы из одной базы данных DataBase1 в другую базу DataBase2, расположенную на другой платформе. Интерфейс передачи данных можно разбить на три части (рис. 7.9).

Схема интерфейса передачи данных

Рис. 7.9. Схема интерфейса передачи данных

Первая часть – программа А, помещающая сообщения в исходящую очередь RQ1, вторая – передача сообщений от одного менеджера очередей к другому в очередь назначения Q2, третья – программа B, помещающая сообщения из очереди назначения Q2 в таблицу базы данных.

В данной схеме нужно учитывать, что скорость разбора сообщений из очереди назначения Q2 и помещения их в DataBase2 (участок 3 ) должна быть больше скорости поступления сообщений в эту очередь. Если же сообщения генерируются в исходящую очередь из базы DataBase1 не линейно, то необходимо учитывать характер нелинейности и возможные "узкие" места интерфейса. В любом случае не следует допускать переполнения очередей.

Часто встречаются задачи, в которых требуется при изменении информации в одной системе передать произошедшие изменения в другие системы, причем формат изменяемых данных на разных платформах может иметь различный вид. При этом обработку информации целесообразно сосредоточить в одном месте, так как алгоритмы преобразования данных из DataBase1 в DataBase2, DataBase3 и т.д. очень похожи и имеют много общего, а часто являются подмножествами друг друга. В этом случае мы имеем интерфейс передачи данных с централизованной обработкой сообщений, схема которого показана на рис.7.10.

Схема интерфейса с централизованной обработкой сообщений

Рис. 7.10. Схема интерфейса с централизованной обработкой сообщений

В качестве инструментального средства для центра обработки сообщений рекомендуется Брокер сообщений WebSphere BI Message Broker. Это достаточно эффективный инструмент, являющийся интегрированной средой для визуального проектирования программ обработки сообщений. При проектировании более сложных, разветвленных потоков передачи и распространения информации, которая на пути от источника к приемнику может меняться и дополняться, следует также учитывать производительность всех точек входа и выхода сообщений и соизмерять скорости выгрузки сообщений со скоростью их передачи и обработки.

Приведем еще несколько приемов настройки и тестирования интерфейсов.

Перенаправление потоков

Потребность в этом приеме может возникнуть когда необходимо посылать "пачки" сообщений, например, с QM_AS400 на QM_HPUX. Доступ к запуску приложений на AS400 временно закрыт. Но WebSphere MQ работает. Самое простое решение (рис.7.11) с сервера WindowsNT направляем необходимую "пачку" сообщений на AS400 в локальную удаленную очередь (remote queue), нацеленную на HP_UNIX. Этот же прием может использоваться, если доступ к менеджеру QM_HPUX открыт только с определенного IP адреса.

Перенаправление потоков

Рис. 7.11. Перенаправление потоков

"Вечный двигатель"

Этот прием весьма полезен при тестировании интерфейсов для проверки стабильности и надежности работы программ. Схема "вечного двигателя" изображена на рис. 7.12. В очереди Remote Queue rq1 на сервере WindowsNT в качестве параметра Remote Queue Name указывается rq2, а на сервере HP_UNIX в очереди Remote Queue rq2 соответственно rq1.

"Вечный двигатель"

Рис. 7.12. "Вечный двигатель"

И еще один прием, точнее святая обязанность администратора WebSphere MQ, это документирование интерфейсов. Весьма удобно иметь документированные интерфейсы в графическом виде, и программных средств для этого более чем достаточно (Visio, Bpwin и т.д.). Но по мере сложности интерфейсов их графическое представление становится не наглядным. В этом случае может быть рекомендован Excel, с помощью которого в колонках таблиц прописываются параметры настройки интерфейсов.

По мере возрастания количества интерфейсов, менеджеров и их объектов может возникнуть ситуация, когда администратор WebSphere MQ по названию объекта не сможет определить его сущность. Во избежание этого рекомендуется с самого начала разработать некоторые правила, по которым следует называть все объекты на разных менеджерах. Например, если простые локальные очереди (local queue) будут оканчиваться на .Q, трансмиссионные (transmission queue) на .TQ, локальные удаленные (remote queue) на .RQ, каналы на .CH, процессы на .P и так далее, то по окончанию сразу можно определить тип объекта. То же касается направления передачи и сущности передаваемых сообщений. Например, надо передать курсы валют из системы ABS1 в систему ABS2.

Создаваемые объекты в системе ABS1 можно назвать:

ABS1_ ABS2_CV.RQ – локальная удаленная очередь;

ABS1_ ABS2_CV.TQ – локальная трансмиссионная очередь;

ABS1_ ABS2_CV.CH – канал отправитель.

В системе ABS2:

ABS1_ ABS2_CV.Q – локальная очередь;

ABS1_ ABS2_CV.CH – канал получатель.

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

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

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

Серверное оборудование – чем мощнее сервера, тем быстрее будет работать программное обеспечение.

Размеры баз данных – чем больше база, тем дольше выполняются запросы.

Алгоритмы обработки сообщений – если требуется просто вставить запись в таблицу, то это может быть относительно высокая скорость, а если требуется выполнение операторов SELECT и проверка условий, на основе которых принимается решение о добавлении или изменении записи, то скорость обработки сообщений уменьшается.

Программное обеспечение – корректно написанная программа работает быстрее, к тому же выбор языка программирования играет важную роль. Замечено, что один и тот же алгоритм, реализованный на C и Visual Basic, дает существенно разные результаты. Например, простое перекладывание persistent сообщений размером 1Кб из очереди в очередь на одном и том же менеджере (NT платформа, процессор Pentium IV с тактовой частотой 1.8 ГГц) с помощью программы, написанной на С, дает результат 400 сообщений в секунду, а с помощью программы на Visual Basic только 140.

Тип хранения сообщений в очереди – сообщения persistent обрабатываются медленнее, чем not persistent. Not persistent сообщения из предыдущего примера перекладывались со скоростями 1000 и 200 сообщений в секунду, соответственно.

Наличие механизмов шифрования и сертификации также влияет на скорость обработки сообщений. Так использование SSL механизма может отнять до 10% производительности в зависимости от длины ключа и алгоритма шифрования данных.

< Лекция 7 || Лекция 8: 123 || Лекция 9 >