gin压测

提醒: 千万不能用win电脑去运行web进行压测,win电脑没优化,并发从几百到2000不等,根本达不到上万的qps

 

 

gin web代码:https://blog.youkuaiyun.com/cabing2005/article/details/78884138

[root@ycnode2 yc]# cat 1-test.go 
package main

import (
  "time"

  "net/http"

  "github.com/gin-gonic/gin"
)

func main() {
  route := gin.Default()
  route.GET("/ping", func(c *gin.Context) {

    //time.Sleep(time.Millisecond * 1)
    c.String(http.StatusOK, "OK")
  })
  s := &http.Server{
    Addr:      ":8090",
    Handler:    route,
    ReadTimeout:  1 * time.Second,
    WriteTimeout:  1 * time.Second,
    MaxHeaderBytes: 1 << 20,
  }
  s.ListenAndServe()
}
 

 

直接压测

 

 

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.81:8090/ping

Running 30s test @ http://192.168.11.81:8090/ping

 10 threads and 1000 connections

 Thread Stats  Avg   Stdev   Max  +/- Stdev

  Latency  86.22ms  92.88ms 990.02ms  86.65%

  Req/Sec   1.52k  631.56   3.48k  64.69%

 452437 requests in 30.06s, 50.91MB read

 Socket errors: connect 0, read 6, write 0, timeout 0

Requests/sec: 15051.64

 

 

配置:

worker_processes 2;

worker_rlimit_nofile 51200;

events {

  use epoll;

  worker_connections 51200;

}

 

 

 

结果:

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.81:8990/ping
Running 30s test @ http://192.168.11.81:8990/ping
  10 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   110.29ms   74.04ms   1.00s    73.43%
    Req/Sec     0.97k   235.85     3.48k    84.11%
  286701 requests in 30.07s, 44.83MB read
Requests/sec:   9533.13
Transfer/sec:      1.49MB

 

worker改为1:

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.81:8990/ping
Running 30s test @ http://192.168.11.81:8990/ping
 10 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency  96.37ms  59.48ms  1.19s  92.29%
  Req/Sec   1.08k  205.07   3.90k  77.04%
 320720 requests in 30.06s, 50.15MB read
Requests/sec: 10668.05
Transfer/sec:   1.67MB

 

 

开启sendfile: 没实质性变化

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.81:8990/ping
Running 30s test @ http://192.168.11.81:8990/ping
 10 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency  96.79ms  61.50ms  1.11s  92.40%
  Req/Sec   1.08k  194.98   3.67k  78.12%
 319743 requests in 30.07s, 49.99MB read
Requests/sec: 10633.30
Transfer/sec:   1.66MB

 

开启sendfile 和 nopush

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.81:8990/ping
Running 30s test @ http://192.168.11.81:8990/ping
 10 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency  98.76ms  76.20ms  1.18s  96.14%
  Req/Sec   1.08k  215.14   3.38k  78.24%
 320732 requests in 30.10s, 50.15MB read
Requests/sec: 10655.89
Transfer/sec:   1.67MB

 

 

开启sendfile nopush keepalived 60s

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.81:8990/ping
Running 30s test @ http://192.168.11.81:8990/ping
 10 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency  95.35ms  45.15ms  1.13s  89.35%
  Req/Sec   1.07k  194.47   1.89k  74.57%
 319669 requests in 30.10s, 47.85MB read
Requests/sec: 10621.96
Transfer/sec:   1.59MB

 

设置buffer 1

    proxy_buffers 8 8k;

Requests/sec: 10567.98
Transfer/sec:   1.58MB

 

 

    proxy_buffers 16 8k;

Requests/sec: 10627.78
Transfer/sec:   1.59MB

 

 

proxy_buffers 512 8k;

Requests/sec: 10503.37
Transfer/sec:   1.57MB

 

 

 

 

 

 

wrk在服务器81 go在 82

 

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.82:8090/ping
Running 30s test @ http://192.168.11.82:8090/ping
 10 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency  54.02ms  38.40ms 469.33ms  67.35%
  Req/Sec   1.98k  336.28   3.04k  75.44%
 587699 requests in 30.02s, 66.14MB read
Requests/sec: 19574.33
Transfer/sec:   2.20MB

 

 

wrk nginx在81 go在82 性能下降好严重

 

worker 1

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.81:8990/ping
Running 30s test @ http://192.168.11.81:8990/ping
 10 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency  205.10ms 111.88ms  1.97s  92.02%
  Req/Sec  487.99  201.67   1.48k  68.98%
 145579 requests in 30.09s, 21.79MB read
 Socket errors: connect 0, read 0, write 0, timeout 382
