php Mcrypt響應慢的原因解決備註

上午的時候, 有同事來找我說上週新上線的乙個使用mcrypt的指令碼, 響應非常慢, 但是伺服器的各項指標都正常, 不知道是什麼原因.

經過了解, 乙個簡單的可重現的指令碼如下:

當20個併發請求這個指令碼的時候, 我們會發現apache的響應時間急劇上公升…

考慮到這個問題可能具有一定的普遍性, 於是我想我還是寫一篇文章來介紹下這個坑, 防止後來人再次踩到.

php的mcrypt擴充套件的mcrypt_create_iv, 如果你不指定的話, 預設使用/dev/random(linux上), 作為隨機數產生器. (也許有的同學已經知道原因了, 呵呵, 那就可以略過了)

這裡的問題就在於/dev/random, 它的random pool依賴於系統的中斷來產生. 當系統的中斷數不足, 不夠產生足夠的隨機數, 那麼嘗試讀取的程序就會等待, 也就是會hang住, 來看乙個簡單的例子:

當你的機器不夠繁忙的時候, 你會發現, 輸出的速度很慢, 偶爾還有停頓…

問題就出在了這裡, 當你20個併發請求的時候, 伺服器的中斷數不夠, 產生不了足夠的隨機數給mcrypt, 繼而導致php程序等待, 從而表現出, 響應時間變長

解決的辦法就是, 改用/dev/urandom, /dev/urandom也是乙個產生隨機數的裝置, 但是它不依賴於系統中斷.

修改後測試, 問題解決, 一切正常….

weibo上sae的同學 @胥昕ops提供了乙個不需要修改php**的解決方案:

胥昕ops: sae 二三月份遇到的這個問題，一條命令秒殺此問題，

用urandom的結果填充entropy池子，這樣既保證了entropy池的數量，也保證了隨機性

然而, 為什麼php使用/dev/random作為預設, 這是因為理論上來說, /dev/urandom在一定的情況下, 可能會被可**(參看: /dev/random), 所以一般上認為, /dev/urandom不如/dev/random安全.