客戶端 - 服務器交互的一些最佳實踐是什麼？

我正在構建一個工作網站，其中一個更重要的功能是顯示數據的豐富內容網格。默認情況下，它每個頁面只顯示20個項目，但是我們在數據庫中有200個項目可以過濾，排序和搜索。客戶端 - 服務器交互的一些最佳實踐是什麼？

我們的銷售和營銷團隊也請求「列表中的所有」功能，使他們能夠在一個地方顯示所有數據，並通過而不是頁面滾動數據。

Flexigrid data

這整個系統在服務器端，jQuery和Flexigrid在客戶端上使用ASP.Net MVC構建，並且使用JSON通過AJAX交換兩者之間的數據。

我已經得到了實際的數據傳輸部分非常穩固。一個包含20個結果的頁面對於整個請求需要800ms（通過Flexigrid發送一個請求到服務器並獲得響應）。這更多的是需要一段時間的客戶端處理。

我可以卸載一些客戶端處理的服務器。但是這會使服務器端操作花費更長時間並使文檔的大小返回更大。在高速互聯網連接的情況下不成問題......但事實並非如此。

另一種選擇我是下載儘可能多的數據可能和大部分數據處理轉移到客戶端。這將請求時間減少到基本零（僅提取更改的元素而不是整個數據集）。它在具有快速CPU和大量RAM的機器上工作得很好，但事實並非如此。

因爲至少有一個人檢舉這個「不是一個真正的問題，」讓我澄清...

我還能做些什麼來減輕客戶端的處理時間問題，而沒有移動這麼多處理到服務器，我最終與數據傳輸時間問題？
平衡客戶端處理與服務器端處理有什麼最佳實踐？
錯在服務器端還是客戶端更好？
我可以使用哪些工具更好地優化這些交換，以便事情不會繼續發生錯誤？

來源

2011-11-01 EAMann

什麼是你所需要如此長的客戶端處理？處理JSON對象（即使是非常大的對象）也不應該太密集。

很多寫數據的客戶端時可能會放慢下來DOM看起坐。減少DOM查找可以極大地提高性能。我認爲平衡服務器客戶端處理的良好做法是在服務器上發生錯誤。由於服務器在您的控制之下，您可以隨時選擇升級您的服務器。保持服務器上的大部分處理也將使移動設備和舊電腦變得更容易。

你應該使用AJAX以增強用戶體驗的方式&客戶端功能。按用戶要求加載和處理數據。通過僅加載他們請求的內容，可以減少服務器&客戶端的負載。

如果您也一直在請求相同類型的數據，您可以查看兩個服務器&客戶端緩存。通過使用緩存，您可以減少請求時間和/或帶寬。

來源

2011-11-02 05:44:15

服務器發送一個JSON對象給客戶端。 JSON對象然後被加載到Flexigrid中。 Flexigrid本身將對象讀入表中，然後執行一些昂貴的'document.createElement（）'操作來格式化表以供顯示。它將對象轉換成一個非常密集的HTML表格。 – EAMann

另請參閱下面的詳細回覆... – EAMann

事實證明，問題在於客戶端上的JavaScript引擎比我正在使用的數據更多。我花了大部分時間對流程進行基準測試並對各種操作進行計時。

在Chrome中一切都運行得很快。 Firefox的運行速度相當快（Chrome的速度並不如Chrome瀏覽器那麼快）。真正的表現落後於Internet Explorer。

當我加載整個數據集 - 所有200行 - Flexigrid嘗試做表表中的每個單元格的一些後處理。正如你在截圖中看到的那樣，每一行都有29個單元格......所以我們通過一堆格式化操作總共查看了5800次。

我能夠從較低級別的單元循環中抽出一些更昂貴的操作（即創建jQuery對象），以便它們每行只運行一次，但最終我仍然遇到與IE相關的操作性能問題。

給你一些真實世界的基準測試，我設置代碼吐出的總時間達到某些事件之前：

