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 !