今天發(fā)現(xiàn)公司出現(xiàn)一個問題
index是個耗時任務(wù),請求的時候一直阻塞在那里
接下來第二個請求到來的時候也阻塞在那里
這是為什么呢?
先來分析下原因
剛開始我以為是fpm的問題,請求交給nginx后,通過fpm轉(zhuǎn)交給worker進(jìn)程處理的時候阻塞,應(yīng)該是不會影響下一個請求的.因為兩個請求由不同的worker進(jìn)程處理.
那是什么原因呢?
查了下資料,發(fā)現(xiàn)每個請求進(jìn)來都會啟用session_start(),session嗎,大家都知道.
那是怎么阻塞后續(xù)的請求呢?
原來seesion_start()的時候,會去服務(wù)器上找session文件.讀取里面保存的session信息.
同學(xué)們注意了,session默認(rèn)保存的是文件.意味著什么,讀取的時候會有文件鎖.
那么原因就很明顯了
第一個請求進(jìn)來,占有session文件,耗時處理.
第二個請求進(jìn)來,發(fā)現(xiàn)session文件被占有,就阻塞等待.
結(jié)果也是跟我預(yù)計的一樣.
當(dāng)?shù)谝粋€請求返回的時候,后續(xù)請求立馬執(zhí)行了.
那可以怎么樣規(guī)避這樣的問題呢?
- 將session存到redis這樣的內(nèi)存緩存中;
- session讀取完之后立馬釋放
session_write_close();
注意的地方:
之前在本地測試時候,發(fā)現(xiàn)不管設(shè)置都是阻塞的,一度以為這個函數(shù)沒什么用.后來思考了下,斷定是我本地的phpstudy配置的問題.估計phpstudy就啟動了一個進(jìn)程來處理所有請求,所以導(dǎo)致了阻塞.