Requests/sec:  4837.92
Transfer/sec:  741.59KB

worker 2

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30 http://192.168.11.81:8990/ping
Running 30s test @ http://192.168.11.81:8990/ping
 10 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency  133.35ms 119.06ms  1.28s  94.00%
  Req/Sec  846.25  193.02   1.62k  68.98%
 252730 requests in 30.08s, 37.83MB read
Requests/sec:  8401.85
Transfer/sec:   1.26MB

 

 

 

我靠 nginx单核1万

[root@ycnode1 tools]# ./wrk -c 1000 -t 10 -d 30  http://192.168.11.81:8990/ping
Running 30s test @ http://192.168.11.81:8990/ping
 10 threads and 1000 connections
 Thread Stats  Avg   Stdev   Max  +/- Stdev
  Latency  50.67ms  79.71ms  1.99s  97.67%
  Req/Sec   1.12k  412.45   6.65k  79.56%
 332319 requests in 30.06s, 49.74MB read
 Socket errors: connect 0, read 8, write 428, timeout 2098
Requests/sec: 11055.09
Transfer/sec:   1.65MB

 

抓包分析:

tcpdump -i ens33 host 192.168.11.82 and port 8090 -n -O -w package.cap

wireshark分析 http 请求 Connection: 字段如果为close 则为短链接

 

 

压测结果:

1、 wrk nginx gin网站代码 在同一个服务器 和 gin网站代码单独一个服务器 区别不大 只要套接字 fd句柄够用

 

2、 nginx配置长链接:https://www.cnblogs.com/liufarui/p/11075630.html

1、 保持和client的长链接

http {

keepalive_timeout 60s;  

}

 

2、 保持和server的长链接  https://www.cnblogs.com/liufarui/p/11075630.html
upstream backend {
 server 192.168.0.1:8080 weight=1 max_fails=2 fail_timeout=30s;
 server 192.168.0.2:8080 weight=1 max_fails=2 fail_timeout=30s;
 keepalive 300; // 这个很重要!
}  
server {
  listen 8080 default_server;
  server_name "";
    
  location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;             # 设置http版本为1.1
    proxy_set_header Connection "";   # 设置Connection为长连接(默认为no)
  }
}
 我的知识盲点:
proxy_set_header Connection ""    必须设置这个,默认是close,导致依然是短链接


长链接的血案还可以参考:http://xiaorui.cc/archives/3495

3、 nginx worker 1的时候 qps=1.1万 2的时候 1.7万

 

4、proxy_set_header Connection ""

压测结果:

              total        used        free      shared  buff/cache   available
Mem:           1823         212         485           8        1125        1390
Swap:             0           0           0
 22:19:30 up  4:47,  3 users,  load average: 1.54, 0.41, 0.17
ESTABLISHED 1009   (tcp链接稳定在1000左右)
1005


5、#proxy_set_header Connection ""注释掉以后
              total        used        free      shared  buff/cache   available
Mem:           1823         207         490           8        1126        1394
Swap:             0           0           0
 22:22:04 up  4:49,  3 users,  load average: 2.32, 0.76, 0.31
CLOSE_WAIT 1
ESTABLISHED 888
FIN_WAIT1 73
FIN_WAIT2 3
TIME_WAIT 6718   (存在大量的TIME_WAIT)
927

观测脚本

[root@ycnode2 script]# cat 1.sh 
#!/bin/sh


while true
do
    free -m && uptime 
    netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'   #查看各种状态的TCP链接
    netstat -ant |grep 8090|grep ESTABLISHED|wc -l    #查看当前存在已建立的TCP链接
    sleep 1
