1. 項(xiàng)目概述為什么我們需要關(guān)注“Performance”如果你在IT運(yùn)維、軟件開(kāi)發(fā)或者系統(tǒng)管理的崗位上待過(guò)一段時(shí)間那么“Performance”性能這個(gè)詞對(duì)你來(lái)說(shuō)絕對(duì)不是一個(gè)陌生的概念。它就像懸在頭頂?shù)倪_(dá)摩克利斯之劍平時(shí)風(fēng)平浪靜一旦出現(xiàn)問(wèn)題輕則應(yīng)用卡頓、用戶(hù)抱怨重則服務(wù)宕機(jī)、業(yè)務(wù)中斷。我處理過(guò)太多因?yàn)樾阅芷款i導(dǎo)致的深夜告警也見(jiàn)過(guò)不少團(tuán)隊(duì)在問(wèn)題爆發(fā)后才手忙腳亂地開(kāi)始“救火”。所以今天我想和你深入聊聊“Performance”這個(gè)話(huà)題它遠(yuǎn)不止是一個(gè)指標(biāo)而是一套從認(rèn)知、監(jiān)控、分析到優(yōu)化的完整方法論。簡(jiǎn)單來(lái)說(shuō)Performance指的是一個(gè)系統(tǒng)、應(yīng)用或組件在特定負(fù)載和環(huán)境下完成其預(yù)期功能的能力和效率。它通常通過(guò)一系列可量化的指標(biāo)來(lái)衡量比如響應(yīng)時(shí)間、吞吐量、資源利用率CPU、內(nèi)存、磁盤(pán)I/O、網(wǎng)絡(luò)和并發(fā)用戶(hù)數(shù)等。理解并掌握Performance意味著你能提前發(fā)現(xiàn)系統(tǒng)的“阿喀琉斯之踵”在用戶(hù)感知到問(wèn)題之前就將其解決從而保障服務(wù)的穩(wěn)定、流暢和可靠。無(wú)論是面對(duì)“無(wú)法讀取 usbperf\performance 注冊(cè)表項(xiàng)”這樣的底層系統(tǒng)錯(cuò)誤還是分析“CPU或數(shù)據(jù)庫(kù)性能是否為瓶頸”這樣的高層架構(gòu)問(wèn)題一套清晰的性能管理思路都是你手中最有力的工具。2. 性能管理的核心維度與指標(biāo)體系要管理性能首先得知道看什么。性能是一個(gè)多維度的概念不能只盯著CPU使用率一個(gè)數(shù)字。我們需要建立一個(gè)立體的監(jiān)控視角。2.1 四大核心性能維度響應(yīng)時(shí)間這是用戶(hù)最能直接感知的指標(biāo)。它指的是從發(fā)起一個(gè)請(qǐng)求到接收到完整響應(yīng)所花費(fèi)的時(shí)間。例如一個(gè)網(wǎng)頁(yè)加載完成需要2秒一個(gè)API接口返回?cái)?shù)據(jù)需要200毫秒。響應(yīng)時(shí)間又可細(xì)分為網(wǎng)絡(luò)時(shí)間請(qǐng)求在網(wǎng)絡(luò)中傳輸?shù)暮臅r(shí)。服務(wù)器處理時(shí)間應(yīng)用服務(wù)器執(zhí)行邏輯、訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)等所花費(fèi)的時(shí)間。前端渲染時(shí)間瀏覽器解析HTML、CSS執(zhí)行JavaScript并繪制頁(yè)面的時(shí)間。 一個(gè)健康的系統(tǒng)其響應(yīng)時(shí)間應(yīng)在可接受的范圍內(nèi)保持穩(wěn)定。突然的飆升或持續(xù)高位往往是問(wèn)題的征兆。吞吐量指系統(tǒng)在單位時(shí)間內(nèi)成功處理的請(qǐng)求數(shù)量或數(shù)據(jù)量。常見(jiàn)單位有請(qǐng)求數(shù)/秒RPS/QPS、事務(wù)數(shù)/秒TPS、字節(jié)/秒。吞吐量反映了系統(tǒng)的處理能力。在高并發(fā)場(chǎng)景下吞吐量會(huì)先隨著并發(fā)數(shù)上升而上升達(dá)到一個(gè)峰值后可能會(huì)因?yàn)橄到y(tǒng)資源飽和而下降或響應(yīng)時(shí)間急劇惡化這個(gè)峰值點(diǎn)就是系統(tǒng)的性能極限。資源利用率這是洞察系統(tǒng)內(nèi)部狀態(tài)的窗口。主要關(guān)注CPU利用率如果持續(xù)高于70%-80%可能意味著計(jì)算密集型任務(wù)過(guò)載或存在低效代碼。內(nèi)存利用率需要關(guān)注使用量以及Swap交換分區(qū)的使用情況。頻繁的Swap交換會(huì)嚴(yán)重拖慢系統(tǒng)。磁盤(pán)I/O包括讀寫(xiě)速率MB/s和IOPS每秒輸入輸出操作次數(shù)。高延遲或長(zhǎng)時(shí)間的等待隊(duì)列await是磁盤(pán)瓶頸的典型表現(xiàn)。網(wǎng)絡(luò)I/O帶寬使用率、數(shù)據(jù)包吞吐量以及錯(cuò)誤率/丟包率。并發(fā)用戶(hù)數(shù)同時(shí)與系統(tǒng)進(jìn)行交互的用戶(hù)數(shù)量。這個(gè)指標(biāo)通常與響應(yīng)時(shí)間、吞吐量結(jié)合分析用于進(jìn)行壓力測(cè)試和容量規(guī)劃。2.2 建立有效的性能基線(xiàn)在討論“性能好”或“性能差”之前必須有一個(gè)參照物這就是性能基線(xiàn)。基線(xiàn)是系統(tǒng)在正常、平穩(wěn)運(yùn)行狀態(tài)下的各項(xiàng)性能指標(biāo)范圍。例如你的Web應(yīng)用在平時(shí)工作日的性能基線(xiàn)可能是平均響應(yīng)時(shí)間500msCPU利用率40%數(shù)據(jù)庫(kù)連接數(shù)50。建立基線(xiàn)的方法很簡(jiǎn)單在系統(tǒng)無(wú)故障、負(fù)載典型的時(shí)期例如一周持續(xù)收集上述核心指標(biāo)。這個(gè)基線(xiàn)將成為你判斷性能是否異常的“標(biāo)尺”。任何指標(biāo)持續(xù)、顯著地偏離基線(xiàn)都值得深入調(diào)查。沒(méi)有基線(xiàn)所有的性能數(shù)據(jù)都只是孤立的數(shù)字無(wú)法形成有效判斷。3. 性能分析實(shí)戰(zhàn)從現(xiàn)象到根因的排查路徑當(dāng)性能問(wèn)題發(fā)生時(shí)告警信息往往只是一個(gè)表象比如“CPU使用率過(guò)高”或“接口超時(shí)率上升”。真正的挑戰(zhàn)在于如何像偵探一樣順著線(xiàn)索找到根本原因。下面我分享一個(gè)通用的、自上而下的排查路徑。3.1 問(wèn)題定位與分層排查法一個(gè)典型的在線(xiàn)應(yīng)用請(qǐng)求會(huì)經(jīng)過(guò)“用戶(hù)端 - 網(wǎng)絡(luò) - 負(fù)載均衡/網(wǎng)關(guān) - 應(yīng)用服務(wù)器 - 緩存/中間件 - 數(shù)據(jù)庫(kù)/外部服務(wù)”等多個(gè)環(huán)節(jié)。性能問(wèn)題可能出現(xiàn)在其中任何一環(huán)。高效的排查需要逐層縮小范圍。確定問(wèn)題范圍是單個(gè)用戶(hù)的問(wèn)題還是所有用戶(hù)都受影響是某個(gè)特定功能慢還是整個(gè)系統(tǒng)都慢這能幫你快速判斷是全局性資源瓶頸還是局部代碼/配置問(wèn)題。檢查外部依賴(lài)查看上游負(fù)載均衡器、CDN、DNS的健康狀態(tài)和監(jiān)控指標(biāo)。網(wǎng)絡(luò)丟包、延遲激增都可能導(dǎo)致前端響應(yīng)變慢。分析應(yīng)用服務(wù)器檢查系統(tǒng)資源使用top,htop,vmstat,iostat等命令快速查看CPU、內(nèi)存、磁盤(pán)I/O的實(shí)時(shí)狀態(tài)。top命令看哪個(gè)進(jìn)程占用CPU高vmstat 1查看系統(tǒng)層面的進(jìn)程、內(nèi)存、交換分區(qū)、IO和CPU活動(dòng)iostat -xz 1查看磁盤(pán)利用率、等待時(shí)間和吞吐量。分析應(yīng)用日志查看應(yīng)用錯(cuò)誤日志、慢查詢(xún)?nèi)罩救绻婕皵?shù)據(jù)庫(kù)、GC日志對(duì)于Java應(yīng)用。錯(cuò)誤堆棧和超時(shí)記錄是寶貴的線(xiàn)索。深入數(shù)據(jù)庫(kù)與中間件數(shù)據(jù)庫(kù)這是最常見(jiàn)的性能瓶頸點(diǎn)。使用SHOW PROCESSLIST;MySQL或pg_stat_activityPostgreSQL查看當(dāng)前正在執(zhí)行的慢查詢(xún)。分析執(zhí)行計(jì)劃EXPLAIN檢查是否缺少索引、是否全表掃描。緩存/消息隊(duì)列檢查Redis的內(nèi)存使用率、命中率、連接數(shù)檢查Kafka的堆積延遲、分區(qū)負(fù)載是否均衡。3.2 常見(jiàn)性能瓶頸場(chǎng)景與工具使用CPU瓶頸表現(xiàn)為%us用戶(hù)態(tài)CPU或%sy系統(tǒng)態(tài)CPU持續(xù)高位。排查工具top/htop定位進(jìn)程perfLinux可以進(jìn)行CPU性能剖析jstackJava可以抓取線(xiàn)程堆棧分析熱點(diǎn)代碼?？赡茉驘o(wú)限循環(huán)、低效算法、序列化/反序列化操作過(guò)頻、頻繁的GC對(duì)于Java。內(nèi)存瓶頸表現(xiàn)為可用內(nèi)存不足可能開(kāi)始使用Swap。排查工具free -h,vmstat,jmapJava堆內(nèi)存分析?？赡茉騼?nèi)存泄漏對(duì)象未被GC回收、緩存數(shù)據(jù)無(wú)限增長(zhǎng)、JVM堆內(nèi)存配置不合理。磁盤(pán)I/O瓶頸表現(xiàn)為%util磁盤(pán)利用率高await平均等待時(shí)間長(zhǎng)。排查工具iostat -xz 1,iotop。可能原因大量日志寫(xiě)入、數(shù)據(jù)庫(kù)未優(yōu)化的大量隨機(jī)寫(xiě)、磁盤(pán)本身性能不足如機(jī)械硬盤(pán)跑數(shù)據(jù)庫(kù)。數(shù)據(jù)庫(kù)瓶頸表現(xiàn)為應(yīng)用響應(yīng)慢但應(yīng)用服務(wù)器資源并不緊張。排查工具數(shù)據(jù)庫(kù)自身的慢查詢(xún)?nèi)罩尽⒈O(jiān)控面板如MySQL的Performance Schema, Prometheus Grafana?？赡茉蛉鄙儆行饕QL語(yǔ)句寫(xiě)得差如SELECT *、表鎖或行鎖競(jìng)爭(zhēng)、連接池配置過(guò)小。實(shí)操心得遇到“無(wú)法讀取 usbperf\performance 注冊(cè)表項(xiàng)下的‘first counter’值”這類(lèi)Windows系統(tǒng)性能計(jì)數(shù)器錯(cuò)誤時(shí)這通常意味著性能計(jì)數(shù)器數(shù)據(jù)庫(kù)損壞?？梢試L試以管理員身份打開(kāi)命令行運(yùn)行l(wèi)odctr /R命令來(lái)重建性能計(jì)數(shù)器。這類(lèi)問(wèn)題雖然不常見(jiàn)但一旦出現(xiàn)會(huì)導(dǎo)致依賴(lài)系統(tǒng)性能計(jì)數(shù)器的監(jiān)控工具如某些APM代理無(wú)法正常工作知道這個(gè)快速修復(fù)命令能省去很多麻煩。4. 性能測(cè)試在問(wèn)題發(fā)生前主動(dòng)發(fā)現(xiàn)性能優(yōu)化不能只靠被動(dòng)響應(yīng)告警。主動(dòng)進(jìn)行性能測(cè)試模擬真實(shí)負(fù)載是評(píng)估系統(tǒng)能力、發(fā)現(xiàn)潛在瓶頸的必備手段。性能測(cè)試主要分為以下幾類(lèi)4.1 性能測(cè)試的類(lèi)型與目標(biāo)負(fù)載測(cè)試在預(yù)期的正常負(fù)載下測(cè)試系統(tǒng)的性能表現(xiàn)驗(yàn)證是否滿(mǎn)足性能需求。目標(biāo)是確認(rèn)系統(tǒng)在基線(xiàn)負(fù)載下的行為。壓力測(cè)試逐步增加負(fù)載直到超過(guò)系統(tǒng)預(yù)期容量找到系統(tǒng)的性能拐點(diǎn)和極限。目標(biāo)是找出系統(tǒng)在什么情況下會(huì)崩潰以及如何崩潰。耐力測(cè)試在穩(wěn)定、中高負(fù)載下長(zhǎng)時(shí)間如12-24小時(shí)運(yùn)行系統(tǒng)檢查是否有內(nèi)存泄漏、資源逐漸耗盡等問(wèn)題。目標(biāo)是驗(yàn)證系統(tǒng)的穩(wěn)定性。尖峰測(cè)試短時(shí)間內(nèi)突然施加遠(yuǎn)高于平均水平的負(fù)載模擬促銷(xiāo)、熱點(diǎn)新聞等場(chǎng)景測(cè)試系統(tǒng)的彈性恢復(fù)能力。4.2 測(cè)試工具選型與實(shí)戰(zhàn)步驟市面上性能測(cè)試工具很多從開(kāi)源的JMeter、k6、Gatling到商業(yè)的LoadRunner。對(duì)于大多數(shù)Web應(yīng)用和API服務(wù)JMeter因其功能強(qiáng)大、社區(qū)活躍、免費(fèi)開(kāi)源是一個(gè)極佳的起點(diǎn)。使用JMeter進(jìn)行一次基礎(chǔ)壓力測(cè)試的步驟創(chuàng)建測(cè)試計(jì)劃打開(kāi)JMeter新建一個(gè)“測(cè)試計(jì)劃”。添加線(xiàn)程組線(xiàn)程組定義了虛擬用戶(hù)的數(shù)量、啟動(dòng)時(shí)間和循環(huán)次數(shù)。例如設(shè)置“線(xiàn)程數(shù)”為100“Ramp-Up時(shí)間”為10秒表示在10秒內(nèi)啟動(dòng)所有100個(gè)用戶(hù)“循環(huán)次數(shù)”為永遠(yuǎn)。配置HTTP請(qǐng)求在線(xiàn)程組下添加“HTTP請(qǐng)求”采樣器。填寫(xiě)服務(wù)器名稱(chēng)、端口、路徑如/api/v1/users以及請(qǐng)求方法GET/POST等。如果需要傳遞參數(shù)或JSON body在相應(yīng)標(biāo)簽頁(yè)中配置。添加監(jiān)聽(tīng)器為了查看結(jié)果需要添加監(jiān)聽(tīng)器。常用的有查看結(jié)果樹(shù)用于調(diào)試查看每個(gè)請(qǐng)求和響應(yīng)的詳情正式壓測(cè)時(shí)應(yīng)禁用因?yàn)樗浅Ｏ膬?nèi)存。聚合報(bào)告提供所有請(qǐng)求的統(tǒng)計(jì)摘要包括平均響應(yīng)時(shí)間、中位數(shù)、吞吐量、錯(cuò)誤率等這是分析的核心。用表格查看結(jié)果以表格形式展示每個(gè)樣本的結(jié)果。圖形結(jié)果以圖表形式展示響應(yīng)時(shí)間、吞吐量隨時(shí)間的變化。執(zhí)行測(cè)試并分析點(diǎn)擊運(yùn)行按鈕開(kāi)始測(cè)試。觀察聚合報(bào)告中的關(guān)鍵指標(biāo)吞吐量是否達(dá)到預(yù)期平均響應(yīng)時(shí)間/中位數(shù)是否在可接受范圍內(nèi)錯(cuò)誤率是否為0如果有錯(cuò)誤通過(guò)結(jié)果樹(shù)或日志排查原因。關(guān)注隨著線(xiàn)程數(shù)增加吞吐量是否線(xiàn)性增長(zhǎng)響應(yīng)時(shí)間是否平穩(wěn)當(dāng)吞吐量不再增長(zhǎng)而響應(yīng)時(shí)間急劇上升時(shí)就找到了當(dāng)前配置下的性能瓶頸點(diǎn)。注意事項(xiàng)性能測(cè)試環(huán)境應(yīng)盡量與生產(chǎn)環(huán)境隔離但硬件配置、網(wǎng)絡(luò)拓?fù)?、軟件版本?yīng)盡可能相似否則測(cè)試結(jié)果沒(méi)有參考價(jià)值。壓測(cè)前務(wù)必清理測(cè)試數(shù)據(jù)確保每次測(cè)試起點(diǎn)一致。同時(shí)要監(jiān)控測(cè)試機(jī)本身的資源CPU、網(wǎng)絡(luò)避免測(cè)試機(jī)成為瓶頸導(dǎo)致結(jié)果失真。5. 系統(tǒng)性性能優(yōu)化策略與案例找到瓶頸只是第一步如何優(yōu)化才是體現(xiàn)功力的地方。優(yōu)化需要遵循“測(cè)量 - 分析 - 優(yōu)化 - 再測(cè)量”的循環(huán)并且要有成本意識(shí)。5.1 優(yōu)化層次與常用手段性能優(yōu)化可以從上到下從成本低、見(jiàn)效快的層面開(kāi)始架構(gòu)與設(shè)計(jì)層成本最高但收益可能最大緩存策略引入Redis、Memcached等緩存高頻讀取、計(jì)算復(fù)雜但變化不頻繁的數(shù)據(jù)。牢記緩存雪崩、擊穿、穿透的應(yīng)對(duì)方案。異步化將非實(shí)時(shí)必需的操作如發(fā)送通知、記錄日志通過(guò)消息隊(duì)列如Kafka、RocketMQ異步處理縮短請(qǐng)求主鏈路響應(yīng)時(shí)間。讀寫(xiě)分離與分庫(kù)分表數(shù)據(jù)庫(kù)壓力大時(shí)考慮主從讀寫(xiě)分離。數(shù)據(jù)量極大時(shí)考慮分庫(kù)分表。靜態(tài)資源優(yōu)化使用CDN加速圖片、JS、CSS等靜態(tài)資源的加載。代碼與算法層避免N1查詢(xún)?cè)贠RM框架中尤其常見(jiàn)使用聯(lián)表查詢(xún)或批量查詢(xún)代替循環(huán)中的單條查詢(xún)。選擇合適的數(shù)據(jù)結(jié)構(gòu)與算法在數(shù)據(jù)量大時(shí)一個(gè)O(n2)的算法足以拖垮整個(gè)服務(wù)。減少不必要的序列化/反序列化特別是在微服務(wù)間調(diào)用時(shí)。連接池化數(shù)據(jù)庫(kù)連接、HTTP客戶(hù)端連接等務(wù)必使用連接池管理。數(shù)據(jù)庫(kù)層索引優(yōu)化為查詢(xún)條件中的字段添加索引但注意索引不是越多越好它會(huì)降低寫(xiě)速度。使用EXPLAIN分析執(zhí)行計(jì)劃。SQL優(yōu)化避免SELECT *只取需要的字段優(yōu)化子查詢(xún)和JOIN注意大數(shù)據(jù)量下的分頁(yè)查詢(xún)效率避免使用LIMIT M, N深度分頁(yè)。合理設(shè)計(jì)表結(jié)構(gòu)遵循范式但有時(shí)為了性能也需要適當(dāng)?shù)姆捶妒皆O(shè)計(jì)如冗余字段。系統(tǒng)與資源配置層JVM調(diào)優(yōu)針對(duì)Java應(yīng)用合理設(shè)置堆內(nèi)存大小-Xms,-Xmx、新生代與老年代比例、選擇合適的垃圾收集器如G1。操作系統(tǒng)參數(shù)調(diào)優(yōu)調(diào)整Linux內(nèi)核參數(shù)如TCP緩沖區(qū)大小、文件描述符數(shù)量、虛擬內(nèi)存管理參數(shù)等。硬件升級(jí)最直接但成本也最高的方式包括使用更快的CPU、SSD硬盤(pán)、更大的內(nèi)存。5.2 一個(gè)真實(shí)的優(yōu)化案例慢查詢(xún)治理我曾遇到一個(gè)后臺(tái)管理系統(tǒng)在導(dǎo)出大量數(shù)據(jù)報(bào)表時(shí)頁(yè)面經(jīng)常超時(shí)。排查過(guò)程如下現(xiàn)象導(dǎo)出功能響應(yīng)時(shí)間超過(guò)120秒前端報(bào)超時(shí)錯(cuò)誤。應(yīng)用服務(wù)器CPU和內(nèi)存正常。排查查看應(yīng)用日志發(fā)現(xiàn)該導(dǎo)出操作對(duì)應(yīng)的SQL執(zhí)行時(shí)間長(zhǎng)達(dá)110秒。在數(shù)據(jù)庫(kù)端執(zhí)行該SQL確認(rèn)非常慢。分析使用EXPLAIN分析該SQL發(fā)現(xiàn)它涉及三張表關(guān)聯(lián)且其中一張大表千萬(wàn)級(jí)沒(méi)有在關(guān)聯(lián)字段上建立索引導(dǎo)致全表掃描。同時(shí)SQL中使用了SELECT *而實(shí)際只需要其中5個(gè)字段。優(yōu)化在關(guān)聯(lián)字段上添加了復(fù)合索引。將SQL改為只查詢(xún)需要的字段SELECT field1, field2...。與業(yè)務(wù)方溝通為導(dǎo)出功能增加了時(shí)間范圍限制避免一次性拉取全部歷史數(shù)據(jù)。結(jié)果優(yōu)化后同樣的導(dǎo)出操作SQL執(zhí)行時(shí)間從110秒降至不到2秒頁(yè)面導(dǎo)出功能恢復(fù)正常。這個(gè)案例告訴我們數(shù)據(jù)庫(kù)索引和SQL語(yǔ)句的優(yōu)化往往是性?xún)r(jià)比最高的性能提升手段。6. 構(gòu)建持續(xù)的性能管理體系性能管理不應(yīng)該是一次性的運(yùn)動(dòng)而應(yīng)該融入研發(fā)和運(yùn)維的日常流程形成一個(gè)閉環(huán)。6.1 監(jiān)控告警體系搭建你需要一個(gè)7x24小時(shí)的眼睛來(lái)盯著系統(tǒng)。現(xiàn)代監(jiān)控體系通常包括基礎(chǔ)設(shè)施監(jiān)控使用Zabbix、Prometheus Node Exporter監(jiān)控服務(wù)器、虛擬機(jī)、容器的CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)等指標(biāo)。應(yīng)用性能監(jiān)控使用APM工具如SkyWalking、Pinpoint、或商業(yè)產(chǎn)品監(jiān)控應(yīng)用內(nèi)部方法調(diào)用鏈、SQL執(zhí)行時(shí)間、外部調(diào)用耗時(shí)等實(shí)現(xiàn)代碼級(jí)別的可觀測(cè)性。日志集中分析使用ELK Stack或Loki收集和分析應(yīng)用日志、業(yè)務(wù)日志便于故障排查。用戶(hù)體驗(yàn)監(jiān)控使用Google Analytics、或自建前端監(jiān)控收集真實(shí)用戶(hù)的頁(yè)面加載時(shí)間、操作耗時(shí)等。為關(guān)鍵指標(biāo)設(shè)置合理的告警閾值基于之前建立的性能基線(xiàn)并通過(guò)郵件、釘釘、企業(yè)微信等渠道及時(shí)通知到人。6.2 性能門(mén)禁與容量規(guī)劃性能門(mén)禁在CI/CD流水線(xiàn)中集成性能測(cè)試。每次代碼合并前自動(dòng)運(yùn)行一套核心接口的性能測(cè)試用例如果關(guān)鍵指標(biāo)如平均響應(yīng)時(shí)間、錯(cuò)誤率劣化超過(guò)一定比例則阻止合并。這能將性能問(wèn)題扼殺在萌芽階段。容量規(guī)劃基于歷史流量增長(zhǎng)趨勢(shì)和業(yè)務(wù)目標(biāo)如預(yù)計(jì)下個(gè)季度用戶(hù)增長(zhǎng)50%通過(guò)性能測(cè)試數(shù)據(jù)推算出未來(lái)需要多少服務(wù)器資源、數(shù)據(jù)庫(kù)讀寫(xiě)能力需要提升多少。避免業(yè)務(wù)增長(zhǎng)時(shí)系統(tǒng)因容量不足而崩潰。性能的世界沒(méi)有銀彈它是一個(gè)需要持續(xù)投入、不斷學(xué)習(xí)和精細(xì)調(diào)整的領(lǐng)域。從建立正確的認(rèn)知開(kāi)始到搭建監(jiān)控、制定流程每一次對(duì)性能問(wèn)題的成功排查和優(yōu)化不僅提升了系統(tǒng)的穩(wěn)定性也加深了你對(duì)系統(tǒng)內(nèi)在運(yùn)行邏輯的理解。記住最好的性能問(wèn)題是那些在發(fā)生之前就被你預(yù)見(jiàn)并解決掉的問(wèn)題。