PHP執行時間：決定執行速度時要考慮的因素

由於我所有的請求都是通過一個索引腳本進行的，因此我試圖計算所有請求的響應時間。PHP執行時間：決定執行速度時要考慮的因素

它只是開始時間（腳本開始）和結束時間（腳本結束）之間的差異。

當我在memcached上緩存我的數據並且用戶都使用memcached進行服務。

我通常得到的迴應時間不到一秒鐘，但有時會出現超過一秒的奇怪秒殺。最糟糕的情況可能會高達200多秒。

我想知道，如果移動用戶有一個緩慢的連接，這是否反映了我的迴應時間？

我服務的主要移動用戶。

謝謝！

2011-03-05 lxcid

如果您使用PHP測量（它聽起來像是你），那就是在服務器端生成頁面所需的時間，而不是下載所需的時間。

在整個頁面中放置定時器，並嘗試將其分解爲導致200多秒的巨大延遲的部分。

你甚至可以添加一個小腳本，它會通過電子郵件發送每個部分加載時間的詳細信息，如果它經常不足以自己查看。

2011-03-05 06:45:13

感謝您的回答。我猜測可能是EC2碰巧選擇了特定的php執行，並決定偏向它。由於約90％以上的請求不到一秒鐘。我會繼續監測情況。：）謝謝！ – lxcid 2011-03-06 18:44:43

不，這是您的腳本的運行時。它不會計算用戶的延遲，這是底層Web服務器擔心的問題。腳本中的某些內容需要很長時間。我建議你分析你的腳本來找到它是什麼。 Xdebug是一個很好的方法。

2011-03-05 06:44:10 deceze

謝謝！對於快速回答傢伙。 :)我希望我能投票給你們。 – lxcid 2011-03-06 18:45:09

@lxcid其實，你*可以*。你也應該接受一個答案。 – deceze 2011-03-06 22:56:59

可能是因爲客戶端非常緩慢地下載結果，腳本無法完成。如果您不使用像nginx這樣的前端服務器，首先要做的就是嘗試一下。

2011-03-05 07:03:20 amartynov

不正確。在收到請求之前，腳本不會啓動，並且無論客戶端下載多長時間，腳本都會完全生成。儘管Nginx對緩存有所幫助，但OP仍然需要弄清楚問題的根源。我接受這個解釋的唯一方法是如果用戶正在上傳文件，然後nginx甚至不會幫助。 – 2011-03-05 23:43:36

有人已經提到xdebug，但通常你不想在生產中運行xdebug。我建議使用xhprof來分析開發/分期/製作頁面。您可以有條件地打開xhprof，這使得運行生產變得非常簡單。

2011-12-16 19:16:05

回答