上期分享了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有还有一些坑，也是对象池带来的，各位有需求的可以搜一搜，避免掉坑里。