我正在重寫一個3年前編寫的數據可視化Web工具。從那時起,瀏覽器的JavaScript引擎已經變得更快,所以我正在考慮將部分工作從服務器轉移到客戶端。優化數據可視化Web應用程序的性能
在頁面上,數據在表格和地圖(或圖表)中可視化,它使用的是相同的數據,但方式不同,所以兩種準備顯示數據的算法是不同的。
在用戶與數據下拉選擇器(3主+ 2sub取決於3主)的每次交互之前,發送了3個Ajax請求,php完成所有工作並僅發回需要的數據(在html中爲表/ xml的圖表)非常微小的響應,沒有性能問題和JavaScript附加響應,並沒有比追逐更改事件更多。
所以表現得不錯,但在標準用戶的每一個變化必須等待Ajax響應:/
現在我的想法是在一個Ajax請求發送回一個JSON對象,只有在主的每一個變化3標準組合,然後讓javascript填充表中的數據以及ajaxsuccess上的圖表/地圖,然後再改變2個子標準。
我的猶豫與服務器發送的json的結構有關,負載的平衡。事實上,如果只有一種算法需要創建想要的json結構來顯示原始數據中的數據,我會將php處理數據到這個對象中,以便爲javascript處理而無需任何額外的處理;但也有2
所以
如果我的PHP過程的數據,以創建2個對象(一個用於表/一個用於圖),我會加倍JSON響應&增加存儲器的大小在客戶端使用;我不喜歡這種方法,因爲這兩個對象包含相同的數據,只是結構不同&冗餘是邪惡的,不是嗎?
如果我發送原始對象並讓javascript搜索要顯示的內容以及我在哪裏向客戶端提供大量工作 - 這也適用於每個子標準更改(或者我可以在ajaxsuccess上創建所有json對象所以他們在這個子標準變化的情況下準備好) - 在這裏,我用舊的瀏覽器/小公羊用戶喜中有憂...
(原始JSON對象及時治療,根據標準3KB之間變化和12kb,在500和2000之間的記錄)
我沒有發現最好的方法...
因此,對於這個單一的原始數據多個結構化對象的工作,你會有PHP(增加響應大小和發送冗餘數據)或JavaScript(增加JavaScript負載)處理原始數據?
由於一噸您的意見
我們在這裏談論的數據是多少?除非你正在談論成千上萬的記錄,否則即使是一個較老的客戶端機器/瀏覽器也應該能夠處理這個問題(如果你正在處理那麼多的記錄,那麼你可能會遇到更大的問題,就像你描述的那樣)。只需傳遞原始數據一次,讓客戶端擔心渲染。 – DaveRandom
對於3個主要標準的每個組合,原始數據是36個狀態*(在2到10個不同人口組之間)*(在4到6個不同的結果類型之間) - > 300和2000個記錄之間(stateid,resulttypeid,groupid,百分比) – mikakun
增加,有3個主要標準60個不同的組合(因此總共大約100 000記錄在db中,因此我選擇從服務器請求數據不會超過這個級別);輔助問題是:在用戶請求另一個組合的數據後,將先前的原始數據保留在客戶端存儲器中是明智的做法(加上:如果返回先前看到的數據,則不會再發送ajax請求;否則:如果查看多個組合,在客戶端內存中有數十個對象,每個平均有千條原始記錄) – mikakun