如何減少服務器「等待」時間？

我想優化我的網站的速度，我在pingdom.com上使用了很棒的工具。目前，加載頁面花費的時間超過50％是「等待」時間，如下面的屏幕截圖所示。我能做些什麼來減少這種情況？此外，這個數字有多典型？有沒有基準呢？謝謝！如何減少服務器「等待」時間？

high server wait time

編輯： 好吧..讓我澄清一些事情。沒有服務器端腳本或數據庫調用正在進行。只是HTML，CSS，JS和圖像。我已經做了一些事情，比如將js推到body標籤的末尾以獲得並行下載。我知道main.html和templates.html通過在js.js下載之後同步完成而增加了總體等待時間，但這不是問題。對於每個請求有多少「等待」時間，我只是感到驚訝。服務器距離是否影響到此？如何在共享服務器上工作，會影響等待時間嗎？有沒有什麼瑕疵可以補救這些問題？

enter image description here

來源

2012-06-07 alnafie

這不是一個真正的編程相關問題。嘗試http://serverfault.com/ – Gerrat

-1

這是服務器的問題。據Pingdom的「網絡瀏覽器正在等待來自服務器的數據」是什麼定義「等待」的時間。

從JavaScript或代碼的最後解決這個問題的方法並不多。

來源

2012-06-07 19:40:52 MattK311

這不是等待時間。 – ddlshack

等待時間（也稱爲time to first byte）是服務器從連接啓動時發送第一個字節需要多長時間。如果這很高，這意味着您的服務器在發送頁面之前需要做很多工作才能呈現頁面。我們需要了解您的網站在呈現網頁時所做的更多信息。

來源

2012-06-07 19:47:45 ddlshack

很好，這也可能與您的HDD/RAID上的訪問時間有關。我的SSD服務器的第一個字節（TTFB）的時間較短，而且網站確實加載速度更快。 – Thom

服務器可能需要做很多工作，但它可能同樣需要做很多等待。在知道應該爲最大的勝利應付什麼之前，你需要分解那段時間。 – Jason

如果您有多個服務器請求正在等待該頁面，則可以確保這些服務器請求是以並行方式異步發送的，以便對它們進行序列化。

獲取多個請求的最慢可能方式是發送一個請求，等待它的響應，發送下一個請求，等待它的響應等等。通常以更快的速度異步發送所有請求，然後處理所有請求他們到達時的反應。這將總等待時間縮短爲任何單個請求的最長等待時間，而不是所有請求的累積等待時間。

如果您只是提出一個請求，那麼您在客戶端可以做的所有事情是確保請求在頁面加載順序中儘早發送到服務器，以便其他部分的頁面可以在請求正在處理的同時完成他們的業務，從而更快地開始初始請求（因此更快完成）。

來源

2012-06-07 20:06:27 jfriend00

在Apache中最常見的原因是使用DNS反向查找。這意味着服務器每次發出請求時都會嘗試弄清楚您的機器名稱。這可能需要幾秒鐘的時間，這就解釋了爲什麼你需要很長的等待時間，然後是很快的負載，因爲這個問題不是帶寬問題。

其明顯的解決方案是在/etc/httpd/conf/httpd.conf中

HostnameLookups Off

禁用hostnamelookup但是......這通常是不夠的。事實是，在許多情況下，即使您禁用了主機名查找，apache仍會進行反向查找，因此您需要仔細查看apache配置的每一行。特別是LOGS最常見的原因之一。默認情況下，在許多Red Hat - Centos安裝中，日誌格式包括代表「hostname」的％h，並且需要apache進行反向查找。你可以在這裏看到：

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined 
LogFormat "%h %l %u %t \"%r\" %>s %b" common

你應該改變這些％h爲％a來解決這個問題。

來源

2012-12-02 19:29:43

感謝隊友..任何來源推薦這樣的提示？ –

@ÜnsalKorkmaz在這裏你去http://httpd.apache.org/docs/2.2/mod/mod_log_config.html 編輯：對不起，我誤讀。以爲你說過「任何資源推薦」。 – ConnectedSystems

'''HostnameLookups'''已關閉，但'''LogFormat''是罪魁禍首。通過將％h更改爲％a，我獲得了50％的提升。 – Birla

TTFB直接受瀏覽器和服務器之間「物理」距離的影響。 CDN代理是縮短所述距離的最佳方式。這與本地緩存功能相結合，將通過從最近的POP（位置放置點）位置加載緩存對象來幫助提供更快速的響應。

效果將取決於用戶的地理位置和CDN的傳播。不過，你可以預期significant improvement,50％-70％或更多。

根據經驗，我看到90％的內容被緩存，並直接從位於另一個大陸的代理服務器提供，這些代理服務器位於全球另一端。

來源

2013-08-12 18:56:05

如何減少服務器「等待」時間？

回答

相關問題