经过再次重写之后，性能已经是 Nginx 的 1.76 倍

[herozem]

guard 是一个高性能熔断器+代理

RT。上周末发了 https://www.v2ex.com/t/424778#reply14

然后最近几天一直在迭代。从把锁丢掉，到重写 radix tree 和融合统计模块，到把 net/http 换成 fasthttp， 在我的笔记本上，QPS 从 7k 左右到了 22k，对比 Nginx，性能从 Nginx 的 0.55 到 1.76 倍。改写的过程非常 累，因为写好的测试需要一遍一遍推翻重写。数据结构也需要仔细设计。hot-path 需要非常注意避免性能问题。

但是改写的过程也学到了很多东西，例如怎么去优化 Go 的性能，期间尝试了 prefork 模式，减少锁，缩小临界区，使用 CAS，调整 GOGC参数 等等等等。

项目链接：

https://github.com/jiajunhuang/guard

核心模块的设计基本上已经稳定了，接下来要做的事情是：

• 改写 time.Now，使用自己维护的粗略时间以减少性能损耗
• 将 radix tree 中的 path 和索引改为[]byte，以便进一步降低 string 和[]byte 之间转换的损耗
• 嵌入 viper，以便提供动态配置更改的功能
• graceful restart

欢迎大家关注和 star，以及提出意见，建议和 PR ！

[sagaxu]

能公布测试的细节吗？ i5-3210M 是双核不是四核，nginx cpu affinity 怎么设置的？


@herozem GC 卡顿都不敢保证 < 1ms，只能实现软高精度时间

[assad]

要是能取代 nginx 就牛逼了

[herozem]

@gouchaoer
@est
@sagaxu
@assad 开发的时候都是用 wrk 粗略压测，CPU 是物理双核虚拟四核。GOMAXPROCS 默认是虚拟核心数（我 1.9 ），Nginx worker 是 4。我今天好好的做一次专业一些的压测，请大家耐心等候。

[herozem]

@assad 没准备取代，设计的时候就没想过要取代。理想的方式是躲在 Nginx 之后作为一个中间件。因为 Nginx 非常的成熟非常的专业，第二 fasthttp 没有完全遵循 HTTP RFC，第三 guard 并不准备增加 Nginx 那么多可更改的配置和“脚本支持”。

理想的方式是 Nginx 处理完规则，然后打到 guard，然后后面是应用

[sagaxu]

@herozem nginx 后面的中间件生存空间有限，一不留神就给 nginx 补丁或者模块取代了

[herozem]

@sagaxu :joy: 那可能是命数。。。要替代 Nginx，有太多太多的功能要开发和完善。其实这个项目起初也是为内网的一个需求设计的，不过目前还不够成熟所以还没有上生产。所以设计之初就是躲在 Nginx 后面工作的 (地下工作者

[KgM4gLtF0shViDH3]

跟 caddy 一样吗

[herozem]

@bestkayle 我们不一样 :)

[VYSE]

@zhujinliang #13 如果只是对 cpu 运转时间做比较操作,利用 time.Now()的 monotonic clock reading 精度是最高, 读的来源实际就是 cpu 开机至今的 cycle 数, 某些打印操作会导致读自然时间,这就依赖系统时间 api 误差(内核其实只是周期性 update 时间戳)

[zhicheng]

一般用非 C/C++ 写的基础软的生命周期：
1, 写了个 demo 发现性能能接近 nginx，觉得有戏。
2, 经过一番优化，性能已经完全超过 nginx，觉得非常有戏。
3, 随着功能的完善，性能逐渐下降，完全无法匹敌 nginx。
4, 继续经过一翻优化，性能勉强达到 nginx 水平，但代码已经不像高级语言，后悔没有直接用 C。
5, 用 C 重写了一个 lib，给上层语言调用，性能很好，但 Bug 很多，很容易 Crash。
6, 发现有人写了个 nginx 插件，很好用，项目被抛弃。

[feverzsj]

这是再测 fasthttp 吧

[herozem]

@feverzsj 绝大部分性能确实来自 fasthttp，但是也离不开其他组件的支持。


@zhicheng 并不想取代 Nginx。在此只是压测时做对比和参照。Nginx 作为我最喜欢的软件之一，怎么能取代呢

[zhicheng]

@herozem
并不是说要取代 nginx，而是不要把重点放在性能优化上，把重点放到需求上，性能只是一个功能。如果 “非性能” 部分的需求巨大，到时候哪怕再用 C 写一个，也不是问题。

[m939594960]

benchmark nginx 的配置没关 log 啊

[0ZXYDDu796nVCFxq]

我优化一下 nginx 对比一下
nginx 单进程，CPU 是虚拟机的 i5-4590 CPU @ 3.30GHz

测试结果：
1. 请求 nginx 默认首页
wrk --latency -c 2048 -d 30 -t 2 http://127.0.0.1:32645/index.html

Running 30s test @ http://127.0.0.1:32645/index.html
2 threads and 2048 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 16.54ms 91.31ms 1.97s 96.19%
Req/Sec 35.86k 14.09k 81.79k 66.50%
Latency Distribution
50% 1.55ms
75% 2.86ms
90% 4.47ms
99% 406.41ms
2140722 requests in 30.08s, 1.69GB read
Socket errors: connect 1029, read 98, write 0, timeout 564
Requests/sec: 71172.27
Transfer/sec: 57.69MB

2. 请求 nginx 直接 return 的 hello world
wrk --latency -c 1000 -d 30 -t 2 http://127.0.0.1:32645/hello

Running 30s test @ http://127.0.0.1:32645/hello
2 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 43.54ms 182.36ms 1.83s 94.93%
Req/Sec 83.45k 12.45k 128.69k 74.58%
Latency Distribution
50% 0.99ms
75% 1.75ms
90% 50.98ms
99% 1.12s
4975705 requests in 30.04s, 749.51MB read
Socket errors: connect 0, read 21, write 0, timeout 352
Requests/sec: 165662.55
Transfer/sec: 24.95MB


测试配置和脚本见 github：
https://gist.github.com/travislee8964/76e57bf013923eb9efe9f5cc6c5f9ce9

[0ZXYDDu796nVCFxq]

网络和内核没经过优化，所以有一些 socket errors
优化后性能应该还能有提升

[0915240]

强烈关注。。

[herozem]

@zhicheng 嗯，这也是一种观点。过早优化是万恶之源没错，但是性能也是一个重要的功能。软件开发的过程并非要剑走偏锋，例如追着性能不放，而是在权衡之下取一个比较好的点。目前这边也没有完全追逐性能

[herozem]

@gstqc 如果可以的话，最好能把 guard 的测试一起贴上去。这样方便对比，哈哈~

[wzy44944]

压完看下火焰图更准确些，不然很容易被一些无所谓的配置掩盖掉，比如 nginx 的 accept 锁要去掉，reuseport 打开，而且随机请求压才有意义，只压一个请求会有内存缓存，这点和配置也有关系。既然不是替代 nginx 的，就不要和 nginx 对比了吧，和做同一个业务的软件对比才好