Apusic MQ性能测试报告.docx

Apusic
金蝶中间件有限公司
2011年6月30日
目录
目录 2
第1章 概述 4
测试环境 4
测试参数 5
测试结果计算方式 6
第2章 APUSIC 化的非持久消息）。
本次主要测试以下几种存储：
BerkerleyDB(高性能)：采用BerkerleyDB作为存储，并打开异步读写和缓存机制（具体配置参考附录），使其具有较高的性能（但同时可靠性也较低）。
BerkerleyDB(高可靠)：采用BerkerleyDB作为存储，并关闭异步读写和缓存机制（也就是刷硬盘，具体配置参考附录），使其具有很高的可靠性（但同时性能也较低）。
DBM：采用Apusic自主实现的DBM存储算法。
内存存储：消息全部存在内存里面（实际上就是没有持久），可靠性完全没有保障。
JDBC：可靠性和性能完全依赖于底层的数据库，本次测试以Oracle数据库为例，数据库不做任何优化。
根据以上几种存储，制定本组测试的测试方案如下：
只使用一个队列进行测试。使用多个队列会提升MQ服务器的并发处理能力，由于本组测试只是用来对比各种存储类型的效率，故选择一个队列来使并发性对测试结果的影响降到最低。
分别使用1个、2个、4个、8个、12个、16个、20个、24个、28个生产者同时对该队列发送若干条消息，以保证生产者的消息生产速度。
由于消费消息的速度比生产消息的速度慢，消费者个数设置为生产者个数的两倍，以保证消费者的消费速度。
分别发送大小为1K、100K、1M的消息，测试MQ服务器对不同大小消息的处理情况。
测试结果分析
根据以上数据，性能从高到底依次是：内存、berkeleyDB(高性能)、DBM、berkeleyDB（高可靠）、JDBC，其中内存存储在发送较大的消息时很容易导致服务器内存溢出，不能用于生产环境，仅用于测试；DBM存储不太稳定且有一定的缺陷，也不推荐在生产环境下使用。
BerkerleyDB(高性能)和BerkerleyDB(高可靠)代表了BerkerleyDB的两个极端配置，前者在性能上接近于内存存储，最高时近20000条/秒（消息大小为1K时），可用作非持久消息队列的存储；后者虽然在性能上降了几个数量级，最高时仅为570条/秒（消息大小为100K时），但每个消息过来都要刷一次硬盘，就算物理服务器断电（且没有独立的硬盘电源）也不会丢失消息，可靠性得到了保障，可用作对可靠性要求非常高的持久消息队列存储；有些应用场景可能只是希望在MQ服务器进程崩溃或操作系统崩溃都不会丢失消息，而不需要刷硬盘这么高的可靠性，此时可以根据需要对BerkerleyDB进行调整，使其可靠性介于上述两者之间，其性能通常也能达到10000条/秒左右(消息大小为1K时)。
JDBC的存储性能和可靠性完全依赖于底层的数据库产品，目前主流的数据库在可靠性方面都能有很好的保障，故一般将JDBC用作持久消息队列的存储。在性能方面，本次测试所用的Oracle数据库在存储小消息（1K）时略高于BerkeleyDB（高可靠），但在对大消息的处理上明显低于BerkeleyDB（高可靠）存储。
逻辑处理性能
测试目的
主要用于测试MQ服务器对消息的逻辑处理（比如多线程的并发处理）性能，影响该性能的主要因素有：生产者个数、消费者个数、队列个数。
测试方案
由于队列的存储类型和消息大小会对结果造成影响，为了使本组测试更加突出主题，将忽略存储类型
及消息大小这些干扰因素。测试方案制定如下：
只选择BerkerleyDB(高性能)进行测试；
只选择1K的消息大小进行测试；
测试单个队列多个生产者的情况，分别测试1个、2个、4个、8个、12个、16个、20个、24个、28个生产者同发送若干条消息；
测试单个生产者多个队列的情况，即每个队列上只挂一个生产者，分别测试1、2、4、8、16个队列的情况；
由于消费消息的速度比生产消息的速度慢，消费者个数设置为生产者个数的两倍。
测试结果分析
从以上结果可以看出，随着生产者个数的增加，服务器的吞吐量逐渐上升，这是因为生产者个数的增加会导致单位时间内发送给服务器的消息增加；但增到一定程度后吞吐量趋于平稳，甚至稍微呈现下降的趋势，这是因为当达到服务器的处理极限后，生产者个数的增加会加剧服务器对资源的争用。
根据以上数据得知，队列个数的增加会导致服务器的吞吐量上升，这是因为一个队列上挂了一个生产者，队列的增加导致了生产者个数的增加，从而单位时间内生产消息的速度提高了；但增长到一定程度后，吞吐量趋于平稳，说明已经达到了服务器处理能力的峰值（大约25000条/秒）。
组网性能
测试目的
本组测试主要用于测