不斷通過Javascript查詢服務器 - 好主意？

Question

我有一個擁有大約5-10位管理員的小型網站。我已經設置它來監視每個管理員正在做什麼（添加項目，刪除項目等）。我在管理面板中有一個列表，顯示集體管理部門執行的前10項活動。今天，我決定每30秒進行一次自我更新。

我的問題很簡單：這樣做有什麼問題嗎？我在每次請求時都會調用一小段文本，並且請求可能一次只能在3臺或4臺計算機上運行（反映登錄的併發管理員數量）。

$(document).ready(function(){ 
    setInterval("activity()", 30000); 
    }); 

    function activity() { 
    $("#recent_activity").load("../home/login #recent_activity .data"); 
    } 

對每個請求產生以下（或類似 - 僅限10行）。

<table> 
    <tbody> 
    <tr> 
     <td><p>jsampson</p></td> 
     <td><p>logged out</p></td> 
     <td><p>28 minutes 27 seconds ago</p></td> 
    </tr> 
    <tr> 
     <td><p>jdoe</p></td> 
     <td><p>logged in</p></td> 
     <td><p>29 minutes 45 seconds ago</p></td> 
    </tr> 
    </tbody> 
</table> 

Answer 1

3-4個用戶每30秒不是很多。即使是300個用戶也不會太多。

您可能要檢查到這些問題：

• Should I use Ajax Push or Pull
• Simple Long Polling Example Code

您可以緩存此爲好，這將是最好特別是當查詢到生成頁面的計算量很大，但當然要考慮到最新內容需要哪種延遲顯示。

Answer 2

我不認爲這會造成問題。

Answer 3

不，根本不應該有任何問題。我在1分鐘的時間內爲我公司的Intranet門戶上寫的通知系統做同樣的事情。任何Web服務器都應該能夠誠實地處理這個問題。

實際上，它們並沒有比它們更糟，比如說每30秒刷新一次瀏覽器......考慮到數據傳輸的數據傳輸量要小得多，它的數據傳輸速度可能會更快10-20倍而不是刷新它......或者每5-10分鐘刷新一次相同的帶寬。 :-)

Answer 4

你應該緩存這個並且每30秒只更新緩存。

Answer 5

在我看來沒有問題。運行規模更大的網站（比如Betfair）每個連接的客戶端每分鐘使用數百個xhr的呼叫。 顯然他們有更大的硬件基礎設施，但瀏覽器可以很好地應對。

我有使用較小的間隔網站，他們擴展到幾百個從網絡服務器的單層運行併發用戶。

Answer 6

我想說它主要取決於查詢的價格。

雖然現在的用戶數量很少，它會一直如此嗎？

Answer 7

正如altCognito指出的那樣 - 網絡流量不會成爲問題。

我唯一要檢查的是數據庫負載是否會成爲問題。 IE瀏覽器。如果這是由需要一些時間運行的查詢提供的，則會導致問題。如果是這種情況，我建議在數據中添加一些緩存，或者在內存中而不是數據庫中維護數據（僅在啓動時從數據庫加載，並將這些內容添加到此服務器內存列表中）他們發生）。

Answer 8

稱重它反對替代。如果每個用戶每隔30秒刷新一次頁面，加載整個頁面，則服務器端處理和流量產生的數量將遠遠超過刷新「有趣的部分」。

這就是AJAX所做的。

Answer 9

您是否看到Google Wave預覽...？對於這樣一個小數目，這不是一個問題，特別是當管理員知道這個問題時。 （這不像你在某些訪問者的CPU或移動互聯網連接上施加了一些負擔。）

Answer 10

很多用戶不打算停止服務器。

如果你真的關心性能，我給你2忠告：

• 使用JSON用於將數據發送到客戶端，它會比使用HTML輕。

• 使用歷史數據的固定日期並計算客戶端上的相對時間，它將允許您緩存歷史數據。

  {"user":"jsampson","action":"logged out","date":"20090622T170822"}

Answer 11

呀，這不應該有絲毫的問題。這就是說，如果你擔心發回的數據量，你總是可以讓這個調用發回一個簡單的標誌，如果有新的數據，然後去取數據（如果是這樣的話）。

但是，有了這個數量的用戶，你不應該有任何問題。我經常使用一種定製的基於RoR的留言板，使用類似的技術來查看線程是否在您閱讀時進行了更新，並且有超過100名用戶同時擊中它並且沒有任何問題。

Answer 12

有幾種不同的方法可以模擬HTTP上的服務器推送。這種技術最近得到了一個奇特的名字：Comet。

如果您的服務器配置允許無限期地運行腳本，則可以使用iframe來實現該面板並使用分塊傳輸（例如，通過PHP的flush()）創建持久HTTP連接。如果連續消息之間的時間間隔很短，這樣的解決方案應該具有最小的開銷。對於較長的時間間隔，客戶端輪詢更可取，因爲不需要維護TCP連接。

Answer 13

我覺得你做的很好。

如果我正在做這個項目，我會從你有的開始，並添加一個setTimeout（）事件來每秒增加分鐘/秒的顯示。

用戶會認爲顯示是實時的，他們可能永遠不會刷新頁面。

只有每30秒更新一次的危險是，每次將注意力轉向「最新」時，有些人會反射性地刷新。

也可以考慮特殊標記時間少於五分鐘。登錄的顏色編碼與登出。人們「掃描」會更容易，因爲他們可以在不閱讀所有文本的情況下選擇更改。