軟件系統性能常見方法論? 在IT行業的發展過程中，先有傳統行業，後出現了互聯網行業傳統行業的特點為：業務抽象度高，重用率高，流程複雜，中心化管理互聯網行業的特點為：業務水平，垂直拆分，模塊化，職責單一，功能簡單，敏捷交付，非功能性質量要求高，我來為大家科普一下關于軟件系統性能常見方法論?下面希望有你要的答案，我們一起來看看吧!

軟件系統性能常見方法論

在IT行業的發展過程中，先有傳統行業，後出現了互聯網行業。傳統行業的特點為：業務抽象度高，重用率高，流程複雜，中心化管理。互聯網行業的特點為：業務水平，垂直拆分，模塊化，職責單一，功能簡單，敏捷交付，非功能性質量要求高。

通常軟件架構設計分為需求分析整理，概要設計，詳細設計三個階段，每個階段任務如下：

• 需求分析整理階段：針對用例和場景，抽象出系統面向的用戶和角色。梳理用戶和角色應該提供的功能需求，非功能質量需求和限制。
• 概要設計階段： 基于需求對整個系統進行模塊劃分，并定義模塊之間的關系和交互。
• 詳細設計：通過視圖的方式來描述系統架構。視圖包括：數據視圖，邏輯視圖，開發視圖，進程視圖，物理視圖，性能視圖，安全視圖。

一. 架構權衡分析法（ATAM）

架構權衡分析法（Architecture Tradeoff Analysis Method,ATAM）為行業通用的實踐方法,該方法揭示架構滿足特定質量目标的情況，使得我們認識到目标與質量之間的權衡和制約。通用的非功能質量指标包括：高可用，高性能，可伸縮，可擴展，安全性，穩定性，可維護性，可測試性，健壯性等。

非功能性質量需求的具體指标針對不同的系統主要分4部分：應用服務器，數據庫，緩存和消息隊列。

1. 應用服務器

2. 數據庫

關注吞吐量，每天數據總量

3. 緩存

根據應用層的訪問量和訪問峰值，通過評估熱數據的占比，計算緩存資源的大小并估算緩存資源的峰值，由此來計算緩存資源的數量，部署結構，高可用方案等。

4. 消息隊列

二. 技術評審提綱

• 現狀

1. 業務背景：項目名稱，業務描述
2. 技術背景：架構描述，當前系統容量（系統調用量的平均值，請求響應時間的平均值，峰值，最大最小值等 ）

• 需求

1. 業務需求：要改造的内容，要實現的新需求

2. 性能需求：預估系統容量（預估系統調用量平均值，平均響應時間），安全性，可伸縮性。

• 方案描述

1.概述：一句話概括方案亮點：雙寫，遷移，主從分離，分庫分表，擴容，歸檔，接口改造。

2.詳細說明：結合各種視圖（UML,概念圖，框圖）表明改造方案，突出變動的地方。

• 中間件架構：應用服務器，數據庫，緩存，消息隊列
• 邏輯架構：模塊劃分，模塊通信，信息流，時序
• 數據架構：數據結構，數據分布，拆分策略，緩存策略，讀寫分離策略，查詢策略，數據一緻性策略。
• 異常處理，容災策略，灰度發布，上線方案，回滾方案。

3.性能評估

• 給出方案基準數據，并按性能需求評估需要使用的資源數量
• 單機并發量，容量，吞吐量峰值。
• 根據性能需求，評估資源數量，伸縮方式等部署結構。

• 方案的優點缺點，方案對比
• 風險評估
• 工作量評估

三. 系統評估案例

備注：如下數據基準僅做案例演示。

3.1 背景

數字家庭管理平台兩個質量需求。

• 1.第三方系統信息查詢，複位重啟接口頻繁調用。
• 2.ihdmgr，apmgr進行分布式部署，日志檢索耗時費力。

3.2 目标數據量級

• 智能網關，機頂盒，智能組網設備合計800萬，平均每天增長1.2萬。
• 平均每天裝，撤，拆，移工單2.4萬單，下單集中在8:00~19:00，占比80%。

3.3 量級評估标準

• 通用标準

容量：按照峰值的3倍進行冗餘設計。

業務開通容量：時效性較強，按照2年計算，轉儲設計。

第三方查詢接口：吞吐量為1000/S.

• mysql

單端口讀：1000/S

單端口寫：700/S

單表容量：5000萬條。

• Redis

單端口讀：40000/S

單端口寫：40000/S

單端口内存容量：32GB

• Kafka

單機讀：30000/S

單機寫：5000/S

• web 服務器

請求量的峰值：200/S

3.4 方案

方案一. 最大性能方案

無法預估第三方的調用行為，假設提供最快的響應時間，最大的服務性能。

• 整體流程：

提供RESTful 服務來查詢終端信息。

提供RESTful服務來重啟對應終端。

• 數據庫資源評估

