我使用Qpid Proton的Apache Qpid Electron Go包装器设置了一个AMQP 1.0链接,其中只有路径和过滤器,如下所示:
amqpConnection.Receiver(
// the path containing the consumer group
// and the partition Id
electron.Source("<EVENTHUB_PATH>"),
// the filter map contains some annotations filters
// for the Event Hub offset
electron.Filter(filterMap),
)
我按照此文档设置AMQP链接选项:https://godoc.org/qpid.apache.org/electron#LinkOption
但是,在运行Go应用程序时,我意识到它获取消息的速度非常慢,因此我添加了另外2个链接选项,如下所示:
amqpConnection.Receiver(
electron.Source("<EVENTHUB_PATH>"),
electron.Capacity(100),
electron.Prefetch(true),
electron.Filter(filterMap),
)
但是在添加容量和预取链接选项后,我没有看到性能有任何提高。
我每约5秒从4个并行链路(每个分区一个链路)接收大约10条消息。
我尝试使用环境变量PN_TRACE_RAW=true
运行应用程序,用于Qpid Proton的详细输出(参见this:https://qpid.apache.org/releases/qpid-proton-0.18.0/proton/c/api/group__transport.html),但我不确定应该寻找什么来解决此问题。
我不认为Qpid设置有任何问题,但无论如何,这是我在终端上看到的:
[0x9fd490]:0 -> @attach(18) [name="<MY_CUSTOM_NAME>",
handle=1, role=true, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [address="<MY_CUSTOM_PATH>",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, filter={:string=@:"apache.org:selector-filter:string"
"amqp.annotation.x-opt-offset > '<MY_CUSTOM_OFFSET>'"}], target=@target(41) [address="",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]
[0x9fd490]:0 -> @flow(19) [next-incoming-id=1, incoming-window=2147483647, next-outgoing-id=1,
outgoing-window=0, handle=1, delivery-count=0, link-credit=100, drain=false]
我还尝试在与事件中心位于同一Azure位置的AzureVM中运行Go应用,但性能没有提高。
我怎么能在同一个“往返”中同时获取许多消息?我需要每秒处理数千条消息。
您需要一个预取窗口是正确的,但是电子客户端可以做得更好。
我用https://github.com/apache/qpid-proton/tree/master/examples/go/electron的电子样本做了一个快速测试
我得到3000 msg/秒,即使没有预取,和近10000 msg/秒。
$ ./broker -qsize 100000 &
Listening on [::]:5672
$ ./send -count 10000 /x ; time ./receive -count 10000 /x
Received all 10000 acknowledgements
Listening on 1 connections
Received 10000 messages
real 0m2.612s
user 0m1.611s
sys 0m0.510s
$ ./send -count 10000 /x ; time ./receive -count 10000 -prefetch 1000 /x
Received all 10000 acknowledgements
Listening on 1 connections
Received 10000 messages
real 0m1.053s
user 0m1.272s
sys 0m0.277s
很明显发生了一些有趣的事情——我想帮你弄清真相。
PN_TRACE_RAW有点太冗长了,没有帮助,试试PN_TRACE_FRM=1,这会给你一个更易读的摘要。
我很乐意在这里或users@qpid.apache.org继续谈话,如果它变成一个支持案例而不是一个问题/答案。