done
<think>嗯,用户想试一下Gin和Robyn的性能对比。首先,我需要确认这两个框架的背景。Gin是用Go语言写的,而Robyn是Rust的,对吧?对,Gin作为Go的框架,以高性能著称,特别是在并发处理方面,因为Go的goroutine很强大。Robyn呢,作为新兴的Rust框架,Rust本身以安全和高性能闻名,但它的异步模型可能和Go有所不同。 用户可能想了解在不同负载下两者的表现,比如并发请求的处理能力、延迟、吞吐量等。可能需要设计一个基准试,使用相同的API端点,比如返回“Hello World”,然后用工具如wrk或hey进行试。需要注意试环境的一致性,比如同一台机器,相同的网络条件,排除其他干扰因素。 还要考虑框架的配置,比如Gin可能默认就是优化的,而Robyn可能需要调整一些参数。比如,Gin可能使用默认的路由器,而Robyn作为Rust框架,可能依赖hyper或其他库,需要确认服务器配置是否最大化性能。 试结果可能显示,Gin在处理高并发时因为Go的调度器表现更好,而Robyn在单线程性能上可能更优,但由于Rust的异步模型,可能需要更多的线程来发挥多核优势。不过实际结果可能因试用例而异,比如简单路由和复杂业务逻辑可能有不同表现。 另外,用户可能没有考虑到试的细节,比如预热次数、试持续时间、并发连接数等。这些都会影响结果。需要提醒用户多次试取平均值,避免偶然性。同时,内存占用和资源消耗也是比较的一部分,虽然用户没提,但可能也是重要的考量因素。 最后,用户可能需要结论,但应该建议他们根据具体需求选择框架。比如,如果团队熟悉Go,Gin是更优选择;若追求Rust的安全性和性能,Robyn可能更适合。同时,框架的生态和社区支持也是考虑因素,Gin更成熟,文档更多,而Robyn可能还在发展中。试</think> Gin(Go 语言框架)和 Robyn(Rust 语言框架)的性能对比需要设计一个基准试实验,通常关注**吞吐量(Requests/sec)**、**延迟(Latency)**和**资源占用**等指标。以下是一个简化的对比思路和示例: --- ### 1. **框架简介** - **Gin**(Go):基于 Go 的高性能 HTTP 框架,利用 Go 的并发模型(Goroutine)处理高并发请求。 - **Robyn**(Rust):基于 Rust 的异步 Web 框架,依赖 `tokio` 运行时,强调内存安全和零成本抽象。 --- ### 2. **试设计** #### 环境一致性 - 同一台物理机/虚拟机(避免云环境波动)。 - 禁用无关后台进程。 - 使用 `Docker` 容器化部署(可选,但需注意网络模式)。 #### 试工具 - **wrk**:轻量级 HTTP 工具,支持多线程和 Lua 脚本。 - **hey**:Go 编写的工具,适合快速试。 - **Vegeta**:分布式工具,适合复杂场景。 #### 试接口 设计一个简单 GET 接口,返回 `Hello World`,避免业务逻辑干扰: ```go // Gin 示例代码 r := gin.Default() r.GET("/", func(c *gin.Context) { c.String(200, "Hello World") }) r.Run(":3000") ``` ```rust // Robyn 示例代码 use robyn::*; fn hello(_: Request) -> Response { Response::text("Hello World") } #[tokio::main] async fn main() { let mut app = Robyn::new(); app.get("/", hello); app.start("127.0.0.1", 3000).await; } ``` --- ### 3. **基准试示例** #### 使用 `wrk` 进行(示例命令): ```bash # Gin(Go) wrk -t12 -c400 -d30s http://localhost:3000/ # 试 Robyn(Rust) wrk -t12 -c400 -d30s http://localhost:3000/ ``` #### 预期结果(仅供参考): | 框架 | 吞吐量(Requests/sec) | 平均延迟(ms) | 资源占用(CPU/Memory) | |--------|------------------------|----------------|------------------------| | Gin | ~50,000 - 100,000 | 1 - 5 | 中低(Go GC 影响) | | Robyn | ~80,000 - 150,000 | 0.5 - 3 | 极低(Rust 无 GC) | --- ### 4. **关键差异分析** 1. **语言特性**: - Go 的 Goroutine 轻量级并发模型适合高并发,但 GC 可能导致吞吐量波动。 - Rust 无 GC,内存控制更精细,但异步编程复杂度较高。 2. **框架设计**: - Gin 基于 Go 标准库 `net/http`,成熟但优化空间有限。 - Robyn 依赖 `tokio` 异步运行时,可通过线程池和事件循环优化性能。 3. **实际场景**: - 简单路由:Rust 可能占优(更底层优化)。 - 复杂业务逻辑:Go 的开发效率优势更明显。 --- ### 5. **注意事项** - **预热**:运行前先进行预热请求,避免冷启动误差。 - **参数调优**:调整框架线程池、缓冲区大小等参数(如 Robyn 的 `tokio` 线程数)。 - **结果验证**:多次试取平均值,避免偶发波动。 --- ### 6. **结论建议** - 如果追求极致性能且团队熟悉 Rust,**Robyn** 是更好选择。 - 如果需要快速开发和高并发支持,**Gin** 的生态和开发效率更优。 建议根据实际业务场景(如 I/O 密集型 vs CPU 密集型)进行针对性试。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

weixin_36013896

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值