Apusic MQ75性能测试报告Word格式文档下载.docx

Apusic MQ75性能测试报告Word格式文档下载.docx

《Apusic MQ75性能测试报告Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《Apusic MQ75性能测试报告Word格式文档下载.docx（19页珍藏版）》请在冰豆网上搜索。

5.1.1ApusicMQ7.5配置20

5.1.2ApusicMQ7.0配置21

第1章概述

ApusicMQ7.5是MQ团队在2010年下半年开发的版本，该版本在性能、稳定性以及JMS兼容性上有了明显的改善。

本次主要是针对ApusicMQ7.5的性能进行测试，包括单个MQ服务器的性能，以及两个MQ服务器组成的网络的性能。

此外，还对ApusicMQ7.0进行了对比测试。

由于缺乏MQ的第三方测试工具，本次测试采用自主开发的JMS客户端进行测试。

1.1测试环境

本次测试共使用两台配置相同的服务器：

192.168.6.174（服务器A）、192.168.6.187（服务器B），其详细配置如下：

硬件配置

IBMSystemx3450（高配）（IBMX3650M37945I75）：

IntelXeonX56706C2.93GHz,2*4GBDDR3内存,硬盘1T

网络配置

千兆网络

操作系统

Linux：

2.6.18-164.el5（RedHatEnterpriseLinuxServerrelease5.4）

JDBC数据库

Oracle11.2.0.1

JDK

Java（TM）2RuntimeEnvironment,StandardEdition（build1.5.0_22-b03）

JavaHotSpot（TM）64-BitServerVM（build1.5.0_22-b03,mixedmode）

ApusicMQ7.5启动参数

-server-Xms2048m-Xmx2048m

单服务器测试时，只使用了服务器A，生产者、消费者、JDBC存储和MQ服务器都在服务器A上，示意图如下：

两台MQ组网测试的情况下，服务器A和服务器B上各运行一个MQ服务器，生产者和消费者也分别部署在两台服务器上，示意图如下：

1.2测试参数

本次测试统一设置确认模式为自动确认，采用非事务会话。

测试过程中对各种影响性能的参数进行了组合测试，这些参数及其影响如下：

消息持久性

消息的持久性会影响MQ服务器的磁盘IO策略。

存储类型

在ApusicMQ7.5版本中，消息的存储是可以配置的，但不同的存储类型在可靠性和存储效率上有较大的不同，从而影响MQ服务器的处理效率。

消息大小

消息大小会影响消息的持久化和网络传输效率。

队列个数

队列个数会影响MQ的并发性能，即在一定范围内，队列越多，MQ服务器能够同时处理的消息数就越多。

生产者个数

使用多个生产者主要是为了防止单个生产者生产消息的速度低于MQ服务器的处理速度，从而影响真实的测试结果。

消费者个数

使用多个消费者主要是为了防止单个消费者消费消息的速度低于MQ服务器的处理速度，从而影响真实的测试结果。

组网类型

在ApusicMQ7.5的版本中，新增了一种组网方式：

传输通道组网，相比路由组网，该方式在稳定性上有了较大的提升。

1.3测试结果计算方式

测试结果计算方式如下：

从生产者开始生产第一条消息计时，到消费者消费最后一条停止，再用发送的消息条数（或发送的字节数）除以耗费的时间，得出其吞吐量，单位是条/秒（或M/秒）。

另外，在整个测试过程中对系统的CPU和内存进行了监控，并根据监控数据分析是否会影响测试结果。

第2章ApusicMQ7.5性能

2.1单服务器性能

单服务器测试环境下，消息的存储效率和消息的逻辑处理效率是影响MQ服务器吞吐量的主要因素。

2.1.1队列存储性能

2.1.1.1测试目的

主要是用于测试各种存储类型在ApusicMQ中的存储性能。

2.1.1.2测试方案

ApusicMQ7.5的存储有多种类型可供选择：

BerkeleyDB、DBM、内存存储、JDBC存储，各种存储在性能上和可靠性上有较大的差别。

存储类型的选择不仅会影响到持久消息，也会影响到非持久消息，因为ApusicMQ内部对非持久消息也会做持久化处理（但是和持久消息不同的是，MQ服务器重启后将抛弃这些被持久化的非持久消息）。

本次主要测试以下几种存储：

◆BerkerleyDB（高性能）：

