我的protobuf消息中有一些重复元素.在运行时,消息的长度可以是任何东西 - 我看到一些已经问过的问题 - [1]:最大序列化Protobuf消息大小
我这里有一个略有不同的问题.如果我的JMS(Java消息服务)提供程序(在本例中是我的weblogic或tibco jms服务器)对最大消息大小没有任何大小限制,那么协议缓冲区编译器是否会抱怨最大消息大小？
编码/解码的性能是否会在大尺寸(大约10MB)下遭受可怕的影响.
Kenton Varda.. 43
10MB正在推动它,但你可能会好起来的.
Protobuf的硬限制为2GB,因为许多实现使用32位带符号算法.出于安全原因,许多实现(尤其是Google提供的实现)默认情况下会将大小限制设置为64MB,但如果需要,可以手动增加此限制.
对于大型消息本身,实现不会"减速",但问题是您必须始终先解析整个消息,然后才能开始使用任何内容.这意味着整个消息必须适合RAM(请记住,解析内存中的消息对象比原始序列化消息大得多),即使你只关心一个字段,你也要等待整个事情.解析.
一般来说,我建议尝试将自己限制为1MB作为经验法则.除此之外,考虑将消息拆分为多个可以独立解析的块.但是,每个应用程序 - 对于一些应用程序来说,10MB并不是什么大问题,对于其他应用程序来说1MB已经太大了.您需要配置自己的应用以了解相关信息.
我实际上已经看到人们很高兴发送大于1GB的邮件的情况,所以......它"有效".
另外,Cap'n Proto的设计与Protobuf非常相似,但可以支持最多2 ^ 64字节的消息(每个4GB的2 ^ 32段),它实际上允许您从消息中读取一个字段解析整个消息(如果它在磁盘上的文件中,请使用mmap()以避免读取整个消息).
(披露:我是Cap'n Proto的作者以及Google的大部分开源Protobuf代码.)
10MB正在推动它,但你可能会好起来的.
Protobuf的硬限制为2GB,因为许多实现使用32位带符号算法.出于安全原因,许多实现(尤其是Google提供的实现)默认情况下会将大小限制设置为64MB,但如果需要,可以手动增加此限制.
对于大型消息本身,实现不会"减速",但问题是您必须始终先解析整个消息,然后才能开始使用任何内容.这意味着整个消息必须适合RAM(请记住,解析内存中的消息对象比原始序列化消息大得多),即使你只关心一个字段,你也要等待整个事情.解析.
一般来说,我建议尝试将自己限制为1MB作为经验法则.除此之外,考虑将消息拆分为多个可以独立解析的块.但是,每个应用程序 - 对于一些应用程序来说,10MB并不是什么大问题,对于其他应用程序来说1MB已经太大了.您需要配置自己的应用以了解相关信息.
我实际上已经看到人们很高兴发送大于1GB的邮件的情况,所以......它"有效".
另外,Cap'n Proto的设计与Protobuf非常相似,但可以支持最多2 ^ 64字节的消息(每个4GB的2 ^ 32段),它实际上允许您从消息中读取一个字段解析整个消息(如果它在磁盘上的文件中,请使用mmap()以避免读取整个消息).
(披露:我是Cap'n Proto的作者以及Google的大部分开源Protobuf代码.)
京公网安备 11010802040832号 | 京ICP备19059560号-6 