尴尬的事情又发生Newtonsoft.Json vs Protobuf.net

Posted 2021-04-11 beetlex

写程序做下性能测试都是例行的事情了，一般在普通电脑上测试一下如果比较理想那基本不出什么意外！但世事难料,代码写得不好经常提心CPU不够用，其实写得好但不能完全发挥出CPU资源的优势更是一件悲剧的事情！这次事件已经发生了两回，其实还真的很折磨人的。话不多说回到今天的正题Newtonsoft.Json vs Protobuf.net,对于两者的性能我相信大部分人会站在Protobuf.net这一边，的确Protobuf.net作为进制序列化比JSON文本的序列化要高效也是正常事情；但总会有些情况让人难以预料的！接下来看一下测试情况

低置下测试

测试硬件:配置是E3-1230V2 测试用例:返回指定数据量的客户列表信息

Newtonsoft.Json

protobuf.net

由于数据都是字符类型的字段，所以Protobuf.net在性能上并没占有多大的优势，不过的确可以节省大量的带宽，大概能节少40%的带宽资源。其实从测试结果看来JSON处理也并没有想像中那么慢，性能差距在20-30%之间，其实还是可以接受的。

高配置下测试

既然在低配置的机器上Protobuf.net有优势，那高配置的服务器按理也不会存在什么问题。但测试结果告诉我们，Protobuf.net输给了Newtonsoft.Json! 测试硬件:配置是E5-2670V2*2 测试用例:返回指定数据量的客户列表信息

获取３个客户信息

JSON

Protobuf

获取10个客户信息

JSON

Protobuf

获取20个客户信息

JSON

Protobuf

随着返回的列表数据越大，Protobuf.net的响应延时就越高，但服务器的ＣＰＵ资源占用率比较低。而Newtonsoft.Json虽然损耗了大量的CPU资源，但它能通过CPU资源可以有效地把并发数量提升起来；当在获取２０个客户信息的时候，基本把１０Ｇb的带宽占满并达到180000RPS。Protobuf.net在CPU资源占用率上来说虽然比'Newtonsoft.Json'要低很多，但面对一个悲剧的事情就是无法把RPS提升上去，在最后的测试结果里落后了Newtonsoft.Json一倍的RPS.

总结

随着更多硬件资源大规模化，在测试程序的时候也要考虑这情况，程序无法在高配置资源完全发挥硬件资源的优势这种情况针对我个人而言已经是第二次了，这种事情刚开始真让人感觉到相当无助，因为这真的很难让人接受的事实！其实出现这情况都是程序的某个功能点在多线程并发上出现了拥挤的情况，第一次出现这情况是.net core的ServerGC设置，而这一次看了Protobuf.Net的代码发现有些关键方法静态方法上出现的多对象锁的代码，可能是这些锁导致在更多线程资源使用的时候无法达到一个更好的并发效果。最后在这里提醒一下测试的朋友，程序的性能很重要，但有一点更重要的就是完全发挥所有硬件资源处理更多的事情！