嘿嘿，今天改bug，又發現了乙個效能問題。在顯示所有bug列表的列印頁面下，顯示800個bug居然要花26s的時間，看上去已經是另人難於忍受了。在顯示測試報告頁面，由於不需要顯示bug列表，因此，成績從18s一下子提公升到了0.8s，現在這個列印頁面需要將所有的bug都列印出來，需要顯示所有的bug，因此，時間颼颼的往上彪，到了26s，實在是讓人難於忍受。
原因在什麼地方呢？
通過檢視**，發現有一段：
[code] if (print != null && print.equals("true")) else [/code]
在原來的方法中，需要將buglist轉換為頁面顯示需要的buginfoviewbean資料物件。而原來的做法是取出每乙個bug物件，乙個乙個將數字轉換為顯示所需要的字串，而轉換的過程就是查詢資料庫的過程，因此，如果需要轉換800個bug，每個bug需要有10個域需要轉換的話，那麼就要查詢資料庫為800*10次。出此之外，由於buginfoviewbean中包含了在顯示列表中不需要的資訊，而原方法也照轉不誤。因此，實際上查詢資料庫都超過10000次，如果每次查詢花15ms的話，這次查詢就已經花費了15s，另外，將800個物件賦值到另外乙個物件，估計也得花費一段時間。因此，整個時間就上去了。
為了避免大量的資料庫查詢操作，新增了一些map。由於bug中的很多欄位是相同的，相同的字段再去查詢資料庫，明顯不恰當。因此，需要減少重複的查詢次數。
[code] mapbugseriousmap = getbugseriousmap();[/code]
這段**通過一次查詢將資料庫中所有的嚴重程度屬性查詢出來，構造嚴重程度的map。之後通過map，取得每個bug嚴重程度所對應的字串表示。
[code] if(null!=element.getbugtype())[/code]
下面這段**，首先構造人員資訊。
mappersonmap = new hashmap();
如果bug相關的人員不在personmap中，那麼訪問一次資料庫，將其新增進去。如果人員很多的話，可能得需要查詢n次。
好，記錄一下，剛才的優化結果是6.2s。做完這個優化之後，應該會減少更多。但是，如果一次查詢是15s，100次查詢也就是1.5s,無所謂了。
另外，開發過程實在是不敏捷。我的classes已經check in到配置庫了，要重新改的話，需要重新check out classes。耗時2min，然後ant，耗時1.5min，然後啟動tomcat，又要耗時1min，要做這件事情，又得先花費4-5分鐘時間，沒得搞。還是做罷。
這樣的開發方式怎麼會有效率呢……
提公升軟體效能
提高系統的安全性和健壯性，資料庫伺服器和應用伺服器,就要考慮冗餘設計。保證系統的高可用和高可靠以及高併發。保證系統在出現故障時,及時切換正常工作,使用雙機熱備份。使用redis快取伺服器提高系統的效能。使用讀寫分離技術減輕資料訪問的壓力,提公升系統的使用者體驗。在資料庫的設計上來使用分庫 分表 分割...
提公升頁面效能
1.資源壓縮合併，減少http請求 2.非核心 非同步載入 非同步載入的方式 a.動態指令碼載入 b.defer c.async defer 在html解析完成之後才會執行，並按照載入順序執行 async 在載入完成之後立即執行，和載入順序無關。3.利用瀏覽器快取 快取的分為強快取和協商快取 強快取...
postgresql 效能提公升
檔案 postgresql.conf checkpoint又名檢查點，在oracle中checkpoint的發生意味著之前的髒資料全部寫回磁碟，資料庫實現了一致性與資料完整性。oracle在實現介質恢復時將以最近的checkpoint為參照點執行事務前滾。在postgresql中checkpoint...