webman压测和LUMEN压测的问题

你怎么测的,webman这么低

237，这....

看起来是windows？windows下webman是单进程的，性能肯定没多进程好

可能外网测或db瓶颈也说不清，看对比就好了

Linux服务器上跑的， Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz；2核4G的配置，求问 webman为啥这么低啊

Nginx反代了

压测命令，还有反代配置看看，说不定有问题，我开始在本地反代，就是没配置好，也很低

我也发现了，只要使用nginx 压测性能就不好，单独就非常好

nginx 代理记得加 keepalive 10000;，加上后飞一样的感觉。另外也可以把nginx日志关闭，不然每次请求都写日志到磁盘肯定慢

upstream webman {
    server 127.0.0.1:8787;
    keepalive 10000;
}

keepalive 大佬 加这个的意思是啥

让nginx和webman保持长连接，否则每个请求都要和webman建立连接，然后断开，性能巨差

upstream httpds {
server 127.0.0.1:8787;

keepalive   1000;
keepalive_timeout  65; 
keepalive_requests 1000;
keepalive_time 1h;

}

啊这， 加上了，性能还是起不来，不知道是不是哪配置的还不对

重启nginx

就是这个配置项不知道配置多少合适？

keepalive 10000; 其它不用设置。可能你nginx哪里限制了请求量并发连接啥的。
压测内网压测，或者本机压测，走外网压测瓶颈在网络，啥框架都很低。

我再试试

keepalive 是保持连接，在keepalive期间返回结果后不会断开连接，后续有新连接的时候可以直接使用，避免创建链接开销；
但需要分场景使用，如果前端是腾讯云的clb那keepalive不建议开启，否则会导致一堆time_waits。
另外你真的想优化前提必须搞清楚瓶颈在哪啊。
你可以创建一个新的webman不含任何业务代码，压测一下 看 有nginx和直连的区别。如果区别不大且qps符合需求的情况下，那你就没必要去搞这个那个配置优化了，作用不大。
webman并不是能让你的业务代码加速，而是能保值你的业务代码在最快的速度运行。
比方
1、你收到了请求后执行了个sleep，非协程模式下就会导致后续请求阻塞，qps就上不去。
2、你收到了请求后没有任何阻塞通讯，那QPS基本等于你返回接收数据包大小和你机器带宽的最大值。
3、你收到请求查询mysql，注意mysql是阻塞通讯的，其实就如第一点一样的结果。
最后你想找万能狗皮膏药黏贴上去是不可能的，不同场景优化方式不同，无论哪种场景下进行优化，必须找到瓶颈所在。

另外压测结果是外网进行的吧？
平均请求时间是4.213毫秒，传输速度是731.86 kb/s
你的瓶颈是不是在网络带宽上？

单次传输大小2765bytes 加上头那些，当3kb算，
1Mbps 大概 128/3 约等于 43 qps
6Mbps 大概就 43*6 = 258
而且由于128kbs是理论速度，实际未必能达到，所以如果你是外网压测且带宽只有6~7M的情况下，结果并无任何不妥。
你的瓶颈是带宽优化配置不管用。

所以，优化后的压测结果如何？

确实是带宽的问题，带宽到瓶颈了

这个是真大佬呀，我走的是内网测试的，然后就是nginx 代理 webman的 8888 ，webman是直接访问8888端口，就是为了看一下nginx性能损耗，大佬你这qps这个是真牛，学习了

服务器配置是？优化后webman和TP压测QPS各多少？

其实真的建议用nginx/httpd之类的做一个反代，webman专注于动态请求的处理；
加了nginx有损耗但一般不会太大，如果太大的话你可以关闭nginx的日志（访问和错误）再试试。
但是如果没有了前端代理，当有大文件读取的时候，webman要读取文件发送给客户端再结束连接，这样的话容易导致阻塞。
用nginx的话静态直接nginx处理掉，动态丢给webman，能有效最大化利用webman的性能。

学习了

手册说webman发送大文件并不会阻塞
https://www.workerman.net/doc/workerman/http/response.html#%E5%8F%91%E9%80%81%E6%96%87%E4%BB%B6

手册说webman发送大文件并不会阻塞
确实并不阻塞，刚测试了开1进程下载1g文件，另外再访问也能访问正常。

@静默 我加了 keepalive 10000;还是没作用

这已经五百多倍了...