問答專欄Q & A COLUMN
從系統架構本身來說，一般系統優化主要從三個方面入手，數據持久層、業務邏輯層和前端展示層。
限制系統性能主要有兩個方面，一是數據庫自身的性能，二是對數據庫操作的方式，數據庫自身相對簡單，一般通過優化配置、采用高可用方案、搭建集群或者使用性能更好的數據庫來提升性能；數據庫操作主要是數據庫讀寫操作，可以通過SQL優化的方式來提升讀寫速度，或者通過緩存的方式減低并發、提升性能。
代碼層面常見的問題有內存泄露、資源泄露、線程死鎖等，主要通過優化相關的代碼和算法來提升性能，使用數據庫連接、文件讀取時及時關閉IO流，注意線程死鎖，以及靜態對象的使用等，降低JVM的內存消耗，使用高性能的框架、算法，從代碼層面提升系統性能。
前端主要考慮從代碼和資源角度進行優化，如優化、壓縮JS代碼，優化頁面渲染效果，減低渲染頻率，使用異步加載數據，采用緩存減少服務器的訪問以及靜態資源的訪問。
評論0
加載中...
對于業務系統的性能優化，我原來系統的談過分析和診斷的思路，今天再談下業務系統性能優化里面我們常見的一些思考和分析系統性能問題的方法。
有時候大家可能覺得奇怪，為何我們系統再上線前都做了性能測試，為何上線后還是會出現系統性能問題。那么我們可以考慮下實際上我們上線前性能測試可能存在的一些無法真實模擬生產環境的地方，具體為：
1. 硬件能否完全模擬真實環境？最好的性能測試往往是直接在搭建完成的生產環境進行。
2. 數據量能否模擬實際場景？真實場景往往是多個業務表都已經存在大數據量的積累而非空表。
3. 并發能否模擬真實場景？一個是并發需要錄制復合業務場景，一個是并發量大時候需要多臺壓測機。
而實際上我們在做性能測試的時候以上幾個點都很難真正做到，因此要想完全模擬出生產真實環境是相當困難的，這也導致了很多性能問題是在真正上線后才發現。
第二個點也是我們經常談的比較多的點，就是我們的業務系統在進行架構設計的時候，特別是面對非功能性需求，我們都會談到系統本身的數據庫，中間件都采用了集群技術，能夠做到彈性水平擴展。那么這種彈性水平擴展能力是否又真正解決了性能問題？
實際上我們看到對于數據庫往往很難真正做到無限的彈性水平擴展，即使對于Oracle RAC集群往往也是最多擴展到單點的2到3倍性能。對于應用集群往往可以做到彈性水平擴展，當前技術也比較成熟。
當中間件能夠做到完全彈性擴展的時候，實際上仍然可能存在性能問題，即隨著我們系統的運行和業務數據量的不斷積累增值。實際上你可以看到往往非并發狀態下的單用戶訪問本身就很慢，而不是說并發上來后滿。因此也是我們常說的要給點，即：
單點訪問性能正常的時候可以擴展集群來應對大并發狀態下的同時訪問
單點訪問本身性能就有問題的時候，要優先優化單節點訪問性能
業務系統性能診斷的分類
對于業務系統性能診斷，如果從靜態角度我們可以考慮從以下三個方面進行分類
那么一個業務系統應用功能出現問題了，我們當然也可以從動態層面來看實際一個應用請求從調用開始究竟經過了哪些代碼和硬件基礎設施，通過分段方法來定位和查詢問題。
比如我們常見的就是一個查詢功能如果出現問題了，首先就是找到這個查詢功能對應的SQL語句在后臺查詢是否很慢，如果這個SQL本身就慢，那么就要優化優化SQL語句。如果SQL本身快但是查詢慢，那就要看下是否是前端性能問題或者集群問題等。
對于業務系統性能問題，我們經常想到的就是要擴展數據庫的硬件性能，比如擴展CPU和內存，擴展集群，但是實際上可以看到很多應用的性能問題并不是硬件性能導致的，而是由于軟件代碼性能引起的。對于軟件代碼常見的性能問題我在以往的博客文章里面也談過到，比較典型的包括了。
1. 循環中初始化大的結構對象，數據庫連接等
2. 資源不釋放導致的內存泄露等
3. 沒有基于場景需求來適度通過緩存等方式提升性能
4. 長周期事務處理耗費資源
5. 處理某一個業務場景或問題的時候，沒有選擇最優的數據結構或算法
以上都是常見的一些軟件代碼性能問題點，而這些往往需要通過我們進行Code Review或代碼評審的方式才能夠發現出來。因此如果要做全面的性能優化，對于軟件代碼的性能問題排查是必須的。
對于性能問題的發現一般有兩條路徑，一個就是通過我們IT資源的監控，APM的性能監控和預警來提前發現性能問題，一個是通過業務用戶在使用過程中的反饋來發現性能問題。
而隨著DevOps和自動化運維的思路推進，我們更加希望是通過APM等工具主動監控來發現性能問題，對于APM工具最大的好處就是可以進行服務鏈間和全鏈路的性能分析，方便我們發現性能問題究竟發生在哪里。比如我們提交一個表單很慢，通過APM分析我們很容易發現究竟是調用哪個業務服務慢，或者是處理哪個SQL語句慢。這樣可以極大的提升我們性能問題分析診斷的效率。
評論0
加載中...
面試官：給我講講你的項目是怎么性能優化的？
https://mp.weixin.qq.com/s/t_tCxI9b4rmJOye1BiB1oQ
評論0
加載中...
很多時候我們為了節省開支，會在ECS自建Mysql數據庫或者采用第三方一鍵環境來運行WP數據庫，雖然有時會出現訪問延遲等問題，但總體而言還是挺合適的一種方式。只不過并不是每個朋友都具備處理突發問題的能力，一旦在一個相對重要的時刻出現了宕機等難題，抓狂可能是很多人能做也是唯一能做的事情。因此，從成本和運營效率上考慮，推薦大家借助RDS來運行站點數據庫。
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
