Websphere MQ 应用架构以及性能调优和测试
上一篇 / 下一篇 2012-06-26 23:35:20 / 个人分类：性能测试
WebSphere MQ 做为一种消息中间件，它的应用领域主要在两大方面：
1、我们可以编写相应的处理逻辑，来完成不同应用的集成。甚至我们可以在WebShphere MQ的基础上实现分布式Websphere MQ数据交换网络，从而完成不同用户之间、不同部门之间的文件交换，并且具有断点续传、传输加密、在HTTP协议上传输以穿透防火墙等功能。
2、WebSphere MQ 做为WebSphere Message Broker的底层，WebSphere MQ所能够达到的最大性能对整个WebSphere Message Broker所能够体现的性能至关重要。
WebSphere MQ的性能是企业服务总线、以及总线上的应用所能够达到最大性能的关键，也是现在很多SOA应用所能够达到最大性能的关键。 对于这两大方面的应用，我们需要根据具体的应用架构来对WebSphere MQ进行性能优化。为了对WebSphere MQ进行性能优化唯一的方法就是做好性能测试，从而可以决定更好的架构和更好的参数值来得到更高的系统性能。
Websphere MQ数据交换网络：表示多个Websphere MQ队列管理器进行配置形成一个完整的数据交换环境。
WebSphere MQ 客户端应用：表示与WebSphere MQ进行交互的应用程序。
MQ Client App: WebSphere MQ 客户端应用的英文简称。
消息生产者：表示往Websphere MQ放入消息的WebSphere MQ 客户端应用。
消息消费者：表示从Websphere MQ 取出消息的WebSphere MQ 客户端应用。
Within：表示WebSphere MQ 客户端应用与WebSphere MQ处于同一个操作系统环境中，采用IPC通讯方式。
Across:：表示WebSphere MQ 客户端应用与WebSphere MQ处于同一个操作系统环境中，采用TCP/IP通讯方式。
IPC：进程间通讯，这里的IPC是指同一个操作系统环境中的多个进程采用类似于共享内存的方式来进行通讯。
WebSphere MQ应用架构基本上就是以下几个应用架构地扩展和组合。
图3.1 单个队列管理器应用架构
图3.1所表示Websphere MQ应用架构主要分成以下4种：
- 消息生产者、消息消费者、Websphere MQ分别处于不同的机器。
- 消息生产者、消息消费者、Websphere MQ处于同一机器。
- 消息生产者和Websphere MQ分别处于不同的机器，消息消费者和Websphere MQ处于同一的机器。
- 消息生产者和Websphere MQ处于同一机器，消息消费者和Websphere MQ处于不同的机器。
而在现实的应用场合中，我们需要对这种架构进行扩展，从而可以形成如下图所示的应用架构。
图3.2 多队列管理器应用架构示例
在实际用户场景中，WebSphere MQ 客户端应用与Websphere MQ的通讯方式基本上分成以下两种。
- 通过TCP/IP协议与WebSphere MQ交互 。
- ? 通过IPC方式与WebSphere MQ交互，但是IPC方式只有WebSphere MQ 客户端应用和WebSphere MQ处于同一台机器上才能够使用，并且IPC方式的性能远远高于TCP/IP方式的性能。因为IPC方式的高性能，我们在很多实际用户场景中都会修改相应地架构，形成一个新的架构（例子如下图所示）。
图3.3 改进的配置示例
对于图3.3 改进的配置示例所示的架构，我们进行了这样的改变，即把图的上半部分所表示的架构改变成下半部分所表示的架构，这样的架构改变会带来一个好处就是部署在WAS上的JMS/MQ应用往WebSphere MQ放入消息或者取消息的效率将得到大大地提高，从而提高了WAS上的JMS/MQ应用的执行效率
无论Websphere MQ应用架构如何变化，要使整个系统达到一个很好的性能，如何进行性能测试和如何调整WebSphere MQ参数的方法都是一样的。为了更好地阐述相应的方法，我们将以图3.1 单个队列管理器应用架构所示的架构为例。
为了使Websphere MQ发挥最大的性能（假设我们已经对WebSphere MQ 客户端应用进行了Websphere MQ调用编码级别的性能优化考虑），我们需要考虑以下对Websphere MQ产生重大性能影响的几个方面。
- 消息大小会对WebSphere MQ的性能产生较大的影响；所以在现实的应用场合中建议用户采用的消息大小最好为：1K、2K、4K、8K、16K、32K。如果你的消息过大的话，请采用MQ提供的消息分组、消息分段机制来对大消息进行拆分。不要把过大的消息（如5M、10M的消息）不通过相应地消息分组或者消息分段机制进行拆分就直接到打入WebSphere MQ的队列中，这样将会导致WebSphere MQ提供的一些和性能密切相关的参数无法发挥出它所具有的作用，从而不能充份发挥WebSphere MQ的性能。
- 消息生产者、消息消费者、Websphere MQ处于同一机器。
- WebSphere MQ对消息的缓冲能力，WebSphere MQ提供了这样的一个功能，就是WebSphere MQ能够在内存中开辟一个缓冲区来缓冲队列中存储的数据。我们需要根据消息的大小、在高峰期的时候WebSphere MQ队列中会保存的消息的数目、机器的内存大小这几个因素来决定WebSphere MQ的缓冲区的大小。如果我们能够通过测试得出一个合适的值，将使系统大大地减少I/O；从而即使在没有高速存储设备的情况下，Websphere MQ也能够发挥出一个较好的性能。
- I/O分布地考虑，对于Websphere MQ来说在队列中保存的非持久化消息，如果Websphere MQ无法在内存中缓存的话，这些消息将会被写到磁盘存储中；持久化消息将被定期地从内存写到磁盘存储中（机制类似于数据库的CHECKPOINT机制）。WebSphere MQ具有相应的日志能力来保障持久化消息在异常情况下(如系统掉电、Websphere MQ异常终止)不会丢失。在现实的场合中，我们必须把Websphere MQ的日志存储路径单独的放到一个高速存储设备上，并且在条件允许的情况下把Webpshere MQ的队列存储路径（对应于队列管理器目录下的queue目录）也单独放到一个高速存储设备上。通过这些措施，将提高Websphere MQ的性能。
- Websphere MQ客户端应用与WebSphere MQ通讯方式地选定，我们需要在TCP/IP、IPC这两种通讯方式中选择一种。特别是在机器硬件条件允许的情况下，我们建议采用IPC方式通讯，这样将提高我们整个系统的处理效率。
现在让我们想像下我们的应用场景，在整个系统运行时，会存在多个消息生产者和消息消费者与Websphere MQ进行交互，并且这些消息生产者和消息消费者会操作不同的队列或者同一个队列。通过这样地分析我们可以得到以下的用例需要进行测试（假设消息大小为1K），并且我们需要根据现实的情况来决定消息生产者和消息消费者的数目、队列的数目以及决定是否需要把相应的用例进行组合来进行测试。
要测试的用例表格如下所示：
图 4.1 性能测试用例
上述的表格我们确定了三大类用例：
- One To Many:一个消息生产者和多个消息消费者，这个用例描述了这样的应用场合，一个消息生产者把一个消息同时打往多个队列（这个可以利用Websphere MQ的分发列表机制实现），以供分别监听不同队列的消息消费者进行消费，完成相应的业务逻辑。
- Many to Many(Multi Queue):多个消息生产者和多个消息消费者，消息生产者和消息消费者是一对一的关系，但是不同消息生产者或者消费者操作的队列是不同的。
- Many to Many: 多个消息生产者和多个消息消费者，消息生产者和消息消费者是一对一的关系，但是不同消息生产者或者消费者操作的队列是相同的。
我们可以把这三大类用例进行组合一起进行测试，从而可以模拟出真实的复杂环境。通过上面的测试用例表格，我们需要在Websphere MQ中建立20个队列（假设Websphere MQ安装在AIX环境上）。
有了测试用例，我们需要测试程序。我们如何形成测试程序来模拟真实的环境呢？我们可以利用MQ提供的ih03这个supportpac程序来进行模拟，根据测试结果来决定Websphere MQ的参数调整和架构的确定。这里所阐述的方法和步骤在实际的场景中可以完全采用。由于ih03提供的测试程序的限制无法进行长时间的压力测试，所以决定了我们这篇文章是在阐述一个可借鉴的性能测试方法而不是一个具体的步骤。
我们准备2台机器，一台机器做为测试客户机(2CPU)，一台机器做为测试服务器(4CPU)。测试服务器和客户机安装AIX操作系统、gcc编译器、ih03程序。客户机上的ih03程序通过TCP/IP的方式连接测试服务器上的Websphere MQ 队列管理器，测试服务器上的ih03程序通过IPC方式连接MQ队列管理器。在这里测试环境不采用高速存储设备，直接利用本机提供的磁盘。
图 5.1测试的架构
注：左边的是测试服务器，右边的是测试客户机。
为了部署这样的架构我们需要做如下几个方面的工作：
1、在测试服务器上安装Websphere MQ V6.0 Server，并且打补丁打到V6.0.2.1。
2、在测试客户机上安装WebSphere MQ V6.0 Client,打补丁到V6.0.2.1
3、在测试客户机上用gcc编译相应地源代码，源代码见：src.rar
3.1．编辑相应地Makefile文件，文件内容见：Makefile.server
3.2．建立server目录，调用make all将在server目录生成可执行文件。
4、在测试服务器上用gcc编译相应地源代码,源代码见：src.rar
4.1．编辑相应地Makefile文件，文件内容见：Makefile.client
4.2．建立client目录，调用make all将在client目录生成可执行文件。
5、在测试服务器上调用crtmqm 命令建立相应地队列管理器QM1,注意把MQ日志的路径指向单独的一个磁盘设备上。
创建队列管理器的时候，注意扩大日志文件的大小和数目（这个大小和数目和你要持久化的消息的数目以及消息大小的乘积的值密切相关，不同的应用场景的值是不一样的）
命令格式如下：
crtmqm -lf <LogFilePages> -lp <LogPrimaryFiles> -ls <LogSecondaryFiles>
我们最好把LogFilePages这个值设值为16384,即每个日志文件的大小为64MB。
并且还有一个非常中要的参数就是qm.ini中的LogBufferPages参数，它代表日志缓冲区的大小，修改这个值能大幅提高性能。通过增大这个值，对存储持久化消息来说可以减少磁盘的I/O数目，从而间接提高放入持久化消息的速度。最好把这个值设置为4096。
6、用WebSphere MQ相应地命令在队列管理器上建立好相应地队列、侦听器(TEST.LISTEN(1414))、服务器连接通道(SYSTEM.ADMIN.SVRCONN).
在开始测试前，我们需要调整和Websphere MQ性能比较关键的几个参数值。
将通道和侦听程序设置为trusted方式，通过修改qm.ini配置文件中MQIBindType参数，创建或修改qm.ini文件中与Channels相关的小节
Channels:
MQIBindType=FASTPATH
- WebSphere MQ消息内存缓存参数调整，这个需要分成两个部分来进行阐述.
- 非持久性消息对应的内存缓存：在WebSphere MQ中存在DefaultQBufferSize这样一个参数，这个参数表示对Websphere MQ中的每个队列分配多少内存缓存，缺省值是比较小的，如果我们采用缺省值就会导致缓存里只会缓存少量的非持久化消息，这样大量的非持久化消息就会被写到磁盘当中，这将大大降低性能。我们都知道对于非持久化消息是没有必要写入到磁盘中的，我们最好的结果就是非持久化消息最好全部能够在内存中缓存中这样就不会存在I/O。但是这个DefaultQBufferSize值的大小不是越大越好，这个是由系统空闲内、在MQ中会保留多少条消息的数目和消息大小的乘积的值决定。无论如何我们再测试还没有开始地时候都需要调整这个值，然后根据你测试的结果以及得到的一些监控信息来最终决定这个值的大小。我们起初把它设置成为128M.
- 持久性消息对应的内存缓存：对于持久性消息来说都必须写磁盘，如果设置DefaultPQBufferSize这个值也会对性能产生一定的影响，我们不能够使用缺省值，建议这个值最好和LogBufferPages*4k 这个值进行匹配或者是整数倍。我们起初把它设置成为16M.
操作系统通信内核参数的调整
这里主要涉及两个参数的调整，一个是sendbuffersize，一个是recvbuffersize，这个参数最好设置在4k-16k之间，这个值主要和你的网络带宽相关需要在客户机和服务器都修改，最好两边的值都是一样。并且这个值的选取最好由你所产生的消息大小来确定，如应用系统中大部分消息的大小都是4K-16K之间的话，那我们最好设定这个值的大小为8K。
并且在跨广域网的多个队列管理器之间互连通信的时候我们最好把WebSphere MQ 的keepalive 的值设为TRUE,并且修改操作系统通信内核参数（SOCKET超时时间）的值。
- 如果对WebSphere MQ并发压力比较大的话，请调整MaxChannels和 MaxActiveChannels属性值
各个操作系统都提供了对系统资源消耗的监控工具，如vmstat 、topas等。然后我们需要有这样一个工具，它能够监控系统的资源消耗情况并形成一个数据文件，然后这个工具提供一个分析工具把这些数据文件转换成一些图表和报表，这样我们可以通过分析这些图表和报表来查看系统资源（如内存、CPU、网络带宽、I/O情况）情况，来进一步确定需要调整哪些WebSphere MQ参数，以进一步提升WebSphere MQ的性能。
对于这样的工具，我们建议使用nmon。nmon能够监控系统资源的使用情况并形成一个数据文件。它还提供了一个分析工具，从而我们可以把这些数据文件转换成EXCEL表格，让我们非常方便地分析系统资源消耗的情况。这个分析工具产生的分析结果给我们进行操作系统参数的调整和Websphere MQ参数的调整提供了一个很好的参考数据。
此工具的参考资料和下载信息请见：
1、nmon performance: A free tool to analyze AIX and Linux performance
2、nmon analyser : A free tool to produce AIX performance reports
按照说明分别在测试客户机和服务器上安装nmon.
我们从上面测试用例表格中选取一个测试用例来阐述测试的步骤，这样的步骤在任何场景以及真实的应用场景中的性能测试中都是类似的。
我们选取Many to Many、消息生产者和消息消费者的数目都是20、建立的队列数目是20、消息生产者和消息消费者在测试客户机这个用例来演示我们如何进行性能测试和分析来决定参数调整。
1、在放有可执行程序的目录，建立manytomany2目录，把相应地mqtimes2、mqput2程序放入此目录。
2、我们打算每个生产者将产生7W条持久性消息，每个消息大小为2K。
mqtimes2:对应的就是消息消费者
mqput2:对应的是消息生产者。
2.1、制做一个消息文件大小为2k 的文件：msg2.data。
2.2、制做mqput2这个消息生产者所需要的参数定义文件:parmtst1.txt，并且修改parmtst1.txt文件中qmgr的值为合适的队列管理器名称如QM1,msgcount的值为70000 persist的值为1（代表为持久化消息），msgtype的值为8（代表为数据报消息），encoding的值为273（代表为AIX integers），codepage的值为437（代表为ascii）, filelist的值为msg2.data（代表打入的消息为msg2.data文件对应的数据）。
3、编写startTest.sh脚本，从而可以同时把mqtimes2和mqput2这两个应用启动起来，脚本的内容：
echo "The usage: startTest.sh [testclientnumber MsgCount]"
echo $1
i=$1
echo $i
while [ $i -ne 0 ]
do
./mqput2 -f parmtst1.txt -q Q$i> MQPut2log$i.txt &
./mqtimes2 -c $2 -q Q$i -t 30 -m QM1 -s 4096 -b 120> MQTimeslog$i.txt &
i=`expr $i - 1`
done
4、在测试客户机端(mqm用户)，运行：
export MQSERVER=SYSTEM.ADMIN.SVRCONN/TCP/’200.31.11.146(1414)’
export MQCCSID=819
表示要连接哪台机器上的Websphere MQ.
5、 在测试服务器端，起动nmon工具，
./nmon –fT –s 3 –c 150
这个命令将在当前路径产生一个后缀名为nmon的存储监控信息的数据文件，以被事后分析。
6、在测试客户机端，启动测试
./startTest.sh 20 70000
这个脚本代表将起动20个消息生产者（mqput2）进程和20个消息消费者(mqtimes2)进程，不同的消息生产者进程操作不同的队列。
7、等待测试结束，把测试客户机上的消息生产者（mqput2）进程和消息消费（mqtimes2）进程产生的结果文件(MQTimeslog和MQPut2log文件)，下载到本机。
7.1、通过查看MQPut2log文件我们可以知道花费了多少时间完成消息的打入，以及成功打入了多少条消息
7.2、通过查看MQTimesLog文件我们可以知道花费了多少时间完成消息的取出，以及平均每秒消费了多少条消息，以及各个时刻对应的每秒消费了多少条消息。通过这个我们可以得到WebSphere MQ的消息吞吐率。
8、把测试服务器上的nmon工具产生的存储监控信息的数据文件下载到本机
9、用nmon工具提供的analyser工具（它是一个xls文件，里面嵌有宏），打开刚刚下载下来的nmon工具产生的监控信息数据文件，进行转换成xls文件
我们打开转换后的xls文件，通过查看其中的图表和相应的数据可以决定出相应地系统资源的消耗，从而可以决定是否可以继续调整Websphere MQ的参数。
图7.1 CPU和I/O 使用率
从上图可以看出CPU的使用率非常的平稳，只有40%的CPU被利用到，通过这样的情况，我们马上可以判断出我们可以再增加1倍的并发压力，并且DISK的I/O有点抖动，并且这个可以判断出这个是由于取消息的时候从硬盘中取并且取走后需要删除相应的消息所导致，这样就可以给我们一个假设判断是否可以修改DefaultPQBufferSize这个值来降低这种抖动？于是我们马上查看内存使用情况：
图7.2 内存使用率
从这个图可以看出空闲内存非常的平稳并且内存还足够，所以我们就会去提高DefaultPQBufferSize这个参数的值，并且增大并发压力来决定我们这个机器能够承受多少压力。
图7.3 网络利用率
查看这个图可以看到，对于100M以太网来说，网络的带宽利用率并不高。通过上面的判断可以增加并发数，修改WebSphere MQ参数来进行进一步的测试。
上面的阐述仅仅说明了一种思路、一种方法，具体的应用的实施可以借助它来进一步的完善以形成自己的思路和方法，从而给传统的消息中间件应用以及SOA应用的性能最大化打下一个良好的基础
1、nmon performance: A free tool to analyze AIX and Linux performance
2、nmon analyser : A free tool to produce AIX performance reports
3、IH03: WebSphere Message Broker V6-Message display, test &performance utilities
4、MP6K: WebSphere MQ for AIX V6.0 - Performance Evaluations
TAG:
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
我的存档
数据统计
- 访问量: 89240
- 日志数: 117
- 建立时间: 2007-04-01
- 更新时间: 2012-07-20