populate火災時，瀏覽器首先會關閉XHR請求
addData所述請求之後火災已經返回和JSON對象之前通過表中的每個單元解析的數據和迭代的初始解析後
addCellProp火災
done起的火災時，一切都finsihed

處理20行的數據（默認值）：

------------------------------------------------------ 
| browser | populate | addData | addCellProp | done | 
------------------------------------------------------ 
| Chrome | 0  | 84  | 123   | 286 | 
| IE9  | 0  | 151  | 309   | 799 | 
| IE8  | 0  | 226  | 481   | 1105 |

處理完整的數據集（179行此機器上）：

------------------------------------------------------ 
| browser | populate | addData | addCellProp | done | 
------------------------------------------------------ 
| Chrome | 0  | 318  | 669   | 1963 | 
| IE9  | 0  | 157  | 1813  | 9428 | 
| IE8  | 0  | 229  | 2188  | 13335 |

最昂貴的操作在addCellProp和done之間。我已經完成並儘可能地提高了代碼的效率，但是當您運行數據集的多次迭代時（特別是在操作DOM時），您只能做很多事情。

我已經修改了Flexigrid（儘管許多建議不要）儘可能少地觸摸DOM，這實際上加快了一些。當我開始這項研究時，IE9將花費20到30秒時間來擊中done事件。

這裏不幸的事實是，並非所有的平臺都是平等的，IE似乎不是以這種方式處理顯示內數據的最佳引擎。

更好的方法可能是在服務器端創建和操作HTML表格，並在IE用戶請求時將所有內容（標記和全部）發送到瀏覽器，而不是依靠IE從原始創建標記JSON對象。

來源

2011-11-02 23:13:12 EAMann

每個事件的跨瀏覽器基準測試都非常有用。這確實有助於澄清問題的根源。格式化IE用戶的服務器端聽起來像一個堅實的想法。 –

我通過並重寫了一些東西，以便在AJAX請求中發送整個表。在原始系統中，只有數據被髮送，JS被用來處理它並填充表格。一方面，我現在在XHR響應中發送10倍的信息。另一方面，頁面在IE中可靠地加載10倍。 – EAMann

我可以做些什麼來緩解客戶端處理時間問題，而不會將太多的處理移動到服務器，導致數據傳輸時間問題？

數據是從數據庫中傳出來的嗎？如果這樣的話，那裏限制數據。這是數據庫擅長的。我使用flexigrid並保留所有的分頁排序和過濾。數據庫僅返回按要求排序和過濾所需的數據。所有服務器必須做的就是返回它，並且所有客戶端必須做的就是呈現它。

平衡客戶端處理與服務器端處理有什麼最佳實踐？

保持客戶端輕越好

是更好地失之於服務器或客戶端的一邊？

是服務器有更多的權力

什麼是一些工具，我可以用它來更好地優化這些交流，這樣的事情不要繼續走歪？

IE開發者工具使用網絡標籤，看看有什麼過來電線

來源

2011-12-22 10:38:05

這不是問題所在。分頁，排序和過濾*都在服務器上完成。但是，當數據集是200 + 30列以上的列時，客戶端渲染在IE上顯着減慢*。它與Flexigrid中編碼不佳的事件處理程序有很大關係，而不是數據本身。 – EAMann

如果數據是受限的服務器端，那麼客戶端將永遠不會收到這樣大的數據集。例如客戶端只會收到一頁數據。當用戶點擊下一頁時，flexigrid回調到服務器並獲取下一頁。除非你想在一個頁面上顯示200多行？ –

分頁默認設置爲在一頁上限制爲5,10,15或20個結果。但正如我在原始問題中所提到的那樣，銷售/營銷團隊特別要求「查看全部」選項，以在單個頁面上顯示所有數據。這是當我嘗試調試「查看所有」時的性能。 – EAMann

客戶端 - 服務器交互的一些最佳實踐是什麼？

回答

相關問題