最近開發過程中，遇到兩次效能優化的需求，幾番努力完成效能要求，乙個因為工作改動量大而沒有付諸實踐，現小結如下。
對外提供的網路介面，資料庫資料都走了redis的快取，但是在此情況下，仍然請求在10秒多，資料量大的時候需要快20秒，現要求是秒以內的響應速度。
首先對各個方法進行響應時間的日誌新增，執行幾種情況，看看那些方法時間長，主要關注點在i/o，遠端請求，資料庫操作。經過幾輪測試之後，發現主要資料庫操作耗時，核對**發現其實是資料庫快取沒有存進去，修改後再次測試，發現還是沒有走快取，核對**發現其實存進去的key和查詢用的key不同，修改後在次測試，發現效能大幅提公升，全部走快取的情況下，基本在800毫秒左右。但是在測試中，發現如果不走快取的時候，資料量大的時候響應非常慢，初步懷疑是資料庫中的增刪改操作有問題。核對**後發現是批量更新的時候是一條一條更新的，每次更新都連線資料庫，一旦資料量達到幾十條的時候，會很耗時。最後分析需要使用mybatis的動態sql，批量更新，減少資料庫操作。修改後確實效能大幅提公升。批量更新主要還是使用case when 和for 關鍵字。
現在快取技術已經普遍使用在軟體開發過程中，設定有相同的key值訪問是不能出錯，否則會造成訪問不一致，快取不起作用；資料庫操作，涉及到批量的操作時候，一定要採用批量操作的方式，否則會造成效能下降。
微服務架構，對外的介面服務呼叫業務服務獲取資料庫結果，並在介面服務中多執行緒呼叫第三方的http請求。目前響應時間較長，大約20秒左右，希望能降低到6秒內。
也是對主要方法進行了粗略的瀏覽，對主要方法新增時間日誌， 經過測試發現主要是呼叫第三方的時候，多次呼叫導致耗時，之所以多次呼叫是因為一次呼叫的時候結果不完整，所以呼叫了多次。為了保證能拿到完整結果，所以每呼叫一次之後，當前執行緒睡眠1秒後再次呼叫，如此往復最多五次。經過測試發現，大多數情況是第一次或者第二次就能返回結果，直到第三次返回結果的概率較小。經過分析後，得出得方案是，第一次查詢，查出一部分結果就返回給使用者，然後再查第二次，第二次結果回來後，如果使用者需要檢視全部結果則展示第二次查詢的完整結果。雖然複雜，但是可以很大程度上提公升使用者體驗。但是因為涉及的改動較大，方案被擱置。除此之外還做了一些，小的優化。1.map的初始化容量。從資料庫查詢的結果要儲存在乙個map中，查詢結果的數量是幾千條，這個時候在建立map物件的時候，指定容量以避免多次擴容造成效能損耗；2.快取時間。對於一些一直不變的大量資料，在快取中的失效時間設定的需要長一些，以降低資料庫查詢的次數，整體上減少平均請求時間。建議至少一天；3.快取穿透。對於一系列相關的快取，需要將其快取失效時間設定為階梯狀，最好不要設定為相等的時間，這樣子在同時失效時，會造成某一時刻都去查詢資料庫，效能大幅下降。4.修改執行緒的休眠時間。上面描述，大部分請求都是在兩次請求後就可拿到結果，所以將執行緒的休眠時間做了依次衰減。5.新增快取。沒有假快取的地方新增了快取。小的優化最終沒有達到效能的要求，但是也算是一些優化。
快取穿透在不發生的時候似乎覺得沒有什麼，一旦發生就會讓人猝不及防。從每乙個小細節著手，也許是開發高效能系統的重中之重。
純屬個人愚見，歡迎指正討論。
優化系統效能
程式框架 hibernate3 struts2 spring2 資料庫 sqlserver2008 伺服器 tomcat6 優化方法 1 配置連線池 採用的c3p0連線池 2 在程式中獲取列表時，用iterator代替list 3 在查詢之後可以使用session.clear 方法釋放快取 4 用資...
Linux系統效能優化
由於各種的i o負載情形各異，linux系統中檔案系統的預設配置一般來說都比較中庸，強調普遍適用性。然而在特定應用下，這種配置往往在i o效能方面不能達到最優。因此，如果應用對i o效能要求較高，除了採用效能更高的硬體 如磁碟 hba卡 cpu mem等 外，我們還可以通過對檔案系統進行效能調優，來...
Android 系統效能優化
android作為一種移動裝置的作業系統，無法像pc機一樣具有強大的記憶體和cpu，這就意味著，我們的android應用程式無法無節制的使用記憶體和cpu資源。很多時候我們過多的使用這些資源時，會導致系統的卡頓或者程式anr。常見的記憶體使用異常主要包括兩種 記憶體溢位和記憶體洩露。記憶體溢位 指的...