性能測試學習線路圖(建議)

時間 2019-11-08

標籤性能測試學習線路建議欄目系統性能简体版

原文原文鏈接

1 概覽

縱向劃分3顆子樹:vugen,controller,monitor。優先學習vugen腳本開發以及調試。html

橫向劃分爲2層：基礎知識以及高級應用。web

2 基礎知識

2.1 Loadrunner工具使用

2.1.1 建議學習路徑

Vugen開發腳本（函數使用）->controller場景設置->monitor增長計數器apache

http://www.cnblogs.com/jackei/archive/2006/10/20/534684.html編程

2.1.2 Loadrunner 認證

http://www.51testing.net/BWF_DIY/mercury/mercury_060104_11.htm性能優化

2.1.3 Vugen經常使用加強函數

增長事務:lr_start_transaction/:lr_end_transaction服務器

檢查點: web_reg_find網絡

關聯: web_reg_save_param ，web_set_max_html_param_lensession

日誌: lr_error_message，lr_log_message, lr_output_message …

選項設置: web_set_timeout

http header: web_add_auto_header

以及更改runtime setting。

2.1.4 Loadrunner 架構圖

概覽圖

詳細架構圖：

2.2 Html/http協議

HTML 4.01 Specification：

http://www.w3.org/TR/html4/

http://www.eygle.com/digest/2006/12/html_xml_and_internet.html

對性能測試而言，META http-equiv控制http頭、瀏覽器行爲，故最爲重要。

http協議:

http://www.faqs.org/rfcs/rfc2616.html

客戶端發送請求：

服務器響應：

2.3 C 語言基礎編程

Loadrunner經常使用的c函數主要集中在內存分配/釋放、字符串操做、文件讀寫。

如: malloc/free

Sprintf/strcmp/strlen/

Fopen/fread/fwrite

2.4 Linux 性能分析初步

核心指令：

Top

Sar

Vmstat

Iostat

Sar -n DEV

/proc文件系統

分析經驗性步驟：

首先查看 CPU 使用狀況，按照診斷 CPU、內存或磁盤瓶頸的指導進行操做。對於下面的每一個步驟，查找一端時間內的趨勢，從中收集系統運行性能較差時的數據。另外，只有將這些數據與系統正常運行時收集的數據進行比較時才能進行準確的診斷。

步驟 1

# sar -u [interval] [iterations]
(示例: sar -u 5 30)
%idle 是否很低? 這是 CPU 未在運行任何進程的時間百分比。在一端時間內 %idle 爲零多是 CPU 瓶頸的第一個指示。

不是 -> 系統未發生 CPU 瓶頸。轉至步驟 3。
是 -> 系統可能發生了 CPU、內存或 I/O 瓶頸。轉至步驟 2。

步驟 2

%usr 是否較高? 不少系統正常狀況下花費 80% 的 CPU 時間用於用戶， 20% 用於系統。其餘系統一般會使用 80% 左右的用戶時間。

不是 -> 系統可能遇到 CPU、內存或 I/O 瓶頸。轉至步驟 3。
是 -> 系統可能因爲用戶進程遇到 CPU 瓶頸。轉至部分 3，部分 A，調整系統的 CPU 瓶頸。

步驟 3

%wio 的值是否大於 15? （不一樣os有不一樣的閥值）

是 -> 之後記住這個值。它可能表示磁盤或磁帶瓶頸。轉至步驟 4。
不是 -> 轉至步驟 4。

步驟 4

# sar -d [interval] [iterations]
用於任何磁盤的 %busy 是否都大於 50? (請記住，50% 指示一個大概的指南，它可能遠遠高於您系統的正常值。在某些系統上，甚至 %busy 值爲 20 可能就表示發生了磁盤瓶頸，而其餘系統正常狀況下可能就爲 50% busy。)對於同一個磁盤上，avwait 是否大於 avserv?

不是 -> 極可能不是磁盤瓶頸，轉至步驟 6。
是 -> 此設備上好像發生了 IO 瓶頸。
轉至步驟 5。

步驟 5

系統上存在磁盤瓶頸，發生瓶頸的磁盤上有哪些內容?

原始分區，
文件系統 -> 轉至部分 3，部分 B，調整發生磁盤 IO 瓶頸的系統。
Swap -> 多是因爲內存瓶頸致使的。
轉至步驟 6。

步驟 6

# vmstat [interval] [iterations]
在很長的一端時間內，po 是否老是大於 0?
對於一個 s800 系統 (free * 4k) 是否小於 2 MB，
(對於 s700 系統 free * 4k 是否小於 1 MB)?
(值 2 MB 和 1 MB 指示大概的指南，真正的 LOTSFREE 值，即系統開始發生 paging 的值是在系統引導時計算的，它是基於系統內存的大小的。)

不是 -> 若是步驟 1 中的 %idle 較低，系統則極可能發生了 CPU 瓶頸。
轉至部分 3，部分 A，調整發生了 CPU 瓶頸的系統。
若是 %idle 不是很低，則可能不是 CPU、磁盤 IO或者內存瓶頸。
請轉至部分 4，其餘瓶頸。
是 -> 系統上存在內存瓶頸，轉至部分 3 部分 C，調整發生內存瓶頸的系統。

2.5 Windows 性能分析初步

同windows perfmon。

一樣集中在 cpu,內存，io,網絡上。

通常經驗值:

網絡

網絡利用率閥值沒有統一。 <30% or 80%?

衝突率: <1%

Packets Received Errors < 1%

I/O：

Disk Time % <90%

Avg. Disk Bytes/Read + Avg. Disk Bytes/Write <20K

Avg. Disk sec/Transfer <0.3 sec

隊列長度：Queue Length <2

Avg. Disk sec/Transfer <18 milliseconds

內存

Available Mbytes >25%

Page in+out <20 次

內存泄露以及錯誤：

Pool Nonpaged Bytes : an increase of 10 percent or more from its value at system startup。

Server -> Pool Nonpaged Failures shows the number of times allocations from nonpaged pool have failed - indicates that the computer `s physical memory is too small. 應爲0

Server -> Pool Paged Failures indicate that either physical memory or a paging file is near capacity. 應爲0

Server -> Pool Nonpaged Peak shows the maximum number of bytes in nonpaged pool the server has had in use at any one point. Indicates how much physical memory the computer should have.

處理器

利用率 <85%

每一個CPU隊列長度 <2

Context Switches/sec <5000次或者<5% of total threads