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

时间 2019-12-08

标签事情发生 newtonsoft.json newtonsoft json protobuf.net protobuf 栏目 JSON 繁體版

原文原文链接

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

低置下测试

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

Newtonsoft.Json

D:\>bombardier.exe -c 100 -n 10000000 http://192.168.2.18:8080/customers_json/3
Bombarding http://192.168.2.18:8080/customers_json/3 with 10000000 request(s) us
ing 100 connection(s)
 10000000 / 10000000 [==========================================] 100.00% 1m16s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec    131290.96   14813.10  146691.93
  Latency      757.08us     1.13ms   398.02ms
  HTTP codes:
    1xx - 0, 2xx - 10000000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   118.21MB/s

protobuf.net

D:\>bombardier.exe -c 100 -n 10000000 http://192.168.2.18:8080/customers_protobu
f/3
Bombarding http://192.168.2.18:8080/customers_protobuf/3 with 10000000 request(s
) using 100 connection(s)
 10000000 / 10000000 [===========================================] 100.00% 1m5s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec    152160.79   14677.95  163191.02
  Latency      653.08us     1.10ms   396.02ms
  HTTP codes:
    1xx - 0, 2xx - 10000000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:    86.35MB/s

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

高配置下测试

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

获取３个客户信息

JSON

G:\>bombardier.exe -c 100 -n 10000000 http://192.168.2.19:8080/customers_json/3
Bombarding http://192.168.2.19:8080/customers_json/3 with 10000000 request(s) us
ing 100 connection(s)
 10000000 / 10000000 [============================================] 100.00% 36s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec    271738.73   67774.12  329181.89
  Latency      361.86us     4.37ms      3.06s
  HTTP codes:
    1xx - 0, 2xx - 10000000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   244.72MB/s

Protobuf

G:\>bombardier.exe -c 100 -n 10000000 http://192.168.2.19:8080/customers_protobu
f/3
Bombarding http://192.168.2.19:8080/customers_protobuf/3 with 10000000 request(s
) using 100 connection(s)
 10000000 / 10000000 [============================================] 100.00% 41s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec    243710.66   28345.63  275334.86
  Latency      406.47us   829.25us   394.02ms
  HTTP codes:
    1xx - 0, 2xx - 10000000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   138.26MB/s

获取10个客户信息

JSON

G:\>bombardier.exe -c 100 -n 10000000 http://192.168.2.19:8080/customers_json/10

Bombarding http://192.168.2.19:8080/customers_json/10 with 10000000 request(s) u
sing 100 connection(s)
 10000000 / 10000000 [============================================] 100.00% 51s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec    196290.74   66381.50  263699.22
  Latency      502.81us     4.00ms      3.05s
  HTTP codes:
    1xx - 0, 2xx - 10000000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   513.10MB/s

Protobuf

G:\>bombardier.exe -c 100 -n 10000000 http://192.168.2.19:8080/customers_protobu
f/10
Bombarding http://192.168.2.19:8080/customers_protobuf/10 with 10000000 request(
s) using 100 connection(s)
 10000000 / 10000000 [==========================================] 100.00% 1m14s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec    135254.64   24971.37  165490.90
  Latency      737.06us     1.24ms   513.03ms
  HTTP codes:
    1xx - 0, 2xx - 10000000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   200.84MB/s

获取20个客户信息

JSON

G:\>bombardier.exe -c 100 -n 10000000 http://192.168.2.19:8080/customers_json/20

Bombarding http://192.168.2.19:8080/customers_json/20 with 10000000 request(s) u
sing 100 connection(s)
 10000000 / 10000000 [============================================] 100.00% 54s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec    182806.15   37623.75  209487.43
  Latency      541.37us     1.48ms      0.90s
  HTTP codes:
    1xx - 0, 2xx - 10000000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     0.89GB/s

Protobuf

G:\>bombardier.exe -c 100 -n 10000000 http://192.168.2.19:8080/customers_protobu
f/20
Bombarding http://192.168.2.19:8080/customers_protobuf/20 with 10000000 request(
s) using 100 connection(s)
 10000000 / 10000000 [==========================================] 100.00% 1m50s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec     90249.67    9611.23  102294.37
  Latency        1.10ms     1.04ms   518.03ms
  HTTP codes:
    1xx - 0, 2xx - 10000000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   246.07MB/s

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

总结

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

若是感兴趣这个测试的代码，能够经过如下地址获取:https://github.com/IKende/FastHttpApi/blob/master/WebApi_json_vs_protobuf.zip性能