你怎么測(cè)的,webman這么低

237，這....

看起來(lái)是windows？windows下webman是單進(jìn)程的，性能肯定沒(méi)多進(jìn)程好

可能外網(wǎng)測(cè)或db瓶頸也說(shuō)不清，看對(duì)比就好了

Linux服務(wù)器上跑的， Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz；2核4G的配置，求問(wèn) webman為啥這么低啊

Nginx反代了

壓測(cè)命令，還有反代配置看看，說(shuō)不定有問(wèn)題，我開(kāi)始在本地反代，就是沒(méi)配置好，也很低

我也發(fā)現(xiàn)了，只要使用nginx 壓測(cè)性能就不好，單獨(dú)就非常好

nginx 代理記得加 keepalive 10000;，加上后飛一樣的感覺(jué)。另外也可以把nginx日志關(guān)閉，不然每次請(qǐng)求都寫(xiě)日志到磁盤(pán)肯定慢

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

keepalive 大佬 加這個(gè)的意思是啥

讓nginx和webman保持長(zhǎng)連接，否則每個(gè)請(qǐng)求都要和webman建立連接，然后斷開(kāi)，性能巨差

upstream httpds {
server 127.0.0.1:8787;

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

}

啊這， 加上了，性能還是起不來(lái)，不知道是不是哪配置的還不對(duì)

重啟nginx

就是這個(gè)配置項(xiàng)不知道配置多少合適？

keepalive 10000; 其它不用設(shè)置?？赡苣鉵ginx哪里限制了請(qǐng)求量并發(fā)連接啥的。
壓測(cè)內(nèi)網(wǎng)壓測(cè)，或者本機(jī)壓測(cè)，走外網(wǎng)壓測(cè)瓶頸在網(wǎng)絡(luò)，啥框架都很低。

我再試試

keepalive 是保持連接，在keepalive期間返回結(jié)果后不會(huì)斷開(kāi)連接，后續(xù)有新連接的時(shí)候可以直接使用，避免創(chuàng)建鏈接開(kāi)銷；
但需要分場(chǎng)景使用，如果前端是騰訊云的clb那keepalive不建議開(kāi)啟，否則會(huì)導(dǎo)致一堆time_waits。
另外你真的想優(yōu)化前提必須搞清楚瓶頸在哪啊。
你可以創(chuàng)建一個(gè)新的webman不含任何業(yè)務(wù)代碼，壓測(cè)一下 看 有nginx和直連的區(qū)別。如果區(qū)別不大且qps符合需求的情況下，那你就沒(méi)必要去搞這個(gè)那個(gè)配置優(yōu)化了，作用不大。
webman并不是能讓你的業(yè)務(wù)代碼加速，而是能保值你的業(yè)務(wù)代碼在最快的速度運(yùn)行。
比方
1、你收到了請(qǐng)求后執(zhí)行了個(gè)sleep，非協(xié)程模式下就會(huì)導(dǎo)致后續(xù)請(qǐng)求阻塞，qps就上不去。
2、你收到了請(qǐng)求后沒(méi)有任何阻塞通訊，那QPS基本等于你返回接收數(shù)據(jù)包大小和你機(jī)器帶寬的最大值。
3、你收到請(qǐng)求查詢mysql，注意mysql是阻塞通訊的，其實(shí)就如第一點(diǎn)一樣的結(jié)果。
最后你想找萬(wàn)能狗皮膏藥黏貼上去是不可能的，不同場(chǎng)景優(yōu)化方式不同，無(wú)論哪種場(chǎng)景下進(jìn)行優(yōu)化，必須找到瓶頸所在。

另外壓測(cè)結(jié)果是外網(wǎng)進(jìn)行的吧？
平均請(qǐng)求時(shí)間是4.213毫秒，傳輸速度是731.86 kb/s
你的瓶頸是不是在網(wǎng)絡(luò)帶寬上？

單次傳輸大小2765bytes 加上頭那些，當(dāng)3kb算，
1Mbps 大概 128/3 約等于 43 qps
6Mbps 大概就 43*6 = 258
而且由于128kbs是理論速度，實(shí)際未必能達(dá)到，所以如果你是外網(wǎng)壓測(cè)且?guī)捴挥?~7M的情況下，結(jié)果并無(wú)任何不妥。
你的瓶頸是帶寬優(yōu)化配置不管用。

所以，優(yōu)化后的壓測(cè)結(jié)果如何？

確實(shí)是帶寬的問(wèn)題，帶寬到瓶頸了

這個(gè)是真大佬呀，我走的是內(nèi)網(wǎng)測(cè)試的，然后就是nginx 代理 webman的 8888 ，webman是直接訪問(wèn)8888端口，就是為了看一下nginx性能損耗，大佬你這qps這個(gè)是真牛，學(xué)習(xí)了

服務(wù)器配置是？?jī)?yōu)化后webman和TP壓測(cè)QPS各多少？

其實(shí)真的建議用nginx/httpd之類的做一個(gè)反代，webman專注于動(dòng)態(tài)請(qǐng)求的處理；
加了nginx有損耗但一般不會(huì)太大，如果太大的話你可以關(guān)閉nginx的日志（訪問(wèn)和錯(cuò)誤）再試試。
但是如果沒(méi)有了前端代理，當(dāng)有大文件讀取的時(shí)候，webman要讀取文件發(fā)送給客戶端再結(jié)束連接，這樣的話容易導(dǎo)致阻塞。
用nginx的話靜態(tài)直接nginx處理掉，動(dòng)態(tài)丟給webman，能有效最大化利用webman的性能。

學(xué)習(xí)了

手冊(cè)說(shuō)webman發(fā)送大文件并不會(huì)阻塞
http://wtbis.cn/doc/workerman/http/response.html#%E5%8F%91%E9%80%81%E6%96%87%E4%BB%B6

手冊(cè)說(shuō)webman發(fā)送大文件并不會(huì)阻塞
確實(shí)并不阻塞，剛測(cè)試了開(kāi)1進(jìn)程下載1g文件，另外再訪問(wèn)也能訪問(wèn)正常。

@靜默 我加了 keepalive 10000;還是沒(méi)作用

這已經(jīng)五百多倍了...