Go 如何通过AMQP 1.0在Azure事件中心中批量接收多条消息

我使用Apache Qpid Electron Go包装器为Qpid Proton设置了一个仅包含路径和过滤器的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), 
)

amqpConnection.Receiver(
            electron.Source("<EVENTHUB_PATH>"),
            electron.Capacity(100),
            electron.Prefetch(true),
            electron.Filter(filterMap),
)

我还尝试在与活动中心位于同一Azure位置的Azure VM中运行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如果它更像是一个支持案例而不是一个问题/答案。

感谢您确认“预回迁”是正确的选项，是否有其他与“批处理”相关的设置可以添加到AMQP连接/链接？在我的例子中，我把这个

time.Sleep（2*time.Second）

放在

无限循环中，用于接收消息。我正在对AMQP接收器进行故障排除/测试，我需要降低速率，然后我忘了移除睡眠。。。删除该睡眠呼叫后，消息速率相当高。所以问题是我，而不是代码：）预取是找到最佳数字的关键实验。大到足以消除流量中常见的尖峰/漏洞，但不能再大——速度慢的用户可能会将消息备份到过大的预回迁缓冲区中，并使其他用户挨饿。
$ ./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