目前隨着我們在中國的WebSphere MQ（MQSeries）用戶數量越來越多，越來越多的用戶開始對MQ使用時的性能優化問題提出要求，希望能夠更好地使用我們的產品，並儘可能的發揮它的最大優勢，這裡，我根據日常積累的經驗談一談在MQ性能優化方面應該考慮的因素。
一、 與API 調用有關的MQ性能考慮因素
這裡，我們在討論各個API對性能的影響時，均以C語言提供的API為例，其他開發語言與此類似。
1 關於MQCONN/MQDISC的使用
在MQ的13個函數中，MQCONN/MQDISC是最耗CPU的兩個函數，其次是MQOPEN和MQCLOSE這兩個函數，因此要盡量避免必要地重複使用這幾個函數。比如，當您需要從隊列中讀取多條消息時，正確的編程方法應該如下：
MQCONN
MQOPEN
MQGET
………………..
MQGET
MQCLOSE
MQDISC
即：連接/斷開隊列管理器一次，打開/關閉隊列一次，讀取消息多次。而不應該反覆建立與隊列管理器的連接和反覆進行隊列打開/關閉操作。
2 MQCONNX的使用
通常，我們使用MQCONN這個函數建立與隊列管理器的連接，除此之外，MQ支持trusted application binding，即fastpath binding，用MQCONNX來實現。當從性能方面考慮時，我們可以使用MQCONNX來提高性能。
在使用MQCONNX時，我們可以設置MQCNO(connect option)來指定連接方式。缺省情況下，該選項為MQCNO_STANDARD_BINDING，如果設置為MQCNO_FASTPATH_BINDING，即表明採用fastpath binding方式連接隊列管理器，這種應用稱為trusted application。所謂的trusted application，是指該應用程序和本地隊列管理器代理組成同一個進程，從而提高性能。利用fastpath binding不僅能夠提高連接隊列管理器的性能，同時也能夠提高mqopen,mqclose的性能。
3 消息大小對mqput, mqget函數耗時的影響
盡量減小消息的大小，小消息的讀取效率要高。對於mqget, mqput這兩個函數而言，8k以下的消息的耗時差別不大，8k到128k的消息的耗時隨着消息大小的增加而增加。大於128k的消息耗時較大，因為當與隊列相關的內存滿了的時候，會有硬盤交換。
同時要注意，從傳輸效率而言，如果在廣域網上進行消息傳輸，消息太小會影響傳輸效率，因為對於每一消息，MQ都會有一個消息頭，它會佔有一定的位元組數，如果把消息拆分太小，每個消息的傳輸頭都會佔據一定的開銷。
4 對一個空隊列的open,close 操作比非空隊列的同樣操作耗時要多。
第一次open隊列耗時比接下來的open 耗時要多，對本地隊列和遠程隊列的open,close耗時基本相同。
5 使用MQCMIT對消息進行批處理
當處理一批消息時，可以採用MQCMIT函數，將若干消息作為一個完整的交易來處理，消息將作為一個batch統一提交，而不是一個個地分別提交，因此，可以提高性能。尤其對於永久性的消息效果更加明顯。
6 使用Distribution List 方式來把相同的消息發往不同的目的地
大家知道，MQ適用於不同類型的應用。不僅可以實現”點對點”的通訊，還通過DistributionList支持”多點廣播”應用，即能夠將消息發送到多個目標站點。可以使用一個MQ函數調用將單一消息發送到多個目標站點，並確保為每一站點可靠地提供信息，減少了函數調用的個數。同時，MQ不僅提供了多點廣播的功能，而且還擁有智能消息分發功能，在將一條消息發送到同一系統上的多個用戶或隊列時，MQ可以將消息的一個複製版本和該系統上接收者的名單發送到目標系統。目標系統在本地複製這些消息，並將它們發送到DistributionList上的隊列，從而減少了網絡的傳輸量。
7 當向隊列管理器僅發送一條消息時，使用MQPUT1函數。
在MQ的13個函數中，MQPUT1實現了這樣一種功能，即它合併了MQOPEN, MQPUT, MQCLOSE三個函數的功能，在打開隊列並且只希望發送一條消息時，它的CPU消耗比上述三個函數相加要少。
8 用match correlation ID的方法取消息比不匹配性能要差.
以下文章點擊率最高
Loading…