采用BerkerleyDB作为存储，并打开异步读写和缓存机制（具体配置参考附录），使其具有较高的性能（但同时可靠性也较低）。

◆BerkerleyDB（高可靠）：

采用BerkerleyDB作为存储，并关闭异步读写和缓存机制（也就是刷硬盘，具体配置参考附录），使其具有很高的可靠性（但同时性能也较低）。

◆DBM：

采用Apusic自主实现的DBM存储算法。

◆内存存储：

消息全部存在内存里面（实际上就是没有持久），可靠性完全没有保障。

◆JDBC：

可靠性和性能完全依赖于底层的数据库，本次测试以Oracle数据库为例，数据库不做任何优化。

根据以上几种存储，制定本组测试的测试方案如下：

1）只使用一个队列进行测试。

使用多个队列会提升MQ服务器的并发处理能力，由于本组测试只是用来对比各种存储类型的效率，故选择一个队列来使并发性对测试结果的影响降到最低。

2）分别使用1个、2个、4个、8个、12个、16个、20个、24个、28个生产者同时对该队列发送若干条消息，以保证生产者的消息生产速度。

3）由于消费消息的速度比生产消息的速度慢，消费者个数设置为生产者个数的两倍，以保证消费者的消费速度。

4）分别发送大小为1K、100K、1M的消息，测试MQ服务器对不同大小消息的处理情况。

2.1.1.3测试结果分析

根据以上数据，性能从高到底依次是：

内存、berkeleyDB（高性能）、DBM、berkeleyDB（高可靠）、JDBC，其中内存存储在发送较大的消息时很容易导致服务器内存溢出，不能用于生产环境，仅用于测试；

DBM存储不太稳定且有一定的缺陷，也不推荐在生产环境下使用。

BerkerleyDB（高性能）和BerkerleyDB（高可靠）代表了BerkerleyDB的两个极端配置，前者在性能上接近于内存存储，最高时近20000条/秒（消息大小为1K时），可用作非持久消息队列的存储；

后者虽然在性能上降了几个数量级，最高时仅为570条/秒（消息大小为100K时），但每个消息过来都要刷一次硬盘，就算物理服务器断电（且没有独立的硬盘电源）也不会丢失消息，可靠性得到了保障，可用作对可靠性要求非常高的持久消息队列存储；

有些应用场景可能只是希望在MQ服务器进程崩溃或操作系统崩溃都不会丢失消息，而不需要刷硬盘这么高的可靠性，此时可以根据需要对BerkerleyDB进行调整，使其可靠性介于上述两者之间，其性能通常也能达到10000条/秒左右（消息大小为1K时）。

JDBC的存储性能和可靠性完全依赖于底层的数据库产品，目前主流的数据库在可靠性方面都能有很好的保障，故一般将JDBC用作持久消息队列的存储。

在性能方面，本次测试所用的Oracle数据库在存储小消息（1K）时略高于BerkeleyDB（高可靠），但在对大消息的处理上明显低于BerkeleyDB（高可靠）存储。

2.1.2逻辑处理性能

2.1.2.1测试目的

主要用于测试MQ服务器对消息的逻辑处理（比如多线程的并发处理）性能，影响该性能的主要因素有：

生产者个数、消费者个数、队列个数。

2.1.2.2测试方案

由于队列的存储类型和消息大小会对结果造成影响，为了使本组测试更加突出主题，将忽略存储类型及消息大小这些干扰因素。

测试方案制定如下：

1）只选择BerkerleyDB（高性能）进行测试；

2）只选择1K的消息大小进行测试；

3）测试单个队列多个生产者的情况，分别测试1个、2个、4个、8个、12个、16个、20个、24个、28个生产者同发送若干条消息；

4）测试单个生产者多个队列的情况，即每个队列上只挂一个生产者，分别测试1、2、4、8、16个队列的情况；

5）由于消费消息的速度比生产消息的速度慢，消费者个数设置为生产者个数的两倍。

2.1.2.3测试结果分析

从以上结果可以看出，随着生产者个数的增加，服务器的吞吐量逐渐上升，这是因为生产者个数的增加会导致单位时间内发送给服务器的消息增加；

但增到一定程度后吞吐量趋于平稳，甚至稍微呈现下降的趋势，这是因为当达到服务器的处理极限后，生产者个数的增加会加剧服务器对资源的争用。

