先感謝社區(qū)各位朋友熱心的幫助,上個(gè)帖子關(guān)于消費(fèi)券的問題給了我很大的啟發(fā)。
上一個(gè)帖子:http://www.wtbis.cn/q/8581
目前我在小范圍用webman做應(yīng)用,觀察,等都成熟了(我自己技術(shù)使用)再切換,就和大神(@nitron)說的一樣,線上項(xiàng)目要謹(jǐn)慎,還是先從硬件和流程改進(jìn)吧。
今天做了一個(gè)小的程序,剛發(fā)布,剛才看控制臺的status ,如下圖
我這個(gè)是默認(rèn)的啟動(dòng),我看processes是17,這個(gè)是不是和cpu的核數(shù)有關(guān)系那,我現(xiàn)在是8核的,因?yàn)橛袃蓚€(gè)worker,所以是8*2=16?,就是說一個(gè)monitor和16個(gè)webman進(jìn)程。
問題有點(diǎn)小白,見諒哈,哈哈哈哈哈哈哈~~~~
是的,webman 里面默認(rèn)是開啟 c 數(shù)量二倍的數(shù)量。如果是高i/o的你可以手動(dòng)調(diào)的更高,如果是高計(jì)算的,也可以適當(dāng)調(diào)低一點(diǎn)。
是的,之前沒有升級編寫過,今天上線個(gè)小項(xiàng)目,還是能學(xué)到不少的,不過我也不知道我的是高io還是高計(jì)算的,人不多,估計(jì)默認(rèn)的就能應(yīng)付了。
現(xiàn)在觀察一切安好。
其實(shí)就是一個(gè)請求中,php執(zhí)行占用的時(shí)間和與其他非php交互的時(shí)間哪個(gè)占用時(shí)間多。高i/o的調(diào)高worker數(shù)量是為了不要讓webman的worker都在等待 db/redis/或者遠(yuǎn)程調(diào)用的結(jié)果。這樣cpu利用率比較低。時(shí)間都花在等待上了,可以適當(dāng)調(diào)高worker數(shù)量。如果接口中的判斷,或者計(jì)算相關(guān)邏輯比較多,占接口響應(yīng)時(shí)間比較大的,但是查詢很快的話,就要適當(dāng)降低worker數(shù)量(不要小于cpu核心數(shù),小于的話,就會(huì)有核不被利用了),目的是為了減少系統(tǒng)在多個(gè)worker上的切換。減少并發(fā)時(shí)任務(wù)切換的時(shí)間占比,讓cpu盡可能的用在真正的邏輯上。 具體還是要看場景,不過一般接口的話,默認(rèn)為cpu的二倍沒什么問題
不是什么大神,太抬舉我了,我的建議能幫到你我也很高興。
說的其實(shí)不是什么比較有技術(shù)含量的提議,主要還是個(gè)人的經(jīng)歷
很多年前第一次升職,年輕啊,新官上任三把火,想馬上干出點(diǎn)成績。正好當(dāng)時(shí)有個(gè)新的業(yè)務(wù),想著正好啊,跟各路大神請教之后,決定換了個(gè)技術(shù)棧,卻完全沒有考慮當(dāng)時(shí)團(tuán)隊(duì)的狀況和其他一些技術(shù)之外的問題。
當(dāng)然之后的結(jié)果估計(jì)大家都能猜到,項(xiàng)目延期,上線后問題不斷,團(tuán)隊(duì)的氣氛也差了不少,客戶也有不少怨言,上線磕磕碰碰快兩個(gè)月才完全穩(wěn)定,真感謝當(dāng)時(shí)的領(lǐng)導(dǎo)一直護(hù)著我,不然我估計(jì)要收拾東西滾蛋了[/嘆氣]。
大家的意見你只能做參考,因?yàn)樗酥皇钦f而不用實(shí)際執(zhí)行,他們初心是好的,都希望能幫你解決問題,但最終要落實(shí)還是你。你那個(gè)提問里,群友們的熱心回復(fù),我感覺看到了當(dāng)年的自己,怕你頭腦一熱就上了,就多提了一嘴。
很多問題,實(shí)際上不是什么技術(shù)問題,而是如何權(quán)衡的問題,總結(jié)起來就4個(gè)字“量力而為”。未來如果換了Webman,也希望你能在這里多分享。
嗯嗯是的呀,我現(xiàn)在也是那個(gè)消費(fèi)券項(xiàng)目沒有替換技術(shù)棧,目前一些小的項(xiàng)目用了webman(本月用了2個(gè)),會(huì)都發(fā)布出來并分享一些小的體會(huì)和經(jīng)驗(yàn)。
我這邊客戶到時(shí)支持替換,不過都知道,除了事情肯定還是乙方的責(zé)任,哈哈。
是要慎重。