webman压测和LUMEN压测的问题

Mr_Deng


左图:通过nginx反代压测webman,该接口有一个数据库查询
右图:我司使用的lumen框架,同样nginx虚拟域名访问

环境:CPU Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz 16G
wsl,LNMP包,未做内核优化

麻烦问下,lumne本就如此不堪,还是其它原因呢?

2113 4 0
4个回答

xianrenqh

啊这,我也测试了一下, 一个是webman的, 一个是thinkphp6的:

webman

thinkphp6

  • Mr_Deng 2022-07-01

    你怎么测的,webman这么低

  • Tinywan 2022-07-01

    237,这....

  • 静默 2022-07-02

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

  • MarkGo 2022-07-02

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

  • xianrenqh 2022-07-04

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

  • xianrenqh 2022-07-04

    Nginx反代了

  • Mr_Deng 2022-07-04

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

  • tanhongbin 2022-07-06

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

  • 静默 2022-07-06

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

    upstream webman {
        server 127.0.0.1:8787;
        keepalive 10000;
    }
  • 晚安。 2022-07-06

    keepalive 大佬 加这个的意思是啥

  • 静默 2022-07-06

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

  • tanhongbin 2022-07-07

    upstream httpds {
    server 127.0.0.1:8787;

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

    }

  • xianrenqh 2022-07-07

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

  • tanhongbin 2022-07-07

    重启nginx

  • tanhongbin 2022-07-07

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

  • 静默 2022-07-07

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

  • tanhongbin 2022-07-07

    我再试试

  • MarkGo 2022-07-07

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

  • MarkGo 2022-07-07

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

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

  • 静默 2022-07-07

    所以,优化后的压测结果如何?

  • xianrenqh 2022-07-07

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

  • tanhongbin 2022-07-07

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

  • 静默 2022-07-07

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

  • MarkGo 2022-07-07

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

  • 842461193 2022-07-07

    学习了

  • MarkGo 2022-07-07

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

  • owenzhang 2022-07-18

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

静默

lumen开启opcache了?开启opcache试下。
基于php-fpm的框架性能都很低,和webman这种没法比,webman 并发比laravel lumen这种高十倍甚至几十倍都很正常。

  • 暂无评论
xianrenqh

  • 暂无评论
lavaman

一个常驻内存,一个基于php-fpm 有百倍的差异很正常

年代过于久远,无法发表回答
🔝