3

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

使用 Openwire

持久消息大小：43 个字节，无压缩，200 个并发连接，吞吐量约为 9006 msgs/sec。

持久消息大小：1580 个字节，无压缩，200 个并发连接，吞吐量约为 3678.86 msgs/sec。

CPU 上的负载少于5%，因此我可以使用压缩来获得更好的吞吐量，但这是另一回事。

使用 AMQP 1.0

持久消息大小：43 个字节，无压缩，200 个并发连接，吞吐量约为 12.8 msgs/sec。

持久消息大小：1580 个字节，无压缩，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 在下面指出的那样，我的比较是不正确的，我对 Openwire 使用 Async.Send，对 AMQP 1.0 使用 Sync.Send，我误解了 AMQP 1.0 默认使用 Async.Send。Robbie 指出，持久消息并非如此。这是正确的比较数字

使用 Openwire 持久消息大小进行同步发送：43 个字节，无压缩，200 个并发连接，100,000 条消息计数，吞吐量约为 13.1 毫秒/秒。

持久消息大小：1580 个字节，无压缩，200 个并发连接，100,000 条消息计数，吞吐量约为 13.1 msgs/sec。

使用 AMQP 1.0 的同步发送 持久消息大小：43 个字节，无压缩，200 个并发连接，100,000 条消息计数，吞吐量约为 12.8 毫秒/秒。

持久消息大小：1580 个字节，无压缩，200 个并发连接，100,000 条消息计数，吞吐量约为 11.9 msgs/sec。

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

持久消息大小：1580 个字节，无压缩，200 个并发连接，100,000 条消息计数，吞吐量约为 3678.86 msgs/sec。

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

持久消息大小：1580 个字节，无压缩，200 个并发连接，100,000 条消息计数，吞吐量约为 21.2 msgs/sec。

笔记：

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

AMQP 1.0 Async.Send 号码仍然不接近 Openwire Async.Send 号码。还有其他建议吗？

谢谢你的帮助。

4

2 回答 2

1

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

正如 Tim 已经提到的，异步发送持久性消息有点不寻常（至少在不使用事务来强加某种程度的同步确认以用于绑定目的时）。

于 2014-07-18T17:59:18.477 回答
1

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

我不相信 QPid JMS 客户端被实现为性能最高的 AMQP 1.0 客户端，而是更多的概念证明，因此这可能会随着新客户端的编写而改变。这里的另一个瓶颈是 ActiveMQ 使用的 Proton-J 的当前实现与我们长期强化的 OpenWire 传输相比性能不是很好，因此在该库变得更好之前，性能将受到影响。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，它也有一些改进。这将是一个持续工作的领域，因此您可以预期性能情况会随着时间的推移而改善。

于 2014-07-16T02:05:31.587 回答