-
关于ActiveMQ 消息吞吐量的如何优化?5
最近公司想对公司应用结构进行优化,对现在架构中很多耗费资源严重且耗时比较长的应用间大数据量同步通信的接口进行优化,讨论决定引入消息中间件,网上浏览了一圈最后锁定ActiveMQ,在网上看到很多关于ActiveMQ的测试分析文档,大部分测试结果 AMQ的每秒吞吐量大概都在2000以上甚至更多,但是我在公司服务器上面测试的数据并不是很理想,有点让人头疼,不能够达到峰值,甚至在多线程下速度极速下降,效率方面有点不能让人接受,想看看有没有更好的优化配置。
下面是我的Amq的配置:
[size=large;]
单机服务器:CPU :8个
内存:16G
系统:Linux Red Hat
Amq版本:5.5.1
[/size]
${activemq_base}/conf/activemq.xml :配置
[color=blue]<broker xmlns="http://activemq.apache.org/schema/core" brokerName="pure_master" destroyApplicationContextOnStop="true" persistent="true" useJmx="true"> <destinationPolicy> <policyMap> <policyEntries> <policyEntry topic=">" producerFlowControl="false" memoryLimit="16mb" optimizedDispatch="true"> <dispatchPolicy> <strictOrderDispatchPolicy /> </dispatchPolicy> <subscriptionRecoveryPolicy> <lastImageSubscriptionRecoveryPolicy /> </subscriptionRecoveryPolicy> </policyEntry> <policyEntry queue=">" producerFlowControl="false" memoryLimit="16mb" optimizedDispatch="true"> </policyEntry> </policyEntries> </policyMap> </destinationPolicy> <managementContext> <managementContext createConnector="false"/> </managementContext> <persistenceAdapter> <kahaDB directory="/opt/activemq_data/kahadb_master" indexWriteBatchSize="1000" journalMaxFileLength="32mb" enableIndexWriteAsync="true" enableJournalDiskSyncs="false"/> </persistenceAdapter> <systemUsage> <systemUsage sendFailIfNoSpaceAfterTimeout="3000"> <memoryUsage> <memoryUsage limit="128 mb"/> </memoryUsage> <storeUsage> <storeUsage limit="15 gb" name="dbstore"/> </storeUsage> <tempUsage> <tempUsage limit="128 mb"/> </tempUsage> </systemUsage> </systemUsage> <transportConnectors> <transportConnector name="openwire" uri="tcp://192.168.2.215:61616"/> </transportConnectors> </broker> <import resource="jetty.xml"/>[/color]
JVM设置:
[color=black] /opt/java/jdk1.6.0_29/bin/java -server -Xmx2g -Xms2g -XX:SurvivorRatio=8 -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:ErrorFile=/opt/mqdata/logfile/dump.log -XX:+UseParNewGC -XX:MaxTenuringThreshold=1 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=192.168.2.215 -Dorg.apache.activemq.UseDedicatedTaskRunner=true -Djava.util.logging.config.file=logging.properties -Dcom.sun.management.jmxremote -Dactivemq.classpath=/opt/work/activemq/conf; -Dactivemq.home=/opt/work/activemq -Dactivemq.base=/opt/work/activemq -jar /opt/work/activemq/bin/run.jar start[/color]
单机模式下测试流程:
只对queue进行测试,
1、broker和producer、consumer 都是分离开得 ,一台服务器专门做broker的主机服务器。
2、使用activemq在example下提供的例子在另一台服务器(8核,16G)进行消息生产
3、1个producer 没有consumer 的情况下,消息大小:1K,非持久化消息,每秒大概在2500左右,1000W以后大概每秒1500/s左右
4、1个peoducer 没有consumer,消息大小:1K,持久化消息(kaha),每秒 1200-1500左右,内存到1G左右时,缩减到800-1000左右/s
5、1个producer,1个consumer,消息大小:1K,持久化消息(kaha),每秒1200左右,持续稳定在这个状况
6、5个producer,5个consumer,消息大小:1K,持久化消息(kaha)、每秒在1000左右/s 持续
7、p:1,c:1, 消息大小:1024K,持久化消息,每秒在700-900/s
8、p:5,c:5,消息大小:1024,持久化消息,每秒大概在700左右/s
[size=small;]二、:Pure Master-Slave 模式[/size]
配置:
硬件配置:主从都一样,8 CPU,16G内存
Master 配置与单机模式一样
Slave 只是在<broker> 中增加了masterConnectorURI="tcp://192.168.2.215:61616" shutdownOnMasterFailure="false"
ActiveMQ 内存分配为2G
只对queue进行测试,
1、1个producer 没有consumer 的情况下,消息大小:1K,持久化消息,每秒大概在1000左右,内存过半(1G)时,大概在500-700左右
2、1个producer,1个consumer,消息大小:1K,持久化消息(kaha),每秒800-1000左右,持续稳定在这个状况
3、5个producer,5个consumer,消息大小:1K,持久化消息(kaha)、每秒在500-800左右/s 持续
4、p:1,c:1, 消息大小:1024K,持久化消息,每秒在700左右/s
5、p:5,c:5,消息大小:1024,持久化消息,每秒大概在500左右/s
这是我现在的测试结果.
但是这个结果让我不是很满意,想问问大家在配置ActiveMQ 的时候 我是否有配置有耗时的地方,还可以在那些方面进行优化。
公司的方案倾向于Pure Master-Slave模式但是这种模式有 双向存储的性能消耗,也想问问大家在应用方面那种模式更好一些,初步预算在生产环境为两个服务器。
希望大家能帮忙解决下问题 ,谢谢啊
问题补充:283433775 写道1. 你的调用程序是你自己写的吗?确认瓶颈不是出在程序上,你是用自带的example跑起来的吗?
2. 其实ActiveMQ在网上很多人使用时都说了,并不是很好,肯定这方面多多少少有缺陷。
其实RabbitMQ是Erlang推出的,并且是工业标准,我更建议用这个。
调试程序用的是Activemq 自带的example 测试的,因为在验证阶段么?还没有去使用框架或者开发调试程序。
公司内部使用的系统来架设MQ服务器,想说如果像我上面测试中的吞吐量结果,在大约3K人左右使用的内部系统中,是否能够满足并发处理的需求?
还有正常来说MQ服务器,比如说RabbitMQ 或者openMQ等正常的吞吐量大概维持在多少,请问下有测试过,或者您工作中理想的峰值、平均值是多少?
谢谢
问题补充:283433775 写道引用
公司内部使用的系统来架设MQ服务器,想说如果像我上面测试中的吞吐量结果,在大约3K人左右使用的内部系统中,是否能够满足并发处理的需求?
还有正常来说MQ服务器,比如说RabbitMQ 或者openMQ等正常的吞吐量大概维持在多少,请问下有测试过,或者您工作中理想的峰值、平均值是多少?
抱歉,其实我们也只是刚才调研没多久,只是了解了一下几个MQ之间,并且怎么使用,真正的性能测试,暂时还没有做呢,所以不能提供给你具体信息了,我对他们具体的效率问题还不是太清楚。你还是上网上找一找把。
恩,好滴,十分谢谢啊。
公司环境不是十分好,需要再慢慢测试啦?
一点点来吧?希望元旦前能有个好的测试结果!!
谢谢啦
2011年11月25日 16:06
2个答案 按时间排序 按投票排序
-
采纳的答案
引用
公司内部使用的系统来架设MQ服务器,想说如果像我上面测试中的吞吐量结果,在大约3K人左右使用的内部系统中,是否能够满足并发处理的需求?
还有正常来说MQ服务器,比如说RabbitMQ 或者openMQ等正常的吞吐量大概维持在多少,请问下有测试过,或者您工作中理想的峰值、平均值是多少?
抱歉,其实我们也只是刚才调研没多久,只是了解了一下几个MQ之间,并且怎么使用,真正的性能测试,暂时还没有做呢,所以不能提供给你具体信息了,我对他们具体的效率问题还不是太清楚。你还是上网上找一找把。2011年11月28日 10:52
-
1. 你的调用程序是你自己写的吗?确认瓶颈不是出在程序上,你是用自带的example跑起来的吗?
2. 其实ActiveMQ在网上很多人使用时都说了,并不是很好,肯定这方面多多少少有缺陷。
其实RabbitMQ是Erlang推出的,并且是工业标准,我更建议用这个。2011年11月26日 16:02
相关推荐
无论是通过连接池管理资源、调整预取策略来实现消息的均衡分配,还是通过垂直扩展和水平扩展来提高系统的整体吞吐量,都是确保ActiveMQ能够在高负载环境下稳定运行的关键。此外,对于特定的需求,还可以根据实际情况...
- **Prefetch Size**:预取大小,调整消费者一次性获取的消息数量,平衡延迟和吞吐量。 - **Use Topic or Queue**:根据应用场景选择合适的消息模型,发布/订阅适合广播,队列适合一对一传输。 - **Dedicated ...
- **高性能**: ActiveMQ在单台服务器上可以达到每秒数十万条消息的吞吐量。 - **高可用性**: 支持多种集群配置模式,包括主从、镜像、多播等,确保消息的可靠传递。 - **灵活性**: 支持多种传输协议如AMQP、OpenWire...
通过性能测试,我们可以了解ActiveMQ在高负载情况下的表现,包括吞吐量、延迟、资源消耗等方面,这有助于我们优化系统配置,确保在实际生产环境中能够满足业务需求。 **ActiveMQ 测试报告** "ActiveMQ测试报告.pdf...
多线程的设计可以提高消息处理的吞吐量,但需要注意线程安全问题,如锁的使用,以避免数据竞争和死锁。 8. **测试和调试**: 对于这样的多线程应用,进行充分的单元测试和集成测试是必要的,以确保在各种场景下都...
在GUI模式下,首先进行小规模的压力测试,逐步增加并发用户数量,观察ActiveMQ的吞吐量、延迟和错误率。 4.2 第二轮(headless模式) 为了更接近实际运行环境,后续转为非GUI模式(headless模式),继续增加负载,...
6. **性能优化**:ActiveMQ支持多种策略优化性能,如预取策略、批量发送和消息压缩,以减少网络延迟和提高吞吐量。 7. **管理工具**:ActiveMQ提供了一个Web控制台,用户可以通过浏览器进行监控和管理消息队列,...
- **高性能**:优化的消息传输机制,提升系统的吞吐量。 - **可伸缩**:可以根据系统负载动态调整资源,适应业务增长。 - **易用和安全**:提供友好的管理控制台和API,便于配置和监控,同时支持用户认证和权限管理...
- **高吞吐量**:优化的消息传递性能,支持大量并发连接和消息。 - **多种协议支持**:包括AMQP、STOMP、XMPP等,便于与其他系统集成。 - **安全机制**:用户认证和授权,支持SSL/TLS加密,确保数据安全。 - **...
由于ActiveMQ是一个高性能的消息中间件,因此它在需要高吞吐量和低延迟的场景中尤为受到欢迎。例如,在金融、电信和物联网等领域,ActiveMQ可以处理大量的并发消息传输。同时,ActiveMQ的开源特性也意味着它拥有一个...
5. **高性能**:ActiveMQ采用优化的内存管理和多线程处理,确保了高吞吐量和低延迟。 6. **管理工具**:ActiveMQ提供Web控制台和命令行工具,方便管理员监控和管理消息队列。 三、使用ActiveMQ开发JMS 1. **安装...
3. **异步处理**:非关键任务可以通过MQ异步处理,提高系统整体的响应速度和吞吐量。例如,一个用户下单后,订单处理、库存检查等操作可以异步进行,不影响用户的购物体验。 4. **延迟和定时任务**:ActiveMQ支持...
同时,通过优化内存管理和多线程处理,ActiveMQ能够处理大量并发连接和高吞吐量的消息传输。 3. **网络拓扑**:ActiveMQ可以设置为集群模式,提供高可用性和负载均衡。集群中的每个节点都可以接收和转发消息,如果...
11. **高性能**:ActiveMQ使用高效的内存管理策略和优化的数据结构,确保高吞吐量和低延迟。 12. **可扩展性**:ActiveMQ设计为模块化,可以根据需要添加或移除功能,以适应不同的应用场景。 通过Apache ActiveMQ ...
1. **高性能**:ActiveMQ以其高吞吐量和低延迟著称,能够在大规模并发环境中稳定运行。 2. **多协议支持**:除了JMS,ActiveMQ还支持STOMP、AMQP、XMPP、OpenWire等多种消息协议,能够适应不同类型的客户端需求。 3....
例如,测试消息的延迟、吞吐量、并发处理能力等,这些都是评估消息中间件性能的关键指标。此外,还可以模拟网络故障、服务器宕机等场景,检验ActiveMQ的容错能力和恢复机制。 总之,ActiveMQ作为一款强大的消息...
- **异步处理(Asynchronous Processing)**:ActiveMQ 允许后台处理任务,提高系统的响应速度和吞吐量。 - **可扩展性(Scalability)**:随着业务增长,可以通过增加 ActiveMQ 实例来横向扩展。 ### 4. ActiveMQ 的...
- ActiveMQ设计为高吞吐量和低延迟,适合处理大量消息。 2. **易用性** - 提供简单易用的API,方便开发者快速上手。 3. **丰富的功能** - 支持多种消息传递模式、持久化存储、集群等功能。 4. **广泛的社区支持**...