根据以上数据得知，队列个数的增加会导致服务器的吞吐量上升，这是因为一个队列上挂了一个生产者，队列的增加导致了生产者个数的增加，从而单位时间内生产消息的速度提高了；

但增长到一定程度后，吞吐量趋于平稳，说明已经达到了服务器处理能力的峰值（大约25000条/秒）。

2.2组网性能

2.2.1测试目的

本组测试主要用于测试ApusicMQ7.5在组网环境下对网络的利用率。

2.2.2测试方案

虽然消息存储类型、MQ逻辑处理都会影响测试结果，但为了突出测试目的，将这些因素的影响维持在一个恒定值，本组测试制定的方案如下：

1）将存储类型固定为BerkerleyDB（高性能）；

2）将队列数恒定为1个队列；

3）分别使用1K、100K、1M的消息测试MQ服务器对不同消息大小的处理性能；

4）分别使用1个、2个、4个、8个、12个、16个、20个、24个、28个生产者同时对该队列发送若干条消息，以保证生产者的生产速度；

5）由于消费消息的速度比生产消息的速度慢，消费者个数设置为生产者个数的两倍，以保证消费者的消费速度；

6）分别测试通道组网和路由组网的性能。

2.2.3测试结果分析

从以上数据中可以看出，当消息较小的时候，传输通道比路由有更高的性能，最高吞吐量在14000条/秒左右，这是因为传输通道内部使用了滑动窗口机制，对消息进行批量发送和确认所致。

当然，如果使用多个队列进行测试，传输通道的吞吐量可以达到20000条/秒上。

从以上两组数据中可以得出，当消息较大时，路由连接的吞吐量稍微高于传输通道。

路由连接的最大传输速率最大约为60M/秒，传输通道的最大传输速率约为45M/秒。

第3章ApusicMQ7.0性能

3.1单服务器性能

3.1.1队列存储性能

3.1.1.1测试目的

测试ApusicMQ7.0的存储性能，并和7.5进行对比。

3.1.1.2测试方案

ApusicMQ7.0支持的存储类型有：

DBM、JDBC、BerkerleyDB，其中DBM不推荐在生产环境下使用，在这里不再进行测试，JDBC存储和7.5一样，也不再进行测试。

本组案例主要是针对7.0的BerkerleyDB进行测试，7.0的berkeleyDB用户不能调整参数，服务器内部默认选择了一个可靠性和性能适中的参数配置。

本组测试案例和7.5的队列存储性能测试案例方案类似，采用单队列，然后队列上挂多个生产者和消费者，消费者个数为生产者个数的两倍，并分别测试消息大小1K、100K、1M的情况。

3.1.1.3测试结果分析

从以上数据中可以看出，7.0的berkeleyDB存储性能介于7.5高可靠和高性能之间，最高吞吐量为10000条/秒（消息大小为1K时）。

由于它的可靠性无法和7.5的高可靠配置相比，所以在7.0里面如果想要达到最高可靠的保证，只能用JDBC进行存储。

3.1.2逻辑处理性能

3.1.2.1测试目的

测试ApusicMQ7.0在多个生产者和多个队列的时候的性能表现。

3.1.2.2测试方案

同“ApusicMQ7.5逻辑处理性能测试方案（2.1.2.2节）”，存储采用BerkeleyDB。

3.1.2.3测试结果分析

单队列的情况下，随着生产者个数的增加吞吐量也在增长，当增长到10000条/秒的时候逐渐趋于稳定。

这种情况是每个队列上只挂一个生产者，随着队列的增加，生产者个数也相应增加，故单位时间内发送的消息数也不断增长，当增加到13000条/秒的时候达到峰值，并随着多个队列对资源的争用加剧有略微下降。

相比ApusicMQ7.5的对应测试案例，其吞吐量差距较大（7.5该案例的吞吐量为25000条/秒）。

3.2组网性能

3.2.1测试目的

主要测试ApusicMQ7.0在组网环境下对网络的利用率。

3.2.2测试方案

同“ApusicMQ7.5组网性能测试方案（2.2.2节）”，存储采用BerkeleyDB，只需要测试路由连接组网（7.0只有一种组网方式）。

3.2.3测试结果分析

根据以上测试数据和7.5对应测试案例的数据，可以看出，7.5的路由组网性能比7.0有了较大的提升：

