@u20237 后端很简单 不解析协议，在我的仓库 reactor 的 example 目录中，qps 主要看机器配置

@e7 咱想复杂了，就讨论反向代理这块，语言和技术发展方向暂避不谈

@jeesk 欢迎哦，有问题随时找我

@e7
ET 模式不是性能的标配，读的话不管哪种模式都是尽量一次性读完，减少 syscall 次数，而且有了这个前提 大部分情况 ET 模式反而会浪费一次 syscall ，因为必须判断 ret=-1 && errno = EAGAIN ，而在水平模式下，读出来的数量小于你的 buf 长度 就可以了，不需要再尝试一次

个人感觉它适合在 write 方面，减少 epoll_ctl 的调用

欢迎讨论

@tool2d 哈哈，开心就好

@lesismal 我标题做了定语啊：反向代理。

而且我项目首页就写了 “Just a reverse proxy service”
nginx 是功能很多，但是做为反向代理，大部分功能不需要，非要比功能多不多干吗？不是还有 haproxy 做对比吗

“应该不需要改太多”，想当然了吧，部分的栈内存要换成堆内存，还要增加一次系统调用查询结果综合提升非常有限。再有，程序还没有到过滤优化的阶段。

@rrfeng 来呀，我接受你的挑战，搞不定你就吃粑粑

@hankai17 我的 backend server 就不解析协议，qps 直接就是 11w ，我上边贴了

@lesismal 又看到你，
1. 虽然解析过滤不完整，但是我也走了完整的循环，只是没有过滤所有 header 而已，但这正常单一功能的优势（仅提供反向代理功能）
2. splice 是限于 pipe 。ZEROCOPY 是异步的增加复杂度了，buf 机制也要改，整体提升非常有限
3. 其他选项，根本不会触发啊，比如 gzip：我发的内容很短"hello world"。
4. 我声明了啊，本来就是个实验性项目，功能不完整

只是证明一种可行性，数据要辩证的分析

@Pythoner666666 是的用个计数器也可以达到效果，但这样不就是更通用一点嘛，

#81 又鸡巴贴错了，抱歉
```
wrk -t 2 -c 100 -d 10s -H 'Connection: keep-alive' http://10.146.0.2:8082/xxx
Running 10s test @ http://10.146.0.2:8082/xxx
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 8.30ms 12.55ms 116.67ms 86.81%
Req/Sec 12.44k 8.43k 23.21k 55.50%
247471 requests in 10.00s, 38.00MB read
Requests/sec: 24736.85
Transfer/sec: 3.80MB
```

抱歉，搞错了， #80 是在 nignx 主机上测试的
在 wrk 的主机上测试，数据没那么好，
wrk -t 2 -c 100 -d 20s http://10.146.0.2:8082/xxx
Running 20s test @ http://10.146.0.2:8082/xxx
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 12.87ms 18.90ms 172.84ms 88.01%
Req/Sec 7.64k 6.23k 25.84k 74.00%
304115 requests in 20.01s, 46.69MB read
Requests/sec: 15195.51
Transfer/sec: 2.33MB

铁子们，搞定了 @xiaooloong @learningman @picone

wrk -t 2 -c 100 -d 10s -H 'Connection: keep-alive' http://10.146.0.2:8082/xxx
Running 10s test @ http://10.146.0.2:8082/xxx
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 3.99ms 1.16ms 28.64ms 81.99%
Req/Sec 12.61k 526.49 13.93k 78.50%
250914 requests in 10.00s, 38.52MB read
Requests/sec: 25083.91
Transfer/sec: 3.85MB


wrk 是不带 connection header 的，nginx 默认就按 close 处理了。

@fyxtc 感谢回复，就是要打破所谓的“圈内常识”，我从来都没说我吹 NB ，我只是写了一个 3 倍（也是有数据支撑的，而且我也声明了，我实现的功能不完全）数据只供参考，我相信等功能完善了也不会降低 2 倍的性能差。至于 nginx 的问题，完全可以忽略，参考 haproxy 的就够了。nginx 的配置我确实没搞定，也研究过，也试了上边热心网友提供的配置，都不行。

@hankai17 这个 fd 数量不影响，默认 ulimit -n 就是 1024 ，实际并发链接数 wrk 也才 100 ，

@ZSeptember 也不一定，有些人的实现思路就够 gopher ，自己实现一套条件变量 + queue ，我是觉得没必要，go 天生就带这些东西。另外，你说的优雅关闭 是指关闭 pool 吗？我是觉得没必要，本来 go pool 就不是很必须，再加上一个动态的 pool 就更没必要了

@kneo 是的，自己造的轮子肯定是为了解决自己生产环境的问题，不用考虑通用性

@hankai17 嗯 感谢，我研究研究 backend

@encro 测试数据就是个结果啊，我也声明了，程序还不完善，但要懂其底层原理的人应该明白，补上缺少的那些功能并不会带来 2 倍的性能差异，数据只是参考，不是定性，每个人通过数据分析到的结果是不一样的。