ActiveMQ 5.10 / QPid 0.28 / AMQP 1.0性能问题

时间:2014-07-15 21:05:55

标签: performance activemq amqp qpid

我正在尝试使用OpenWire和AMQP与ActiveMQ进行性能基准测试并获得巨大的吞吐量变化

使用Openwire

持久邮件大小:43个bye,     没压缩,     200个并发连接,     吞吐量约为9006 msgs / sec。

持久邮件大小:1580个byes,     没压缩,     200个并发连接,     吞吐量约为3678.86 msgs / sec。

没有太多的CPU负载小于5%所以我可以使用压缩来获得更好的吞吐量,但这是一个不同的故事。

使用AMQP 1.0

持久邮件大小:43个bye,     没压缩,     200个并发连接,     吞吐量约为12.8 msgs / sec。

持久邮件大小:1580个byes,     没压缩,     200个并发连接,     吞吐量约为11.9 msgs / sec。

我们的配置为

**Client**
    - JMeter 2.11 using Apache QPid 0.28 as AMQP 1.0 client
    - Java 1.7
    - Ubuntu 12.04 LTS Quad Core 2.0 GHz,7GB RAM, 512 KB Cache

**Broker**
    - ActiveMQ 5.10 with KahaDB, using LevelDB didn't give much different numbers
    - Java 1.7
    - Ubuntu 12.04 LTS Quad Core 2.0 GHz,7GB RAM, 512 KB Cache

调整工作:

我查看了以下内容

对于Openwire,在Broker方面,将tcp更改为nio

<transportConnector name="openwire" uri="nio://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.tcpNoDelayEnabled=true&amp;wireFormat.maxFrameSize=104857600"/>

On Client side url was as
    tcp://<broker ip>:61616?jms.useAsyncSend=true

对于AMQP 1.0,在Broker方面,更改为nio并在url上添加了一些选项但没有明显效果

<transportConnector name="amqp" uri="amqp+nio://0.0.0.0:5672?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>

On Client side
    connectionFactory = amqp://username:password@<broker ip>:5672?remote-host=default

Openwire上提供的所有调优选项在amqp上都不可用,特别是在使用jms的生产者上.useAsyncSend = true给了我巨大的性能提升,当然ack的可靠性较低。我发现默认情况下,默认情况下,默认情况下,amqp发送消息处于异步模式。显然这些数字告诉我们它可能正在以同步模式处理?

以下是我已经研究过的一些链接

更新1:

正如Tim在下面指出的,我的比较是不正确的,我使用Async.Send用于Openwire和Sync.Send用于AMQP 1.0,我错误地理解AMQP 1.0默认使用Async.Send。罗比指出,Persistent消息并非如此。这是正确的比较数字

使用Openwire同步发送 持久消息大小:43个字节,     没压缩,     200个并发连接,     100,000条消息计数,     吞吐量约为13.1 msgs / sec。

持久邮件大小:1580个byes,     没压缩,     200个并发连接,     100,000条消息计数,     吞吐量约为13.1 msgs / sec。

使用AMQP 1.0进行同步发送 持久消息大小:43个字节,     没压缩,     200个并发连接,     100,000条消息计数,     吞吐量约为12.8 msgs / sec。

持久邮件大小:1580个byes,     没压缩,     200个并发连接,     100,000条消息计数,     吞吐量约为11.9 msgs / sec。

Async.Send使用Openwire 持久消息大小:43个字节,     没压缩,     200个并发连接,     100,000条消息计数,     吞吐量约为9006 msgs / sec。

持久邮件大小:1580个byes,     没压缩,     200个并发连接,     100,000条消息计数,     吞吐量约为3678.86 msgs / sec。

使用AMQP 1.0发送Async.Send 持久消息大小:43个字节,     没压缩,     200个并发连接,     100,000条消息计数,     吞吐量约为21.7 msgs / sec。

持久邮件大小:1580个byes,     没压缩,     200个并发连接,     100,000条消息计数,     吞吐量约为21.2 msgs / sec。

注意:

即使使用Async.Send也无法保证邮件传递,使用Openwire我总是收到所有100,0000条消息,而使用AMQP 1.0时,大约25%的邮件丢失。

AMQP 1.0 Async.Send数字仍未接近Openwire Async.Send数字。还有其他建议吗?

感谢您的帮助。

2 个答案:

答案 0 :(得分:1)

目前在Broker方面你可以做很多事情来改善AMQP的表现。请记住,您没有在此处进行真正的比较,因为您已禁用ActiveMQ客户端上的同步发送,这导致生产者的交付少于保证。如果你想尝试以这种方式比较它们,那么你应该尝试让QPid JMS客户端也以这种方式发送它的消息。在QPid JMS ConnectionFactory上有一个同步发布选项,您可以尝试查看是否可以让它不发送未设置的消息,因为基本上每个消息都需要一个确认。

我不认为QPid JMS客户端是作为性能最高的AMQP 1.0客户端实现的,而是更多的概念证明,因此这可能会随着新客户端的编写而改变。这里的另一个瓶颈是Proton-J的当前实现,与我们长期强化的OpenWire传输相比,ActiveMQ使用的效果不是很高,因此在该库变得更好之前性能将受到影响。 Proton-J一直​​在不断发展,所以事情应该随着时间的推移而改善。

如果您只使用AMQP客户端发送和接收,则可以在ActiveMQ中配置AMQP传输以使用原始变换器选项,这将降低每条消息的工作量,但不会为您节省很多。

<transportConnector name="amqp" uri="amqp://localhost:5672?transport.transformer=raw"/>

您最好的选择是深入了解QPid JMS客户端代码,看看您是否可以将其配置为发送已解决的持久消息。

在这个阶段,OpenWire在ActiveMQ上的速度总是比AMQP快,所以除非你有一些令人信服的理由使用AMQP只是坚持使用原生的OpenWire客户端。您可以尝试主动版本的ActiveMQ(v5.11-SNAPSHOT),它在AMQP方面做了一些额外的工作,这确实改进了一些东西,它使用了最新版本的Proton-J,它也有一些改进。这将是一个持续工作的领域,因此您可以预期性能图将随着时间的推移而改善。

答案 1 :(得分:1)

Qpid 0.28 AMQP 1.0 JMS客户端默认情况下同步发送持久性消息,默认情况下异步发送非持久性消息。您可以按如下方式使发送异步:将sync-publish = false添加到单个连接URL,或者设置Java系统属性&#34; qpid.sync_publish&#34;真正。有关详细信息,请参阅https://issues.apache.org/jira/browse/QPID-5574

正如Tim已经提到的,异步发送持久性消息有点不寻常(至少在使用事务时不会为了边界目的而强制执行某种级别的同步确认)。