当消息较小时（以1K为例），其吞吐量分别是3900条/秒和3000条/秒，当消息较大时（以100K和1M为例），其网络利用率分别是60M/秒和33M/秒。

第4章总结

根据本次测试，总结如下：

1）ApusicMQ7.5里面可用于生产环境的存储有BerkeleyDB和JDBC，其他存储只能用于测试。

其中BerkeleyDB（高性能）配置可用作非持久消息队列的存储，JDBC和BerkeleyDB（高可靠）配置可用作持久消息队列存储。

2）单服务器环境下，非持久消息（即Berkeley高性能配置）的最大吞吐量能达到25000条/秒；

持久消息（JDBC或BerkeleyDB高可靠配置）在500条/秒左右。

3）组网环境下，非持久的消息的最大吞吐量能达到14000条/秒（单队列的情况下，多队列能达到20000条/秒）；

持久消息由于受限于存储速度，吞吐量约为400条/秒左右。

4）7.5的性能较7.0有了较大的提升，其中单服务器性能提升了约一倍（25000条/秒VS13000条/秒），网络传输性能提升了4倍以上（14000条/秒VS3000条/秒）。

注：

以上数据都以1K的消息大小为例，因为在实际的使用场景中，更多的是一些小消息的传递。

第5章附录

5.1参数配置

5.1.1ApusicMQ7.5配置

1）在测试过程中，服务器A和服务器B上各运行一个MQ服务器（以下称为MQ-A和MQ-B），在MQ-A建立40个本地队列和20个远程队列，MQ-B上建立20个本地队列，每个队列分别用不同的存储来进行测试：

berkeley-store（即高性能配置），berkeley-store4Persistent（即高可靠配置）,DBM,JDBC,Memory。

存储参数配置信息如下（mq_store.xml配置文件）：

<

store-providername="

berkeley-store4Pesistent"

type="

Berkeley"

>

description>

Berkeley-store<

/description>

attributename="

ConfigFileName"

value="

config/je.properties"

/>

CacheSize"

20480"

DefferredWrite"

False"

TxnSupported"

True"

XASupported"

Temporary"

LogFileMax"

10240"

StoreDirectory"

store/persist4Pesistent"

TransactionCommitNoSync"

TransactionCommitWriteNoSync"

CleanBeforeStart"

Lazy"

/store-provider>

berkeley-store"

204800"

store/persist"

default-store-provider"

DBM"

store/jms"

TruncationIntervalMinute"

60"

TruncationSizeMega"

1000"

EnableTruncation"

UseNewDBMVersion"

JDBC数据源的配置（datasources.xml）：

datasourcename="

OracleDB"

jndi-name="

jdbc/oracle"

driver-class="

oracle.jdbc.driver.OracleDriver"

driver-classpath="

lib/ojdbc5_g.jar"

url="

jdbc:

oracle:

thin:

//@192.168.6.174:

1521:

orcl"

min-spare-connections="

5"

max-spare-connections="

30"

idle-timeout="

3000"

propertyname="

user"

mq"

password"

/datasource>

服务器线程设置为1000（mq.conf）：

SERVICECLASS="

com.apusic.util.ThreadPoolService"

NAME="

apusic:

service=ThreadPool,name=MQHandler"

ATTRIBUTENAME="

MaxThreads"

VALUE="

/SERVICE>

其他均使用默认配置即可。

2）单服务器测试队列存储性能时，使用MQ-A的20个本地队列，分别更换不同的队列存储进行测试。

3）单服务器测试逻辑处理性能时，使用MQ-A的40个本地队列，使用berkeley-store存储。

4）组网测试路由服务时使用MQ-A的传输队列和MQ-B的20个本地队列，传输服务使用MQ-A的20个远程队列和MQ-B的20个本地队列，使用berkeley-store存储。

5.1.2ApusicMQ7.0配置

1）服务器A和服务器B上各运行一个MQ服务器（以下称为MQ-A和MQ-B），在MQ-A建立40个本地队列和20个远程队列，MQ-B上建立20个本地队列，均使用berkerley-store。

Berkeley存储配置（mq.conf）：

SERVICE

CLASS="

com.apusic.jms.store.db.DBMessageStoreProvider"

Config"

1048576"

ServicePriority"

L"

服务器线程调为1000（mq.conf）：

service=ThreadPool,name=JMSHandler"

3