把整个文件传过去就行了。基于linkedin的基准（我添加了相关细节）。
我主要展示了100字节小消息的性能。较小的消息对于消息传递系统来说是一个更困难的问题，因为它们放大了系统记账的开销。当我们改变记录大小时，我们可以通过以记录/秒和mb/秒为单位绘制吞吐量来显示这一点。

所以，正如我们所料，这个图表显示了我们每秒可以发送的原始记录数随着记录的增大而减少。但是，如果我们看看mb/秒，我们会发现随着消息变大，实际用户数据的总字节吞吐量会增加：

我们可以看到，对于10字节的消息，我们实际上受到cpu的限制，仅仅获取锁并将消息排队发送，我们实际上无法最大限度地扩展网络。但是，从100字节开始，我们实际上看到了网络饱和（尽管mb/秒继续增加，因为我们的固定大小簿记字节在发送的总字节中所占的百分比越来越小）。

按原样发送xml文件没有什么问题。考虑到负载的大小，您可能希望查看压缩选项，但是发送xml不会引起问题。