• 讀操作吞吐量：

按照1%的終端用戶存在潛在查詢需求，且集中在9:00-19：00 這10個小時内。冗餘按照3倍設計。

（800w*0.01）/(10*60*60)*3=2.23*3=7/s

mysql單端口完全夠用。

• 寫操作吞吐量：

複位重啟後，10條參數需要重新下發，1%的終端用戶存在潛在複位重啟需求，且集中在9:00-19：00 這10個小時内。冗餘按照3倍設計。

（800w*0.01*10）/(10*60*60)*3=22.3*3=70/s

mysql 單端口完全夠用。

• 數據容量：

當前800萬用戶，1%複位重啟，每個用戶下發10條參數，3倍冗餘，單表容量5000萬，2年後下發參數條目數及所需表數量計算如下：

（800w*0.01*365*2年）*10條*3倍=17億條/0.5億=34張。

根據以上讀寫吞吐量評估，如果讀寫分離，主從部署，需要1主1從，如若考慮主備，則需要2主2從。34*2=68張表，考慮将來端口擴展不拆分數據庫，盡量設計更多的庫，比如使用16個庫。設計結果：2端口*16庫*2表。

• 緩存資源評估

為了提升查詢效率，需要redis緩存活躍終端的基本信息，定義近一天和平台有聯系的終端（40%）為活躍終端，緩存24小時，每條終端信息為1KB, 冗餘3倍設計，緩存大小計算如下：

800w*0.4*1KB=3.2GB*3=9.6G.

1台機器32G，讀寫滿足5000/S, 所以設計結果為1台。

• 應用服務器評估

根據數據庫讀寫7/S, 70/S的峰值計算，單台應用服務器即可，選擇兩台可避免單點故障。

設計結果2台。

所以最大性能設計方案最終需要服務器：

數據庫2台 緩存服務器1台 應用服務器1台=4台。

方案二. 最小資源方案

請求量暫時無法評估，最小資源方案可節省成本，目前測算單台容量足夠承載。

數據庫1台 應用服務器1台=2台。

四. 常用的系統層性能指标參考标準

• 寄存器和内存

1. 寄存器，L2,L3，内存，分支預測失敗，互斥量加鎖和解鎖等耗時為納秒級别
2. 内存随機讀取可達30萬次/s，順序讀取可達500萬次/s
3. 内存每秒可讀取GB級别的數據。
4. 讀取内存中1MB的數據為250ns，為亞毫秒級别。

• 硬盤

1. 普通SATA機械盤IOPS能達到120次/S
2. 普通SATA機械盤順序讀取數據可達100MB/S，讀取1MB 數據20ms
3. 普通SATA機械盤随機讀取數據可達2MB/S
4. 普通SATA機械盤旋轉半圈需要3ms
5. 普通SATA機械盤尋道需要3ms
6. 普通SATA機械盤尋道後開始讀取數據，讀取一次數據真正耗時2ms
7. fusionIO卡（一種高的ssd硬盤套件）可達到百萬級别的IOPS,
8. 高端機器如ibm，華為等服務器上的高端存儲設備，每秒GB級别的數據讀取，相當于内存的讀取速度。
9. 固态硬盤訪問延遲：0.1-0.2ms，和内存速度相當。

• 網絡IO

1. 常見千兆網卡傳輸速度為1000Mbit/S, 即128MB/S
2. 千兆網卡讀取1MB數據，10ms。

• 數據庫

1. 通常讀取一條記錄在毫秒級别，短則幾毫秒，大于500ms一般為超時。
2. mysql在4核心，256G内存中性價比最好，繼續垂直擴展由于體系結構限制，成本開始增加，性價比開始降低。

• IDC

1. 同一機房網絡來回：0.5ms
2. 異地機房來回：30~100ms
3. 同一機房RPC服務調用為幾個毫秒，500ms為超時。

• 網站：

1. UV:每日一共有多少用戶來訪，用cookie session跟蹤。
2. 獨立ip訪問：每日有多少獨立ip來訪，同一個局域網可以看成一個ip
3. pv：每日單獨用戶的所有頁面訪問量，如果每日uv為50000 000，那麼每秒平均在線人數為：50000 000/24/60/60=578人。如果每秒都做一次查詢，則需要一個能承載578/S吞吐量的機器。

• 組合計算：

1. 普通機械盤：3ms 旋轉 3ms 尋到 2ms讀取延遲=8ms
2. 普通sata機械盤每秒随機讀取：1000ms/8ms= 125次 IOPS.
3. IOPS代表每秒可随機尋址次數，随機讀取速度取決于數據如何存放，如果按照塊存放，每塊4KB，每次讀取10塊，那麼随機讀取速度為：10*4KB*125次/S=5MB/S
4. 一次讀取内存時間：1000ms/30萬次/S=3ns
5. cpu速度=10倍*内存速度=100倍*IO速度

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!