資訊專欄INFORMATION COLUMN
摘要：如果有人負(fù)責(zé)把控從相對(duì)長(zhǎng)遠(yuǎn)些的角度設(shè)計(jì)系統(tǒng)的迭代，這種情況本是可以避免的優(yōu)化辦法只有一個(gè)就是保留主鏈路，旁支鏈路異步化。這會(huì)導(dǎo)致一次被動(dòng)讀磁盤，性能損耗會(huì)很大。
在并發(fā)量一定的情況下如何對(duì)系統(tǒng)響應(yīng)時(shí)間進(jìn)行詳細(xì)分析
分析步驟
1.1 在關(guān)鍵點(diǎn)位添加日志信息 -> 縮小目標(biāo)范圍
a) 主要函數(shù)耗時(shí)
b) 訪問外部系統(tǒng)耗時(shí)：DB、MQ、Cache、FileSystem、RPC、HTTP等
c) 接口內(nèi)不同邏輯耗時(shí)百分比/絕對(duì)值
1.2 詳細(xì)分析瓶頸出現(xiàn)原因
a) 技術(shù)層面：優(yōu)先考慮
b) 業(yè)務(wù)邏輯：業(yè)務(wù)邏輯改造一般影響較大、耗時(shí)較長(zhǎng)，優(yōu)先級(jí)低
1.3 針對(duì)性解決問題
一旦定位了問題原因，解決問題的方法都相當(dāng)容易
技術(shù)層面
2.1 代碼實(shí)現(xiàn)
a) 串行邏輯是否可以并行化
b) 串行請(qǐng)求是否可以批量(batch)請(qǐng)求
c) SQL是否需要優(yōu)化
d) 算法復(fù)雜度是否需要優(yōu)化
e) 語言核心庫(kù)是否提供了性能更高的使用方式
f) 引用的第三方庫(kù)是否存在性能問題
g) 每次外部請(qǐng)求是否都重新建立連接
2.2 內(nèi)核/硬件層面
a) CPU使用率
b) 內(nèi)存使用率
c) 磁盤IO狀況
d) 網(wǎng)絡(luò)狀況
d) 瓶頸是否由調(diào)用的內(nèi)核函數(shù)引起？
該函數(shù)是如何工作的；新版本內(nèi)核是否已經(jīng)對(duì)此優(yōu)化；如何調(diào)整使用方式可以更高效
2.3 日志
線程會(huì)爭(zhēng)奪日志鎖，在高并發(fā)情況下，同步寫日志很影響性能。異步寫又可能引起OOM。
業(yè)務(wù)邏輯
隨著業(yè)務(wù)的增長(zhǎng)，接口負(fù)擔(dān)的功能原來越復(fù)雜，邏輯鏈路越來越長(zhǎng)，事務(wù)越來越大，性能越來越差，越來越?jīng)]辦法維護(hù)。（如果有人負(fù)責(zé)把控、從相對(duì)長(zhǎng)遠(yuǎn)些的角度設(shè)計(jì)系統(tǒng)的迭代，這種情況本是可以避免的）
優(yōu)化辦法只有一個(gè)就是：保留主鏈路，旁支鏈路異步化。
常用工具
4.1 內(nèi)核
a) CPU: top、vmstat htop w uptime dstat
b) MEM: top、free
c) disk IO: iostat
例: iostat -kx 1 //每秒統(tǒng)計(jì)一次io
iotop -o //查看磁盤使用率較高的進(jìn)程
d) 網(wǎng)絡(luò)
流量：sar -n DEV 1 3 //每秒統(tǒng)計(jì)一次所有網(wǎng)卡流量，共3次
網(wǎng)絡(luò)抓包: tmpdump，可配合tmptrace、wireshark分析
TCP連接狀況：netstat -an | grep TIME_WAIT //client端近期關(guān)閉tcp連接數(shù)量
e) 查看/proc/xxx中的系統(tǒng)詳細(xì)信息
小知識(shí)
a) 網(wǎng)絡(luò)抖動(dòng)引起tcp重傳，一般內(nèi)部系統(tǒng)之間的調(diào)用，linux設(shè)置的重傳時(shí)間間隔為至少200ms以上。
b) 服務(wù)之間通過網(wǎng)絡(luò)調(diào)用，網(wǎng)絡(luò)開銷在500us ~ 2ms
c) 機(jī)械磁盤尋址: 20ms
d) 磁盤的某page中如果存在數(shù)據(jù)，程序?qū)懘藀age時(shí)如果不會(huì)填充整個(gè)page，內(nèi)核會(huì)先載入整個(gè)page，再輸出整個(gè)page，保證磁盤數(shù)據(jù)不丟。這會(huì)導(dǎo)致一次被動(dòng)讀磁盤，性能損耗會(huì)很大。否則會(huì)直接寫入磁盤高速緩存，間隔固定時(shí)間刷盤一次(5s)。
e) 日志使用seaslog buffer
隨著系統(tǒng)并發(fā)量的增加，系統(tǒng)響應(yīng)時(shí)間會(huì)逐步下降甚至雪崩，一般是由多線程之間、模塊之間、子系統(tǒng)之間爭(zhēng)奪資源（鎖）引起的。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/62083.html
摘要：端優(yōu)談?wù)勱P(guān)于前端的緩存的問題我們都知道對(duì)頁面進(jìn)行緩存能夠有利于減少請(qǐng)求發(fā)送，從而達(dá)到對(duì)頁面的優(yōu)化。而作為一名有追求的前端，勢(shì)必要力所能及地優(yōu)化我們前端頁面的性能。這種方式主要解決了淺談前端中的過早優(yōu)化問題過早優(yōu)化是萬惡之源。 優(yōu)化向：?jiǎn)雾搼?yīng)用多路由預(yù)渲染指南 Ajax 技術(shù)的出現(xiàn)，讓我們的 Web 應(yīng)用能夠在不刷新的狀態(tài)下顯示不同頁面的內(nèi)容，這就是單頁應(yīng)用。在一個(gè)單頁應(yīng)用中，往往只有一...
摘要：在本文中我將會(huì)介紹應(yīng)用性能優(yōu)化的一般原則。性能優(yōu)化的流程圖摘取自和合著的性能，描述了應(yīng)用性能優(yōu)化的處理流程。例如，對(duì)每臺(tái)服務(wù)器，你面臨著為單個(gè)分配堆內(nèi)存和運(yùn)行個(gè)并為每個(gè)分配堆內(nèi)存的選擇。不過位能使用堆內(nèi)存最大理論值只有。 原文鏈接：http://www.cubrid.org/blog/dev-platform/the-principles-of-java-application-per...
摘要：淺談網(wǎng)站性能之前端性能優(yōu)化性能優(yōu)化的目的無非是減少用戶流量消耗，提升用戶首屏體驗(yàn)，提升用戶訪問速度，讓用戶專注內(nèi)容本身。前端性能優(yōu)化減少請(qǐng)求數(shù)量基本原理在瀏覽器與服務(wù)器進(jìn)行通信時(shí)，主要是通過進(jìn)行通信。 最近項(xiàng)目慢慢走上正軌，需求趨于平穩(wěn)，這才想起需要對(duì)整站進(jìn)行性能優(yōu)化。經(jīng)過一段時(shí)間的學(xué)習(xí)，結(jié)合現(xiàn)在項(xiàng)目的實(shí)際性能情況，發(fā)現(xiàn)確實(shí)有許多地方可以進(jìn)行優(yōu)化。于是就開始了我的前端性能優(yōu)化之旅。以下...
摘要：淺談網(wǎng)站性能之前端性能優(yōu)化性能優(yōu)化的目的無非是減少用戶流量消耗，提升用戶首屏體驗(yàn)，提升用戶訪問速度，讓用戶專注內(nèi)容本身。前端性能優(yōu)化減少請(qǐng)求數(shù)量基本原理在瀏覽器與服務(wù)器進(jìn)行通信時(shí)，主要是通過進(jìn)行通信。 最近項(xiàng)目慢慢走上正軌，需求趨于平穩(wěn)，這才想起需要對(duì)整站進(jìn)行性能優(yōu)化。經(jīng)過一段時(shí)間的學(xué)習(xí)，結(jié)合現(xiàn)在項(xiàng)目的實(shí)際性能情況，發(fā)現(xiàn)確實(shí)有許多地方可以進(jìn)行優(yōu)化。于是就開始了我的前端性能優(yōu)化之旅。以下...
閱讀 2432·2021-11-23 09:51
閱讀 1240·2021-11-22 13:54
閱讀 3468·2021-09-24 10:31
閱讀 1141·2021-08-16 10:46
閱讀 3669·2019-08-30 15:54
閱讀 731·2019-08-30 15:54
閱讀 2916·2019-08-29 17:17
閱讀 3194·2019-08-29 15:08
