補(bǔ)充了

出現(xiàn)失敗問題出在 rand() 函數(shù)，把rand() 函數(shù)換成 $i 就好了。

確實(shí)，這是什么原因

具體原因不知道，
反正php-fpm 里使用rand()壓測也會有接近一半失敗。
php 自帶的http server 使用rand()函數(shù)有接近一半失敗。
甚至在go里用rand()函數(shù)也是壓測也有接近一半失敗。

以上wrk壓測一切正常，感覺是ab的bug，但是不確定。

我用fpm壓測的時候沒事

我用fpm壓測也有這個問題

代碼

所以ab壓測有失敗請求和使用rand 函數(shù)有關(guān)系。
奇怪的是用wrk壓測一切正常

用mt_rand會不會就好了？

Workerman version:4.0.40 PHP version:7.4.3 webman版本怎么看

你升級下webman最新版本，把重新加載控制器的的配置app.controller_reuse設(shè)為true試試

"workerman/webman-framework": "^1.3.14",

和版本沒關(guān)系，甚至和框架沒有關(guān)系，甚至我覺得和語言都沒關(guān)系，ab壓測的接口里有使用rand函數(shù)就有這個問題

我之前也遇到過類似的問題，我魔改了webman的源碼，讓控制器每次都是重新new一個實(shí)例就沒問題的。
我記得當(dāng)時遇到問題的原因是對另一個對象實(shí)例的屬性進(jìn)行賦值操作的

然后最新的webman版本應(yīng)該是1.4的版本的

嗯~能解決問題就好的

和webman沒關(guān)系，我在fpm下只使用以下代碼，壓測有一半失敗

<?php
echo rand();

就是和使用rand ()有關(guān)系

升級了，沒有變化

原來是1.3.18

性能方面呢，感覺和yaf差距不是很大啊

用yaf空跑也有8k多

感覺不是，我把redis次數(shù)20改成2，也是一樣3500qps左右

并且加 -k 沒有變化

但是空跑加 -k 提升明顯

yaf這邊redis改成2次后都跑到5000多qps

webman改完要重啟或者reload才能生效

說起來在yaf上rand()看壓測的截圖是不會報(bào)錯的，這又不知道是什么原因的。

這個要看yaf 業(yè)務(wù)邏輯里是否用了rand

我這在mac下試了下，確實(shí)如six所說，業(yè)務(wù)里使用rand會導(dǎo)致使用ab有一些失敗請求。
php-fpm 和 webman下都有，這是一個奇怪的現(xiàn)象。

可以 執(zhí)行2次能跑到2w多

不加-k在13000左右 加上在24000左右 yaf加不加-k都是5000多

將redis io 從2調(diào)到10后，webman在2900qps yaf在3900qps 可以確認(rèn)redis無瓶頸，因?yàn)橛玫氖前⒗镌苧edis集群

yaf webman進(jìn)程分別數(shù)是？

webman是8 php-fpm配置的是300

每個請求20次redis操作這種，webman進(jìn)程數(shù)可以開多一些，比如cpu的4倍甚至更多。

開到cpu的8倍可以跑到6000左右

不過要是復(fù)雜業(yè)務(wù)場景，加上數(shù)據(jù)庫操作等，那么webman對比php-fpm是不是性能優(yōu)勢不大了呢，因?yàn)閕o的增加webman性能下降快

如果你的業(yè)務(wù)每個接口都是操作幾十次redis或者mysql，這種業(yè)務(wù)用什么語言或者框架QPS基本都是一樣的，使用webman會有提升天，但是不會有數(shù)倍的性能提升。

服務(wù)器本身的linux內(nèi)核協(xié)議棧處理能力是有限的，一般云服務(wù)器linux內(nèi)核協(xié)議棧處理能力也就是10-30萬請求每秒。webman 6000QPS，傳遞到redis就是每秒12萬QPS，基本上linux內(nèi)核協(xié)議?？斐蔀槠款i了?？偨Y(jié)來說目前一個普通云服務(wù)器的網(wǎng)絡(luò)請求處理能力也就10-30萬/S，所以如果接口從1-2次mysql或redis請求增加到幾十次，那么接口的性能快速下降是必然的。這個不管什么語言、什么框架都基本一樣了。

多隊(duì)列網(wǎng)卡的服務(wù)器，網(wǎng)絡(luò)協(xié)議處理能力會成倍增加，這種服務(wù)器下webman的處理能力會也會翻倍增加。

了解了，謝謝