對(duì)于不同類型的系統(tǒng)，軟件性能的關(guān)注點(diǎn)各不相同，比如：

• Web 類應(yīng)用和手機(jī)端應(yīng)用，一般以終端用戶感受到的端到端的響應(yīng)時(shí)間來(lái)描述系統(tǒng)的性能；
• 非交互式的應(yīng)用，比如典型的電信和銀行后臺(tái)處理系統(tǒng)，響應(yīng)時(shí)間關(guān)注更多的是事件處理的速度，以及單位時(shí)間的事件吞吐量。

從開(kāi)發(fā)人員視角關(guān)注軟件性能

在軟件設(shè)計(jì)開(kāi)發(fā)人員眼中，軟件性能通常會(huì)包含算法設(shè)計(jì)、架構(gòu)設(shè)計(jì)、性能最佳實(shí)踐、數(shù)據(jù)庫(kù)相關(guān)、軟件性能的可測(cè)試性這五大方面。其中，每個(gè)方面關(guān)注的點(diǎn)，也包括很多。

第一，算法設(shè)計(jì)包含的點(diǎn)：
核心算法的設(shè)計(jì)與實(shí)現(xiàn)是否高效；
必要時(shí)，設(shè)計(jì)上是否采用 buffer 機(jī)制以提高性能，降低 I/O；
是否存在潛在的內(nèi)存泄露；
是否存在并發(fā)環(huán)境下的線程安全問(wèn)題；
是否存在不合理的線程同步方式；
是否存在不合理的資源競(jìng)爭(zhēng)。

第二，架構(gòu)設(shè)計(jì)包含的內(nèi)容：
站在整體系統(tǒng)的角度，是否可以方便地進(jìn)行系統(tǒng)容量和性能擴(kuò)展；
應(yīng)用集群的可擴(kuò)展性是否經(jīng)過(guò)測(cè)試和驗(yàn)證；
緩存集群的可擴(kuò)展性是否經(jīng)過(guò)測(cè)試和驗(yàn)證；
數(shù)據(jù)庫(kù)的可擴(kuò)展性是否經(jīng)過(guò)測(cè)試和驗(yàn)證。

第三，性能最佳實(shí)踐包含的點(diǎn)：
代碼實(shí)現(xiàn)是否遵守開(kāi)發(fā)語(yǔ)言的性能最佳實(shí)踐；
關(guān)鍵代碼是否在白盒級(jí)別進(jìn)行性能測(cè)試；
是否考慮前端性能的優(yōu)化；
必要的時(shí)候是否采用數(shù)據(jù)壓縮傳輸；
對(duì)于既要壓縮又要加密的場(chǎng)景，是否采用先壓縮后加密的順序。

第四，數(shù)據(jù)庫(kù)相關(guān)的點(diǎn)：
數(shù)據(jù)庫(kù)表設(shè)計(jì)是否高效；
是否引入必要的索引；
SQL 語(yǔ)句的執(zhí)行計(jì)劃是否合理；
SQL 語(yǔ)句除了功能是否要考慮性能要求；
數(shù)據(jù)庫(kù)是否需要引入讀寫(xiě)分離機(jī)制；
系統(tǒng)冷啟動(dòng)后，緩存大量不命中的時(shí)候，數(shù)據(jù)庫(kù)承載的壓力是否超負(fù)荷。

第五，軟件性能的可測(cè)試性包含的點(diǎn)：
是否為性能分析（Profiler）提供必要的接口支持；
是否支持高并發(fā)場(chǎng)景下的性能打點(diǎn)；
是否支持全鏈路的性能分析。

性能測(cè)試常用衡量指標(biāo)

并發(fā)用戶數(shù)

• 業(yè)務(wù)層面的并發(fā)用戶數(shù)，指的是實(shí)際使用系統(tǒng)的用戶總數(shù)。但是單靠這個(gè)指標(biāo)并不能反映系統(tǒng)實(shí)際承載的壓力，我們還要結(jié)合用戶行為模型才能得到系統(tǒng)實(shí)際承載的壓力。
• 后端服務(wù)器層面的并發(fā)用戶數(shù)，指的是“同時(shí)向服務(wù)器發(fā)送請(qǐng)求的數(shù)量”，直接反映了系統(tǒng)實(shí)際承載的壓力。

