主流go-web服务端框架性能测试

最新推荐文章于 2024-04-03 15:00:15 发布

置顶

ws_lzy007

最新推荐文章于 2024-04-03 15:00:15 发布

阅读量1.2k

点赞数

分类专栏：网络技术网络安全 IPv6

本文链接：https://blog.csdn.net/ws_lzy007/article/details/102664570

版权

本文旨在通过性能测试，比较Go语言中的go-restful, go-echo, go-iris, go-gin和go-chi框架，以及一个自研的C++服务框架。测试指标包括吞吐量和QPS，结果显示，Go框架中gin、chi和echo表现接近，iris较差，Go框架整体资源消耗高于C++，但Go的易用性和简洁性突出。" 5560400,413135,有意识地练习：通往杰出成就的秘诀,"['工作', '教育', '创业', '商业', '成功学']

摘要由CSDN通过智能技术生成

测试目的

由于K8s缘故涉猎go语言，发现golang的web框架很多，都号称高性能标杆；之前一直致力于c++高性能服务端框架研究，出于好奇，想单从性能层面客观比较一下go的众多web框架，另一方面也希望看看c++的实现与go语言实现之间究竟存在多大差异。

高性能服务框架评估指标很多，但一般来讲吞吐量与QPS是关键考量指标，吞吐量衡量带宽利用率，QPS主要考验框架调度性能（几乎所有可称之为“高性能”的服务框架都没有吞吐量问题，毕竟网络瓶颈很轻易就达到了）。由于是框架本身QPS测试，为了屏蔽http协议实现差异选择最精简的协议头（协议处理一般不会有锁，为cpu密集型），因此要求请求/返回报文尽可能小，本文测试基于http协议，返回空报文。

为了实现测试的第二个目的，特将一个自撸的c++服务框架作为c++实现的”砖头”，加入到对比测试中。此框架尚未开源，其高性能特性保障体现在如下设计上：

跨平台实现socket多路复用，支持：poll、epoll、kqueue、port、select、IOCP等模型
采用lock-free算法
线程池设计
socket连接池
多级任务队列
……

PS：
好吧，这样一来貌似更接近测试socket服务框架调度性能……
不要纠结keep-alive，因为wrk使用HTTP/1.1，默认都是keep-alive的

测试环境

环境设置

ulimit -n 2000

压测工具

wrk
由于环境限制，只能wrk客户端和待测试服务端在一台机器上运行

c++自研框架

启动脚本：(最大2000个并发连接，2个线程处理，http端口8080)
./proxy_server -i2000 -o2000 -w2 -x8080
如有条件测试linux系统可自行下载服务端(选择对应平台的包)：https://github.com/lazy-luo/smarGate
http返回报文：

$ curl -i http://localhost:8080/
HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive

压测结果：

$wrk -d 100s -c 1024 -t 8 http://localhost:8080/
Running 2m test @ http://localhost:8080/
  8 threads and 1024 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    13.03ms    3.80ms 100.73ms   86.97%