Java&Go三种HTTP服务端端性能测试

上期分享了Java&Go三种HTTP客户端性能测试，最终的结论是fasthttp > FunTester > http。那么由三种框架创建的服务端性能怎么样呢？今天我们来一起测试一下。

本次测试计划分为不同线程时候，各个服务端的响应QPS以及资源占用的情况。上次发现的Mac本地HTTP服务极限性能有所下降，之前最高能到12万，升级了几次系统之后就变低了，一直没找到解决方案。所以以后应该都不会单独测试某种框架的极限性能了，更多还是对比压测。

测试用例

测试用例采用了FunTester常用的测试用例模板com.funtester.frame.thread.RequestThreadTimes，已经好久没用过固定模板了，刚开始有点生疏。脚本如下：

    static String url = "http://localhost:8001/test";

    public static void main(String[] args) {
        HttpGet httpGet = getHttpGet(url);
        RUNUP_TIME = 0;
        RequestThreadTimes requestThreadTimes = new RequestThreadTimes(httpGet, 20000);
        new Concurrent(requestThreadTimes, 20, "FunTester").start();
    }

线程数，软启动时间，以及请求次数都没有做参数化，直接写死了。

服务端

服务端不涉及业务，直接返回Have Fun ~ Tester ！字符串作为响应。

FunTester

还是采用moco_FunTester的框架，底层用的mocoAPI，做了简单封装，这个框架我一直在用，性能还是不错的，最早12万QPS就是用这个框架实现的。服务端代码如下：

    static void main(String[] args) {
        def server = getServerNoLog(8001)
        server.response("Have Fun ~ Tester ！")
        def run = run(server)
        waitForKey("fan")
        run.stop()
    }

http

Go语言的http框架服务端写法有很多种，这里我选择了代码行数最少的一种，时间有限，不能一一测试，个人感觉不同的写法对性能影响不大。

func TestHttpSer2(t *testing.T) {
	http.Handle("/test", &indexHandler{content: "Have Fun ~ Tester ！"})
	http.ListenAndServe(":8001", nil)
}

fasthttp

原因同上，内容如下：

func TestFastSer2(t *testing.T) {
	address := ":8001"

	router := fasthttprouter.New()
	router.GET("/test", func(ctx *fasthttp.RequestCtx) {
		ctx.Response.SetBody([]byte("Have Fun ~ Tester ！"))
	})
	fasthttp.ListenAndServe(address, router.Handler)
}

实测结果

1线程

框架	CPU	内存	QPS
FunTester	39.85	212.2 MB	17073
Go(net/http)	93.72	16.5 MB	14124
Go(/valyala/fasthttp)	61.53	12.8 MB	17502

5线程

框架	CPU	内存	QPS
FunTester	185.75	181.8 MB	64690
Go(net/http)	311.89	18.4 MB	48608
Go(/valyala/fasthttp)	186.85	15.1 MB	67001

10线程

框架	CPU	内存	QPS
FunTester	276.91	161.0 MB	75795
Go(net/http)	479.69	19.0 MB	62534
Go(/valyala/fasthttp)	269.33	16.6 MB	75723

结论

总体上来看依然跟客户端性能排行一致fasthttp > FunTester > http。Go语言在内存上简直离谱，http框架的QPS略低，在CPU方面消耗也多。看来Go语言以后高性能HTTP框架还是得fasthttp撑住场面。看资料fasthttp这完全得益于对象池的概念，后面FunTester在拓展的时候也抄了这个涉及。不过在高性能HTTP服务处理业务的时候fasthttp有还有一些坑，也是对象池带来的，各位有需求的可以搜一搜，避免掉坑里。

Have Fun ~ Tester ！

• 140道面试题目（UI、Linux、MySQL、API、安全）
• 接口自动化面试题【思路分享】
• 分享一份Fiddler学习包
• Selenium自动化的JUnit参数化实践
• 绑定手机号性能测试
• 浏览器测试的三大挑战及解决方案【译】
• 移动测试工程师职业
• Groovy热更新Java实践
• Java线程安全ReentrantLock
• 无脚本测试
• 如何mock固定QPS的接口
• Selenium并行测试最佳实践
• 连开100年会员会怎样
• 控制台彩色输出