2011-03-05 60 views
0

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

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

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

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

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

我服務的主要移動用戶。

謝謝!

回答

0

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

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

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

+0

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

1

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

+0

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

+0

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

0

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

+1

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

0

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