Java&Go 三种 HTTP 服务端端性能测试
上期分享了Java&Go三种HTTP客户端性能测试,最终的结论是 fasthttp > FunTester > http。那么由三种框架创建的服务端性能怎么样呢?今天我们来一起测试一下。
本次测试计划分为不同线程时候,各个服务端的响应 QPS 以及资源占用的情况。上次发现的 Mac 本地 HTTP 服务极限性能有所下降,之前最高能到 12 万,升级了几次系统之后就变低了,一直没找到解决方案。所以以后应该都不会单独测试某种框架的极限性能了,更多还是对比压测。
测试用例
测试用例采用了 FunTester 常用的测试用例模板com.funtester.frame.thread.RequestThreadTimes
,已经好久没用过固定模板了,刚开始有点生疏。脚本如下:
线程数,软启动时间,以及请求次数都没有做参数化,直接写死了。
服务端
服务端不涉及业务,直接返回**Have Fun ~ Tester !**字符串作为响应。
FunTester
还是采用 moco_FunTester 的框架,底层用的 mocoAPI,做了简单封装,这个框架我一直在用,性能还是不错的,最早 12 万 QPS 就是用这个框架实现的。服务端代码如下:
http
Go 语言的 http 框架服务端写法有很多种,这里我选择了代码行数最少的一种,时间有限,不能一一测试,个人感觉不同的写法对性能影响不大。
fasthttp
原因同上,内容如下:
实测结果
结论
总体上来看依然跟客户端性能排行一致 fasthttp > FunTester > http。Go 语言在内存上简直离谱,http 框架的 QPS 略低,在 CPU 方面消耗也多。看来 Go 语言以后高性能 HTTP 框架还是得 fasthttp 撑住场面。看资料 fasthttp 这完全得益于对象池的概念,后面 FunTester 在拓展的时候也抄了这个涉及。不过在高性能 HTTP 服务处理业务的时候 fasthttp 有还有一些坑,也是对象池带来的,各位有需求的可以搜一搜,避免掉坑里。
Have Fun ~ Tester !
版权声明: 本文为 InfoQ 作者【FunTester】的原创文章。
原文链接:【http://xie.infoq.cn/article/79f52a5f5be9f73a863d7d35c】。文章转载请联系作者。
评论