來自JSON性能問題的巨大HTML列表

我構建了一種使用服務器端PHP和jQuery以及JavaScript中的自定義MVC的項目管理工具。來自JSON性能問題的巨大HTML列表

我有一個彈出窗口來幫助用戶在項目中添加人員。在彈出的位置，用戶必須選擇一個組（比如說一個學生組），然後他可以選擇配置文件將其添加到當前項目中。

我已經用70-120人的小組對它進行了測試，它工作起來有一點延遲。

但是，當我測試1000人的大組時，刷新時間太長以至於Chrome詢問我是否要停止腳本或等待更多時間...這對於iser體驗來說並不好！

數據來自服務器的JSON格式：

{ 「用戶」：[{ 「UID」：「科爾特斯」，「名字」：「弗朗索瓦」，「姓氏」：「CORTES」，「郵件」：「...」}]，/ * 1000個的用戶記錄更多的* /}

和數據在這個HTML的格式（自擬髭模板）

<li> 
    <div class="wrapper"> 
    <p class="title"> {{firstname}} {{lastname}} {{mail}} </p> 
    <p> {{uid}} </p> 
    <p> <input type="checkbox" id="select-{{uid}}" /> </p> 
    </div> 
</li>

jQuery是用於構建列表並添加一些監聽器 - 彈出式驗證前選擇/取消選擇狀態本地存儲 - 懸停鼠標上的一種亮點在每個列表元素上 [code] [code] 我的問題是如何跟蹤性能泄漏和如何修復它？

當然，代碼有點難看，很難維護，當然我也希望能夠很快解決這個問題......有人能幫助我嗎？

編輯：感謝您的意見和您的文章。

更多解釋：通常羣體可容納50-200人。由於一些技術和管理方面的原因，1000人的合併僅佔總數的90％，是暫時的。但是，執行性能並確保UI的反應性是一個巨大的挑戰。

對於它未能通過測試的那一刻...

@克里斯：我在PHP構建測試控制器時間JSON生成和大小

@Dandavis：是的，那一刻我做這個。我使用jQuery從頁面中獲取通用DIV模板，並在JSON數據上循環1000次，javascript字符串替換通配符{{example-data-name}}及其示例數據值，然後將其插入到DOM中jQuery），然後我綁定事件監聽器（jQuery）...醜陋的代碼，我同意，但自制的，沒有辦法，沒時間用BackBone或Knockout重構它...

documentFragment？好吧...需要進一步挖掘！

@ ajax81：在頁面加載時緩存的靜態JSON？爲什麼不......可能是修改現有工作和努力的最簡單方法！

@Alberto：我記住的有用提示。正如我上面所說的，我今天下午開始測試

我的感覺是PHP正確地完成了它的工作（關於數據大小和生成速度），但是m自定義模板方法不能有效處理整個數據！

由於用戶通常在小（50）到中（120）記錄列表中滾動，因此不需要分頁數據。 1,000是壓力測試。它只發生在夏季（節假日），但如果我能成功，用戶的日常經驗將會更好，並在低性能系統中防止崩潰。

問候。

編輯和解決問題

PHP

我已經太赫茲基準PHP腳本：1000條記錄提取和JSON代小於0.25秒執行時間和小於100K上長...所以服務器端沒有特別的問題。

我已經做了一些優化服務器端來限制數據庫和LDAP請求通過使用一些in-PHP緩存，只是爲了限制來自我的應用程序的冗餘和網絡流量。

的Javascript

然後我修改模板的使用：現在我環路1000條JSON記錄，評估模板，並在原始的HTML字符串追加的結果，接下來的附加LI元素到UL。

在這一點上，這個列表是視覺上爲用戶準備好的。

後來我再次循環JSON數據以綁定事件處理程序（單擊複選框，單擊周圍的DIV，並將鼠標懸停在指針上...），但該列表尚未顯示！

刷新列表中的延遲是可見的，但非常短暫，小於1.5秒......也許我會添加一些沙漏圖標以防止用戶在等待列表時重複點擊。

所以定時測試成功，現在 在正常使用，列表不會超過150人，因此，如果它是確定1000 ...它是確定對我來說:-)

非常感謝（@所有）的幫助。

來源

2013-07-08 Hefeust CORTES

您是否對人員數據的實際GET請求計時以確定問題是否正在傳輸列表？ –

嗯。模板非常快，不管是12或12,000。你在循環中追加/ .html（）ing 1,000個LI標籤嗎？如果是這樣，切換到臨時document.createDocumentFragment（）並享受更好的性能數量級。 – dandavis

如果我是你，我會請按照下列步驟操作：

追查其獲取你的數據和時間吧，如果它需要大量的也許只是一個缺失索引，或低效的查詢，但查詢在這一點上，你知道在哪裏可以點你的手指
使用該頁面的靜態版本，而不做任何服務器端調用，簡單地把JSON結果在一個文件中，並加載，看你的代碼的行爲
爲@克里斯皮特曼說GET有多少時間需要

您應該能夠通過執行此步驟大致找到問題出在哪裏。

作爲一般規則，我會建議您增加搜索開始時的字母數量，以便您永遠不會返回大量結果，從而減少加載時間，也是因爲沒有人希望您在返回結果時用戶在搜索字段中輸入「a」。

您可能想要評估的另一件事是傳遞一個更薄的數組，其中只包含用戶的電子郵件，在請求時獲取更多數據，根據定義電子郵件是唯一的。

來源

2013-07-08 16:41:40

根據我的經驗，Chrome通常不會在文件下載時提示取消 - 它通常會處理大量的數據（下載後），從而觸發警告。我並不是說你沒有突出優化的絕佳機會，但我不認爲它們直接適用於OP的確切問題。 –

我不確切地知道你想要什麼，但是你在這個json列表中使用分頁嗎？用分頁10,20,30行等列出值，並給ajax服務器調用抓取下一批分頁行。

來源

2013-07-08 16:43:10 Haseena

您的問題與「性能泄漏」跟蹤沒有直接關係，因爲您知道問題出在哪裏，並且您已經確定了罪魁禍首：您正在處理大量的數據。阿爾貝託提出的通過一個更薄的陣列並試圖用更少的方式做更多的建議是一個很好的開始。 Ase Ena提出的分頁數據的建議很明顯，但是（我猜測）在你的舒適區之外。

如果在您的應用程序中經常訪問和使用此列表，Alberto建議將它緩存到自己的JSON文件中，這是一個很好的建議。每次需要列表時，這將爲您節省大量的數據庫查詢，並減輕您必須進行後續ajax調用來檢索數據。此外，它將被緩存在客戶端的機器上（即使是在訪問應用程序時），並提高性能，因爲每次訪問應用程序或每次需要顯示列表時都不必下載。作爲額外的好處，緩存客戶端上的整個列表大大簡化了您將用於翻閱數據的分頁機制，因爲您不必管理服務器端SQL，會話狀態等。

編輯 -

我想到，當我說「在客戶端緩存JSON文件」時，您可能不知道我的意思。這裏是一個例子：

<script src="MyPeopleList.json?v1" type="text/javascript"></script>

你基本上只是鏈接在json文件中的方式與任何其他的javascript。您的JSON用戶列表現在可供您的應用程序的其餘部分使用，並進行緩存。如果您需要刷新列表或確保您的用戶獲得列表的最新版本，您可以簡單地將「v1」更改爲「v2」。（版本是重要的，因爲某些類型的Internet Explorer積極地緩存這些文件，即使服務器上的文件比緩存中的文件更新也不會刷新）。

來源

2013-07-08 17:05:31

來自JSON性能問題的巨大HTML列表

回答

相關問題