Json 已成为当前服务器与 web 应用之间数据传输的公认标准。
成都创新互联公司自2013年创立以来,先为泰来等服务建站,泰来等地企业,进行企业商务咨询服务。为泰来企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
微服务及分布式架构经常会使用 Json 来传输此类文件,因为这已经是 webAPI 的事实标准。
不过正如许多我们习以为常的事情一样,你会觉得这是理所当然的便不再深入比较。
我们很少会去想用到的这些 Json 库到底有什么不同,但事实上它们的确是不太一样的。
因此,我们团队来对常用的三个 Json 库运行测试,看看在解析不同大小文件时哪个库的速度最快。
在给定的文件大小下,你可以看到不同库之间的解析速度存在着明显的差别。
高吞吐量的情况下,会频繁传输解析小文件,因此一开始的时候可能性能的差距并不明显。
但如果你需要在非常高负载下频繁地解析大量的小文件,差距就开始增大了。
不是所有的 Json 库都叫"特仑苏"。如何根据使用场景才选择正确的库是相当重要的。
回到顶部
选择三个个主流的Json 库来进行基准测试:Jackson, Json .simple,GSON
Yidong Fang 的 Json.simple (https://github.com/fangyidong/Json -simple)。Json.simple 是一个 Json 编解码的Java工具库。它旨在打造一个轻量简单且高性能的工具库。
Google 的 Gson (https://github.com/google/gson)。GSON 这个Java库能够在 Java 对象和 Json 间进行相互转换。同时它还提供了对Java泛型的完整支持,而且还不需要你在类上面添加注解。无需添加注解使用起来则更为便捷,同时在无法修改源代码的情况下这还是一个必要的先决条件。
FasterXML 的 Jackson 项目(https://github.com/FasterXML/jackson)。Jackson 是一个数据处理的工具套件,它的亮点是流式的 Json 解析器及生成器。它是专为Java设计的,同时也能处理其它非 Json 的编码。
回到顶部
我们同时使用大文件和小文件对这些库进行了基准测试。随着文件大小的不同,处理这些文本所需要的系统资源也会随之上升。
这个基准测试主要关注两个关键场景:
1.大文件下(190MB)的解析速度与小文件(1KB)下的解析速度。大文件取自这里:https://github.com/zeMirco/sf-city-lots-Json 。
2.小文件是从这里随机生成的:http://www.Json -generator.com/。
不管是大文件还是小文件,我们都会用同一个库重复运行10次。
对于每一个大文件,我们都会用同一个库来分别运行10 次。
而对于小文件,在单个库的单次运行中会重复执行10000 次。
在小文件测试的各次迭代中,文件内容都不会驻留在内存里。
Jackson 与 Json .simple 领跑了这轮测试,整体来看 Jackson 又要略优于 Json .simple。
从测试运行的平均结果来看,Jackson 与 Json .simple 在大文件上的表现要优秀。
而 JsonNP 排名第三落后甚远,Gson 更是遥遥垫底。
上表记录的是对每个文件解析10次的平均时间,总的平均时间见下方。各个库在小文件测试中夺冠的次数如下:
GSON - 14
Json P - 5
Jackson -1
Json .simple - 0
Gson 这个冠军还是当之无愧的,Json.simple 第二也没什么悬念。Jackson这轮却是垫底了。
尽管 Json.simple 没有在任何文件上夺得第一,但总体来看它的解析速度却是排名第二位的。
还有一个值得注意的是,尽管 Jackson 是这轮最慢的库,但是它在所有文件中的表现都非常一致。
其它三个库虽然偶然会比 Jackson 快很多,但在另一些文件上的解析速度却是旗鼓相当甚至更差。
回到顶部
解析速度并非衡量一个Json 库的唯一指标,但它的确非常重要。
通过运行这次基准测试,我们发现没有一个库能在所有文件上击败对手。
大文件中表现优秀的却在小文件上栽了根头,反之亦然。
如果要从解析速度来看选择哪个库的话还得取决于你的使用场景。
如果你的应用经常会处理大的 Json 文件,那么 Jackson 应该是你的菜。Gson 在大文件上表现得相当吃力。
如果你主要是处理小文件请求,比如某个微服务或者分布式架构的初始化,那么 Gson 当是首选。Jackson 在小文件上的表现则不如人意。
如果这两种文件你都经常会处理到,那么在两轮表现中都位居第二的 Json.simple 对此类场景则更为适合。