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