前端頁面熱數據太多，每秒都要請求幾百個數據更新，開發這樣的頁面 Vue 性能怎麼樣？

01-11

要做一個設備監控的系統，一個設備可能會有上百個的監控數據，一個頁面可能會有上百台設備。頁面需要做大量的頻繁的熱數據更新。請問這種需求，Vue或者angular2.0可以滿足要求么？正在技術選型，原本做過angular1.0，但是怕這個需求下angular1.0性能會太差。求指教一二啊謝謝

單講性能，幾百個數據的更新對於目前的主流框架來說，應該都不會構成什麼瓶頸（桌面端而言）。但是這其實不僅僅是個技術問題：產品 / UX 層面，你要考慮一個『用戶信息接收量』的問題。

首先即使是實時數據，對於用戶來說更新頻率也不是越快越好的。不僅僅是框架更新速度可能有瓶頸，人類接收信息的速度也有瓶頸。舉例來說，除非是圖像，否則 60fps 的實時更新在大多數時候是信息量過剩的。從這個思路出發，最簡單的保證性能的做法就是對更新進行 buffer/batch：不要新數據一來就立刻刷新，而是推到一個隊列裡面，定時一次性刷新出去。

其次，頁面上一次性展示的數據也不是越多越好。想像一下幾百個單元格/圖表不停地刷新（比如 dbmon benchmark），你覺得你能從裡面獲取多少有效信息？倒不如從設計的角度去思考一下如何切分頁面，精簡單個頁面上的信息從而讓它們更容易被用戶接收。

移動端更是如此：幾寸大的屏幕上，信息展示量非常有限，更多的時候要考慮的是『信息量』的優化。

而當你從信息量的角度重新思考過後，可能會發現一些所謂的『性能問題』也不復存在了。

設計良好的ng1程序並不會成為瓶頸，如果你有ng1基礎那麼最好的選擇是ng2 —— 概念上有對應關係，編程模式一樣，性能顯著提升。

不要信那些評測，一切評測都是詭辯術。否則早就有「宇宙最強語言」一統天下了。離開場景談選型的都是耍流氓。

你這個場景下，用ng2開啟push模式（ng2開啟了push模式之後就不再進行臟檢查了，一切界面更新都由你自己完全控制），加上rxjs作為數據架構，在速度和可維護性方面都很不錯。

如果有圖表，建議用ng2+d3以及它的封裝庫nvd3。當然，如果你的圖表需要更高的可定製性，可以把d3純粹作為演算法庫使用，然後把結果綁定到內聯的svg腳本上。我曾經用這種方式實現了一個基於中國地圖的遷徙圖，大約用了三天時間（探索這種可能性，並順帶學了d3）。

你的問題，不是哪個框架性能更好，而更需要的是解決問題的手段。

數據聚合使用表格是最簡單一種方式，但是監控設備，一般是指它的健康度。

通常情況下我們會採用圖表展示的方式處理。設置異常閥值監控不健康的設備，可以按照異常設備的數量按照幾個監控的維度，例如時間，設備分類，所在位置。方便分析情況。

對於如果你只是顯示一個表格展示設備數據，可以採用一次請求拉取數據，一次拉幾千個數據是沒有問題的。

如果說只能從angular 、vue 選擇，我推薦vue，從學習成本來說，比較簡單。同時渲染一千個單元格問題不大。ng 學習成本太高

如果要我推薦，我選擇d3，性能比較好，而且理解了enter/exit/update，會感覺到更加簡單。

當然還有比它們更快的，容我留個坑，有時間再詳細回答

根據 Vue.js 官方的測試結果來看，我認為 Vue 並不會成為這塊的性能瓶頸，測試中渲染 10,000 個列表項 100 次平均只花了 51ms，最慢也只是 343ms。

你的瓶頸在網速，如何減少請求數是你要考慮的問題，不是如何操作 DOM。

可以學遊戲引擎，丟幀，處理不過來，不處理就是，反正更新了很快就會覆蓋。

或者直接按固定頻率採樣，畢竟更新太快，你也看不清啊，視覺有暫留的。

ng1不見得就像你想得那樣不堪哦？

瀏覽器有並發請求數限制，每秒幾百個請求，瓶頸是瀏覽器啊（：

真的需要每秒幾百個請求嗎？我覺得在這方面可能需要再考慮一下。

你一個獲取一個設備的信息就要發上百個請求，一個頁面有上百個設備，你難道刷新一次頁面要發上萬個請求？這種情況我覺得你應該和後端同事商量一下。不管怎麼樣，如果前端要發上百個請求才能獲得想要的數據的話，那說明 API 設計肯定有些問題。

另外框架對性能的影響一般體現在數據綁定和 DOM 操作上。渲染性能取決於你綁定了多少數據和頁面上的元素數量。對於你的場景，頁面上可能有上萬個元素和上萬的數據綁定，這樣的話 Vue 和 Angular2 應該都能滿足你的需求。

儘管技術上或許可以實現，我覺得你可能要先反思一下你的需求。

不應該有個數據處理的前置server么？

一個瀏覽器發500請求，那B端上量級了，請求的響應端不會瓦掉？

不應該是前置server發請求打時間戳，緩存結果么？

lz說的這個場景類似做遊戲，因為遊戲引擎和軟體引擎在圖像更新上的機制不同，解決你的這個要求完全不在話下。如果你對耗電量和硬體上沒有特別大的限制，可以考慮找個遊戲引擎做這套系統。

另外如果需要基於瀏覽器跑的可以選個webgl的引擎。如果可以做成端的，選擇就更多了。隨便一搜一大堆。缺點就是需要你自己寫不少組件，沒有現成的。

忽然想起，如果需要各種企業級組件，可以試下flex，需要注意的是flex做一頁有幾百行的列表組件會和js做的一樣卡，其他方面會比js效率高。

最後補充下，我沒做過vue的dom壓力測試，並不代表vue行不行，只是我沒權利多說。

為什麼要發幾百個？合併成一個請求行不行？

謝謝各位了，不是發幾百個請求，是每秒都會請求上百個數據更新dom，一個設備上百個的話就很多了，.dom比較多....就是怕渲染會出問題，還沒渲染完，數據又過來了……

對於大量次數的數據請求，框架並不是性能瓶頸，減少請求次數是當務之急。

另外，如果頁面僅僅只有數據的更新，並無多少dom的重複渲染的話，個人更推薦vue。

寫起來真的很爽。

把數據集中到資料庫中，然後前段面對資料庫

最可能出現問題的是頁面DOM元素過多，頻繁更新DOM的時候會導致性能瓶頸，JS很快，但是DOM的渲染展示很慢，所以盡量減少DOM個數