我用PHP寫的接口，在單機(jī)版的服務(wù)器下,單用戶調(diào)用,也就是說機(jī)器的并發(fā)用戶數(shù)為1的情況下，該接口的響應(yīng)時(shí)間為100ms
但是用壓力工具測(cè)試,壓到并發(fā)量為220人的時(shí)候,接口響應(yīng)時(shí)間最長(zhǎng)長(zhǎng)達(dá)5s最短是3s 平均下來(lái)也有好幾秒,這個(gè)數(shù)據(jù)完全和單次調(diào)用差距懸殊,這樣的結(jié)果是不是說明接口代碼的性能是很好,但是并發(fā)量一旦上來(lái)的時(shí)間,就性能變的很差,是不是就說明是服務(wù)器的性能差，而不是接口程序性能差？問題到底出在那？
3 回答
吃雞游戲
TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超7個(gè)贊
你想想一下一條馬路可以同時(shí)過十輛車，現(xiàn)在突然同時(shí)要過100輛，而且這個(gè)車都爭(zhēng)搶著要過去，是不是很容易堵車，一堵車大家都慢了。
很對(duì)秒殺系統(tǒng)會(huì)有類似的業(yè)務(wù)場(chǎng)景，引入隊(duì)列服務(wù)排隊(duì)處理請(qǐng)求是一個(gè)通用的方法，這種辦法就好像火車站進(jìn)站口彎來(lái)彎去的排隊(duì)通道。
慕妹3146593
TA貢獻(xiàn)1820條經(jīng)驗(yàn) 獲得超9個(gè)贊
一般情況下，服務(wù)器的瓶頸是不會(huì)在220人的時(shí)候體現(xiàn)的。接口響應(yīng)時(shí)間長(zhǎng)，一個(gè)是檢查你的php配置，是否支持多連接，第二個(gè)就得看你的邏輯代碼，是否在并發(fā)下存在連接爭(zhēng)用的情況
眼眸繁星
TA貢獻(xiàn)1873條經(jīng)驗(yàn) 獲得超9個(gè)贊
一般來(lái)說不是程序的問題。檢查下服務(wù)器的php-fpm配置。
另外。php不適合寫接口，同樣的配置nodejs比php-fpm并發(fā)高很多
- 3 回答
- 0 關(guān)注
- 502 瀏覽
添加回答
舉報(bào)
0/150
提交
取消