0

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

  • 钥匙有多大？
  • 字符串的存储方式（一个字段与多个字段）

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

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

4

2 回答 2

3

来自关于超大消息的 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 中的消息开销在很大程度上很简单：

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

注意：如果您使用嵌套消息，只需递归上述内容。

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

您可能会发现，如果您以压缩形式传输字符串，则可以通过使用启用压缩的 rvrd 或通过更改您的生产者/消费者以使用快速但有效的东西（如放气）（或者如果你感觉像 QuickLZ、FastLZ、LZO 等深奥的东西。尤其是那些具有固定内存占用压缩/解压缩引擎的东西）

你没有说你的目标是哪个平台 api（例如.net/java/C++/C），这会让事情变得有点色彩。在网络上，所有字符串数据将在每个字符 1 个字节中，无论 java/.net 默认使用 UTF-16，但是由于无法重用底层缓冲区，将这些数据放入/从消息中读取会产生巨大的翻译成本在这些情况下，必须执行副本（分别是压缩/扩展）。如果您坚持使用不透明的字节序列，您仍然可以通过托管包装器 api 在幼稚的实现中产生复制开销，但如果您不需要将数据作为本机字符串处理，这至少会减少开销。

于 2009-12-07T17:36:44.443 回答
0

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

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

于 2018-03-20T16:04:33.327 回答