webman压测
安装了event扩展，内核优化参数也调过了，4c8g的阿里云服务器
空跑
20次redis io，fail数量很多
同机器使用yaf 20次redis io，fail数量为0
图中是0.0.0.0改成127.0.0.1后也没变化
代码
其余是webman原来的基本没改动
2022-08-31更新
1714 3 0
3个回答
相似问题
年代过于久远，无法发表回答
代码呢？
补充了
出现失败问题出在 rand() 函数，把rand() 函数换成 $i 就好了。
确实，这是什么原因
具体原因不知道，
反正php-fpm 里使用rand()压测也会有接近一半失败。
php 自带的http server 使用rand()函数有接近一半失败。
甚至在go里用rand()函数也是压测也有接近一半失败。
以上wrk压测一切正常，感觉是ab的bug，但是不确定。
我用fpm压测的时候没事
我用fpm压测也有这个问题
代码
所以ab压测有失败请求和使用rand 函数有关系。
奇怪的是用wrk压测一切正常
用mt_rand会不会就好了？
用的1.4版本的webman么
Workerman version:4.0.40 PHP version:7.4.3 webman版本怎么看
你升级下
webman最新版本，把重新加载控制器的的配置app.controller_reuse设为true试试"workerman/webman-framework": "^1.3.14",
和版本没关系，甚至和框架没有关系，甚至我觉得和语言都没关系，ab压测的接口里有使用rand函数就有这个问题
我之前也遇到过类似的问题，我魔改了
webman的源码，让控制器每次都是重新new一个实例就没问题的。我记得当时遇到问题的原因是对另一个对象实例的属性进行赋值操作的
然后最新的
webman版本应该是1.4的版本的嗯~能解决问题就好的
和webman没关系，我在fpm下只使用以下代码，压测有一半失败
就是和使用rand ()有关系
升级了，没有变化
原来是1.3.18
性能方面呢，感觉和yaf差距不是很大啊
用yaf空跑也有8k多
这种瓶颈明显在redis啊，redis单核的，只能用一个CPU，阿里云这种配置 redis能承受的QPS最多也就几万。
webman里每秒3500请求，每个请求读写redis20次，那redis就是每秒处理7万请求，感觉redis已经极限了。
感觉一般业务一个请求读写1-2次reids就差不多了。
还有压测时要加 -k，因为浏览器都是keep-alive的，keep-alive能大幅提升性能。
感觉不是，我把redis次数20改成2，也是一样3500qps左右
并且加 -k 没有变化
但是空跑加 -k 提升明显
yaf这边redis改成2次后都跑到5000多qps
webman改完要重启或者reload才能生效
说起来在
yaf上rand()看压测的截图是不会报错的，这又不知道是什么原因的。这个要看yaf 业务逻辑里是否用了rand
我这在mac下试了下，确实如six所说，业务里使用rand会导致使用ab有一些失败请求。
php-fpm 和 webman下都有，这是一个奇怪的现象。
可以 执行2次能跑到2w多
不加-k在13000左右 加上在24000左右 yaf加不加-k都是5000多
将redis io 从2调到10后，webman在2900qps yaf在3900qps 可以确认redis无瓶颈，因为用的是阿里云redis集群
yaf webman进程分别数是？
webman是8 php-fpm配置的是300
每个请求20次redis操作这种，webman进程数可以开多一些，比如cpu的4倍甚至更多。
开到cpu的8倍可以跑到6000左右
不过要是复杂业务场景，加上数据库操作等，那么webman对比php-fpm是不是性能优势不大了呢，因为io的增加webman性能下降快
如果你的业务每个接口都是操作几十次redis或者mysql，这种业务用什么语言或者框架QPS基本都是一样的，使用webman会有提升天，但是不会有数倍的性能提升。
服务器本身的linux内核协议栈处理能力是有限的，一般云服务器linux内核协议栈处理能力也就是10-30万请求每秒。webman 6000QPS，传递到redis就是每秒12万QPS，基本上linux内核协议栈快成为瓶颈了。总结来说目前一个普通云服务器的网络请求处理能力也就10-30万/S，所以如果接口从1-2次mysql或redis请求增加到几十次，那么接口的性能快速下降是必然的。这个不管什么语言、什么框架都基本一样了。
多队列网卡的服务器，网络协议处理能力会成倍增加，这种服务器下webman的处理能力会也会翻倍增加。
了解了，谢谢