Question

我试图将一个可能很大的字符串放入一个集合点消息，并对大小限制感到好奇。我理解整个消息有一个物理限制（64mb？），但我很好奇其他变量如何影响它。具体做法是：

钥匙有多大？
如何存储字符串（在一个字段与多个字段中）

对于任何上述主题或任何其他可能相关的建议，我们将不胜感激。

注意：我想将消息保留为原始字符串（而不是字节码等）。

Answer 1

来自非常大消息的Tibco文档：

Rendezvous软件可以非常传输   大信息;它把它们分成了   小包，把它们放在上面   网络可以像网络一样快   接受他们。在某些情况下，这个   行为可以压倒网络   容量;应用可以实现   通过划分大的吞吐量来提高   消息分成更小的块和   调节它发送的速度   那些块。你可以使用   用于评估块的性能工具   尺寸和发送率最佳   吞吐量。

此示例发送一条消息   由一千万字节组成。   自动Rendezvous软件   将消息分成数据包和   发送它们。但是，这一阵   数据包可能超过网络容量，   导致吞吐量不佳：
sender> rvperfm -size 10000000 -messages 1   
在第二个例子中，申请分为千万字节变成一千个小每个万字节的消息，并自动确定批次尺寸和间隔来调节流量为获得最佳吞吐量：
sender> rvperfm -size 10000 -messages 1000 -auto   
通过改变-messages和-size 参数，你可以确定最佳消息大小特定网络中的应用程序。应用开发人员可以使用它调整发送率的信息提高性能。

对于实际限制，添加字符串函数采用C样式ansi字符串，因此理论上是无界限的，但是，给定AddOpaque的签名

tibrv_status tibrvMsg_AddOpaque( 
   tibrvMsg       message, 
   const char*    fieldName, 
   const void*    value, 
   tibrv_u32      size);

以u32为例，说明限制可能是4GB而不是64MB似乎是明智的。

那说使用Tib来传输这么大的数据包可能是一个严重的性能瓶颈，因为它可能需要缓冲大量的流量，因为它试图向所有消费者提供这些类型的消息。默认情况下，rvd缓冲区只有60秒，因此如果您的流量很大，您可能会发现自己正在遭受邮件丢失。

tibco中的消息开销很简单：

与每条消息相关的固定成本（标题）
所有字段（类型信息和字段ID）
加上所有可变长度方面的成本，包括：
1. 发送和接收主题（实际上限制为每个256字节）
2. 字段名称。我发现文档中字段名称的长度没有限制，但是它们越小越好，更好的是根本不使用它们并使用数字标识符
3. 消息

注意：如果您使用嵌套邮件，只需递归上述内容即可。

在您的情况下，与名称相比，有效负载开销将是如此巨大（只要它们合理且简单），尝试优化它们几乎没有意义。

如果您以压缩形式传输字符串，或者通过使用启用了压缩的rvrd，或者通过更改生产者/消费者来快速但有效地使用某些内容，您可能会发现在线路/缓冲上可以获得相当大的效率（或者如果你感觉像QuickLZ，FastLZ，LZO等那些深奥的东西，特别是那些具有固定内存占用压缩/解压缩引擎的东西）

你没有说你要针对哪个平台api（例如.net / java / C ++ / C），这会使事情变得有点颜色。在线上，所有字符串数据都是每个字符1个字节，无论java / .net默认情况下使用UTF-16，但是由于底层缓冲区无法重用，因此会将这些数据放入/读出消息中在这些情况下，必须执行副本（和压缩/扩展）。如果您坚持使用不透明的字节序列，您仍然可以通过托管包装器apis在naieve实现中获得复制开销，但如果您不需要将数据作为本机字符串使用，这将至少减少开销。

Answer 2

消息的总体最大大小为64MB，如OP中推测的那样。来自“Tibco Rendezvous Concepts”文件：

虽然交换大数据缓冲区的能力是Rendezvous的一项功能软件，最好不要让邮件太大。例如，交换数据高达10,000个字节，单个消息是有效的。但要发送可能的文件长度为兆字节，我们建议使用多个发送呼叫，也许一个对于每个记录，块或轨道。根据经验确定最有效的尺寸当前的网络条件。（实际大小限制为64 MB，很少适当的大小。）

Tibco Rendezvous - 尺寸限制

2 个答案: