使用AMQP 1.0向qpid C++代理发送大消息的性能问题

1. 性能差异的核心原因 #

发送端与代理间的性能差距主要源于发送端未利用Qpid Proton的大消息优化特性，具体可能包括以下几点：

• 未启用流模式：如果发送端将整个400MB文件一次性加载到内存并封装为单个AMQP消息体，会触发大量内存拷贝操作，且Proton默认会对大消息做额外的内存处理，导致耗时剧增；而代理到接收端的转发是基于缓冲区的直接传递，无需重新封装消息体，因此速度极快。
• 默认帧大小过小：AMQP 1.0默认帧大小为64KB，大消息会被拆分成千上万个小帧发送，每个帧都要经过协议处理、SSL加密，频繁的帧交互大幅增加了开销。
• 流量控制窗口限制：Proton客户端默认的发送窗口（outgoing window）较小，代理会频繁触发流量控制，发送端需要等待窗口更新才能继续发送数据，导致大量等待时间。
• SSL加密的逐帧处理：发送端对每个小帧单独加密，而代理转发时可能批量处理缓冲区，加密/解密的效率差距被放大。

2. 是操作有误还是预期行为？ #

这显然是操作有误，而非AMQP 1.0或Qpid组件的预期行为。接收端能在2秒内完成140MB消息的接收，说明代理与接收端的配置已经适配大消息场景，问题完全出在发送端的实现细节上，没有利用Proton提供的大消息优化机制。

3. 发送端性能优化措施 #

针对上述原因，可采取以下具体优化手段：

启用流模式发送大消息 #

不要将整个文件加载到内存，而是使用Proton的流API分块读取并发送，避免内存拷贝和大内存分配。示例代码片段（C++）：

// 创建流消息
pn_message_t *msg = pn_message();
pn_message_set_address(msg, "my_queue");
pn_message_set_body_stream(msg, NULL); // 标记为流消息

// 打开发送者
pn_sender_t *sender = pn_sender(pn_session(conn), "sender");
pn_sender_open(sender);

// 分块读取文件并发送
char buffer[1024*1024]; // 1MB块大小
FILE *f = fopen("large_file.bin", "rb");
size_t bytes_read;
while ((bytes_read = fread(buffer, 1, sizeof(buffer), f)) > 0) {
    pn_data_t *body = pn_message_body(msg);
    pn_data_clear(body);
    pn_data_put_binary(body, pn_binary(buffer, bytes_read));
    pn_sender_send(sender, msg, NULL);
    pn_work(conn); // 处理IO事件
}
fclose(f);
pn_message_free(msg);

调大AMQP帧大小 #

通过设置连接的最大帧大小，减少帧的数量，降低协议交互开销：

pn_connection_set_max_frame_size(conn, 1024*1024); // 设置为1MB，可根据实际调整

优化流量控制窗口 #

增大发送窗口，允许代理一次性接收更多数据，减少等待时间：

pn_session_set_outgoing_window(pn_session(conn), 1000); // 调整窗口大小，值越大允许发送的未确认帧越多

SSL加密优化 #

• 启用SSL会话复用，避免每次连接重新握手：在客户端SSL配置中开启会话缓存。
• 选择高效的加密套件，比如AES-GCM（比CBC模式性能更高）。

其他优化点 #

• 升级Qpid Proton到最新稳定版本，修复已知的大消息性能bug。
• 避免不必要的内存拷贝：直接将文件读取到Proton的发送缓冲区，而非先存储到自定义缓冲区再拷贝。
• 确保发送端的事件循环（pn_work或pn_run）高效运行，避免阻塞IO操作占用CPU时间。

内容的提问来源于stack exchange，提问作者Gabriel T