我正在研究一個Web應用程序，並且我正在使用輪詢方法來檢查是否需要更新。這些輪詢請求每隔1或2秒發生一次。如果不需要更新（在這種情況下返回一個空的響應）和大約10 KB（它是內容本身的大小），則響應的大小爲240個字節。我的問題是，由於它每秒至少返回240 B，有沒有辦法通過將邊界推得更多來優化這個響應？減少響應大小
當我檢查響應的內容時，我看到50個字節對我來說很重要（會話ID和狀態碼）。但是，頭文件中有一些信息，例如連接類型，超時和內容類型。對於這種類型的每個請求，這些設置都是相同的（即它總是要求內容類型爲：「text/html; carset = utf-8」）。那麼，我可以在客戶端假設這些設置，並阻止服務器發送這些頭信息嗎？
我在服務器端使用django和jQuery發送ajax請求的方式。此外，任何類型的推送技術現在都不存在問題。
這種問題的一個解決方案是「長輪詢」。輪詢客戶端將發送請求，Web服務器將檢查是否有更新。如果沒有，網絡服務器會休眠一兩秒鐘，然後再次循環檢查，而不發送響應。只要此循環看到更新，它就會發送一個響應。對於客戶端Web瀏覽器來說，它看起來像服務器擁塞並需要很長時間才能響應，但實際上相關數據正在被及時傳輸，並且「無數據」響應僅僅被跳過。
我建議在循環中添加一個超時 - 比如30或60秒 - 之後，網絡服務器將像往常一樣回覆「無數據」。即使只有30秒的週期，也會將空載響應負載減少15-30倍。
警告：我已閱讀過這種實現，但我沒有嘗試過。您需要測試與各種Web瀏覽器的兼容性，以確保這種相當不標準的方法不會在客戶端造成問題。
它確實加起來，但沒有你想象的那麼多。如果每秒調查一整小時，則只能使用864K，比普通網頁所需的緩衝區大一些。即使你做了一整天，你也在談論大約20M。也許如果你是Twitter這樣的人，你可能需要關注這一點，但是我懷疑你會得到任何接近它的流量，因爲這實際上是有問題的。儘管如此，您當然也可以自定義請求的標頭，但是如果對客戶端產生的任何影響將成爲測試的問題會發生什麼。有些標題可能會被刪除，但其他標題可能會讓您感到意外，並且它在技術上也可能會因瀏覽器而異。
我檢查了長輪詢。這似乎是合理的。但是，當你一直忙着睡覺時，它不會導致服務器端的超載。我對服務器上的性能問題沒有太多的瞭解。 – Hgeg 2012-03-24 09:30:53
假設你使用time.sleep（2）這樣的休眠機制，它的性能不會比普通輪詢低。它實際上應該節省CPU時間 - 但它可能會在主機上消耗更多的內存，因爲每個請求線程都在內存中的時間更長。這對你的應用程序是否有意義取決於你的具體情況以及你有多少用戶。但是，它一定會節省帶寬。 – 2012-03-26 17:29:42