場(chǎng)景舉例：
一個(gè)已經(jīng)投入運(yùn)行的 ERP 系統(tǒng)，該系統(tǒng)所在企業(yè)共有 5000 名員工并都擁有賬號(hào)，也就是說(shuō)這個(gè)系統(tǒng)有 5000 個(gè)潛在用戶。根據(jù)系統(tǒng)日志分析得知，該系統(tǒng)最大在線用戶數(shù)是 2500 人。

業(yè)務(wù)層面的并發(fā)用戶數(shù)=2500人 （此數(shù)值僅僅表明在最高峰時(shí)段有 2500 個(gè)用戶登錄了系統(tǒng)，而服務(wù)器所承受的實(shí)際壓力取決于登錄用戶行為，所以它不能準(zhǔn)確反映服務(wù)器此時(shí)此刻實(shí)際承載的壓力）

用戶行為分析建模：
假設(shè)在某一時(shí)間點(diǎn)上，這 2500 個(gè)用戶中，30% 用戶處于頁(yè)面瀏覽狀態(tài)（對(duì)服務(wù)器沒(méi)有發(fā)起請(qǐng)求），20% 用戶在填寫(xiě)訂單（也沒(méi)有對(duì)服務(wù)器發(fā)起請(qǐng)求），5% 用戶在遞交訂單，15% 用戶在查詢訂單，而另外的 30% 用戶沒(méi)有進(jìn)行任何操作。

后端服務(wù)器層面的并發(fā)用戶數(shù)=500人（這 2500 個(gè)“并發(fā)用戶”中真正對(duì)服務(wù)器產(chǎn)生壓力的只有 500 個(gè)用戶（（5%+15%）*2500=500））。

從這個(gè)例子可以看出，后端服務(wù)器層面的并發(fā)用戶數(shù)，同時(shí)取決于業(yè)務(wù)層面并發(fā)用戶數(shù)和用戶行為模式，而且用戶行為模式占的比重較大。因此，分析得到準(zhǔn)確的用戶行為模式，是性能測(cè)試中的關(guān)鍵一環(huán)。獲得精準(zhǔn)的用戶行為模式，是除了獲取性能需求外，最困難的工作。

響應(yīng)時(shí)間 RT

RT：處理一次請(qǐng)求所需要的平均處理時(shí)間
響應(yīng)時(shí)間是終端用戶對(duì)系統(tǒng)性能的最直觀印象，包括系統(tǒng)響應(yīng)時(shí)間和前端展現(xiàn)時(shí)間

• 系統(tǒng)響應(yīng)時(shí)間又可以進(jìn)一步細(xì)分為后臺(tái)系統(tǒng)處理時(shí)間、數(shù)據(jù)庫(kù)處理時(shí)間和網(wǎng)絡(luò)傳輸時(shí)間等；
• 前端展現(xiàn)時(shí)間，取決于客戶端收到服務(wù)器返回的數(shù)據(jù)后渲染頁(yè)面所消耗的時(shí)間

系統(tǒng)吞吐率 TPS

TPS：每秒鐘處理完的事務(wù)次數(shù)，即吞吐率；一般TPS是對(duì)整個(gè)系統(tǒng)來(lái)講的。一個(gè)應(yīng)用系統(tǒng)1s能完成多少事務(wù)處理，一個(gè)事務(wù)在分布式處理中，可能會(huì)對(duì)應(yīng)多個(gè)請(qǐng)求，對(duì)于衡量單個(gè)接口服務(wù)的處理能力，用QPS比較多

QPS

QPS: 服務(wù)器一秒鐘處理完請(qǐng)求的數(shù)量；注意這里是處理完。具體是指發(fā)出請(qǐng)求到服務(wù)器處理完成功返回結(jié)果。可以理解在server中有個(gè)counter，每處理一個(gè)請(qǐng)求加1，1秒后 counter=QPS
計(jì)算公式：QPS = 并發(fā)用戶數(shù) / 平均響應(yīng)時(shí)間

舉個(gè)列子：
如果一次性可以處理100個(gè)請(qǐng)求并發(fā)量，每個(gè)請(qǐng)求耗時(shí)100毫秒，則qps = 1000
如果一次性可以處理50個(gè)請(qǐng)求并發(fā)量，每個(gè)請(qǐng)求耗時(shí)200毫秒，則qps = 250
所以QPS與單個(gè)請(qǐng)求處理時(shí)間以及服務(wù)器一次性可以處理多少請(qǐng)求是成比例關(guān)系的

部分內(nèi)容參考極客時(shí)間: https://time.geekbang.org/column/article/14577#previewimg