轉：碼農的性能測試

1.如何理解TPS

　　性能指標的一個重要因素。TPS（Transaction Per Second，每秒事物數），單位時間內完成的事物的數量。TPS的計算通常是經過的事物除以時間。

　　TPS是跟 測試腳本中事物（Transaction）相關聯的。

　　在 性能測試工具中，吞吐量也被稱之爲TPS（Transaction Per Second，每秒事物數）。吞吐量直接體現系統性能的承載能力，是指單位時間內處理的客戶請求的數量。其計量單位能夠根據需求不一樣而不一樣，好比請求數/秒，頁面數/秒，業務數/小時（能夠說下咱們採集項目中吞吐量能夠用 解析卡數/秒）。

　　對於交互式應用，用戶直接的體驗就是「響應時間」，經過「併發用戶數」和「響應時間」能夠肯定系統的性能規劃；但對於非交互式應用，用「吞吐量」來描述用戶對系統的性能指望可能更加合理。

　　吞吐量做爲性能測試的主要關鍵指標。吞吐量和併發用戶數以前存在着必定的聯繫。在沒有性能瓶頸的時候，吞吐量隨着虛擬用戶數的增長而增長（計算公式爲 吞吐量 = （VU個數 * 每一個VU發出請求數） / 單位時間）。若是性能遇到瓶頸，吞吐量與VU數理之間就再也不符合這個關係。

　　2.如何理解線程調用

　　線程（thread）是」進程」中某個單一順序的控制流。也被稱爲輕量進程。

　　線程的好處：

　　1 建立一個新線程花費的時間少。

　　2.（JAVA中線程具備新的，可運行，運行，等待/阻塞/休眠，死亡等幾種狀態。）在未阻塞狀況下，兩個線程（在同一進程中的）的切換時間少。在阻塞狀況下，線程間切換將產生上下文切換。

　　3.因爲同一個進程內的線程共享內存和文件，因此線程之間互相通訊沒必要調用內核。

　　4 線程能獨立執行，能充分利用和發揮處理機與外圍設備並行 工做的能力。

　　使用線程能夠把佔據長時間的程序中的任務放到後臺去處理

　　ps:JAVA中能夠經過jstack或者jprofiler dump出線程所執行的堆棧信息。

　　 3.如何理解響應時間

　　響應時間反映完成某個業務所須要的時間。

　　在性能測試中是經過測試工具的事物函數來完成響應時間的統計。事物函數會記錄開始事物和結束事物的時間差，使用Transaction Response Time這個詞來講明。

　　響應時間主要包括網絡時間，服務器處理時間，網絡延遲

　　對於交互式應用，用戶直接的體驗就是「響應時間」，經過「併發用戶數」和「響應時間」能夠肯定系統的性能規劃；

　　對於交互式應用，響應時間出現拐點系統就可能出現瓶頸

　　 4.如何理解性能建模（可分類回答）

　　這個不會，以前找到一個資料，分享一下吧 http://www.docin.com/p-452373613.html

　 　5.如何理解響應時間，TPS曲線和用戶之間的關係

　　隨着用戶數量的增長，在未出現瓶頸前響應時間保持穩定，TPS值和併發用戶數成線性關係，出現瓶頸後響應時間變長，TPS基本保持不變或開始降低。

　　 6.在LoadRunner中爲什麼要設置思考時間和pacing?

　　1）Think time，思考時間。能夠經過設置思考時間，來模擬真實用戶在操做過程當中的等待時間。從定義上來看，think time是在iteration內部的某個action中各個步驟的間隔時間。

　　2）Pacing，步調。能夠經過設置兩次迭代（iteration）之間的間隔時間，來調整各個action之間的步調（或者稱之爲節奏）。

　　3）pacing和think time都是能夠模擬現實世界中的停頓。對於複雜場景，這個停頓要靠pacing來完成。不過，pacing怎麼設置才最合適，是須要研究用戶行爲才能定的。

操做系統

　　1.如何判斷CPU、內存、磁盤的瓶頸？

　　CPU瓶頸：

　　1) 查看CPU利用率。建議CPU指標以下

　　a) User Time：65%～70%

　　b) System Time：30%～35%

　　c) Idle：0%～5%

　　若是us,sy高於這個指標能夠判斷CPU有瓶頸

　　使用top查看

　　查看運行隊列

　　每一個CPU都會維持一個運行隊列，理想狀況下，調度器會不斷讓隊列中的進程運行。進程不是處在sleep狀態就是run able狀態。若是CPU過載，就會出現調度器跟不上系統的要求，致使可運行的進程會填滿隊列。隊列愈大，程序執行時間就愈長。「load」用來表示運行隊列，用top 命令咱們能夠看到CPU一分鐘，5分鐘和15分鐘內的運行隊列的大小。這個值越大代表系統負荷越大。超過 1.00，那麼說明CPU已經超出負荷，交通嚴重的擁堵。

　　使用top或者uptime查看

　　查看上下文切換

　　每一個CPU（或多核CPU中每一個核心）在同一時間只能執行一個線程，Linux採用搶佔式調度。即爲每一個線程分配必定的執行時間，當到達執行時間，線程中有IO阻塞或高優先級線程要執行時，Linux將切換執行的線程，在切換時要存儲目前線程的執行狀態，並恢復要執行的線程狀態，這個過程稱之爲上下文切換。對於java應用，典型的是在進行文件IO操做，網絡IO操做，鎖等待或線程sleep時，當前線程會進入阻塞或者休眠狀態，從而觸發上下文切換，上下文切換過多會形成內核佔用過多的CPU使用，使得應用的響應速度降低。

　　使用vmstat查看cs

　　 結論：

　　檢查system的運行隊列,以及肯定不要超出每一個處理器3個可運行狀態線程的限制.

　　肯定CPU 利用率中user/system比例維持在70/30

　　當CPU 開銷更多的時間在system mode,那就說明已經超負荷而且應該嘗試從新調度優先級

　　當I/O 處理獲得增加,CPU 範疇的應用處理將受到影響

　　ps:對於JAVA應用，CPU瓶頸能夠經過jprofiler監控分析

　　 內存瓶頸：

　　1.查看利用率(free)

　　used:已使用多大。

　　free:可用有多少。

　　Shared:多個進程共享的內存總額。

　　Buffers/cached:磁盤緩存的大小。

　　2.查看頁交換，swap交換（po,pi,so,si），磁盤IO(vmstat)

　　si: 每秒從交換區寫到內存的大小

　　so: 每秒寫入交換區的內存大小

　　page in :分頁(Page)從磁盤從新回到內存的過程被稱做Page-In

　　page out : 分頁(Page)寫入磁盤的過程被稱做Page-Out

　　另外在進行頁交換的時候，會產生磁盤IO，還需注意bi,bo

　　Bo 磁盤塊頁面從內存到文件或交換設備的總額

　　Bi 磁盤塊頁面從文件或交換設備到內存的總額

　　3.page fault（pidstat -r，sar -B )

　　minflt/s: 每秒次缺頁錯誤次數(minor page faults)，次缺頁錯誤次數意即虛擬內存地址映射成物理內存地址產生的page fault次數

　　majflt/s: 每秒主缺頁錯誤次數(major page faults)，當虛擬內存地址映射成物理內存地址時，相應的page在swap中，這樣的page fault爲major page fault，通常在內存使用緊張時產生

　　其中sar -B中fault/s表示每秒鐘minflt，majflt的和。

　　結論：

　　監控虛擬內存性能由如下幾個部分組成：

　　1.當系統中出現較少的頁錯誤,得到最好的響應時間,是由於memory caches(譯註:內存高速緩存)比disk caches更快(譯註:磁盤高速緩存).

　　2.較少的空閒內存,是件好事情,那意味着緩存的使用更有效率.除非在不斷的寫入swap device和disk.

　　3.若是系統不斷報告,swap device老是繁忙中,那就意味着內存已經不足,須要升級了.

　　zee：

　　若是用作緩衝區（buff）和快速緩存（Cache）的物理內存不斷地增長，而空閒的物理內存（free）不斷地減小，證實系統中運行的進程正在不斷地消耗物理內存。

　　已經使用的虛擬內存（swpd）不斷增長，並且存在着大量的頁面交換（si和so），證實物理內存已經不能知足系統需求，系統必須把物理內存的頁面交換到磁盤中去。

　　由此能夠獲得這樣的結論：該主機上的物理內存已經不能知足系統運行的須要，內存已成爲該系統性能的一個瓶頸。

　　ps:對於java程序，內存瓶頸能夠經過heap dump後使用mat分析

　　 磁盤瓶頸：

　　iostat查看IO信息。若是 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。

　　另外還須要注意iowait這個值，iowait 值高就意味着磁盤緩慢或負載過大。還有不要信任svctm這個字段。

　　監控swap 和系統分區,要確保virtual memory不是文件系統I/O 的瓶頸.

　　ps:磁盤瓶頸能夠經過pidstat -d 定位程序

　　2.如何理解CPU、內存、磁盤的關係？

　　這些子系統之間關係是彼此聯繫，相互彼此依賴的

　　1.對於進程來講，數據是存放在內存中的，進程的運行須要使用CPU，進程讀寫數據須要跟磁盤打交道。

　　2.當內存不足時須要跟磁盤進行頁(page)交換，swap交換，從而產生磁盤IO。po,so釋放物理內存，pi,si增長物理內存使用。交換分頁的過程須要佔用cpu時間。 (內存佔用太高)

　　3.當磁盤IO負載太高時，須要監控swap和系統分區，要確保virtual memory不是文件系統I/O 的瓶頸。磁盤的至關慢的，當iowait 增加,表示CPU花費大量的時間在等待磁盤IO，此時CPU Bound的應用處理將受到影響（磁盤IO太高）

　　3.如何理解paging in / paging out ?

　　在Linux內存管理中，主要是經過「調頁Paging」和「交換Swapping」來完成上述的內存調度。調頁算法是將內存中最近不常使用的頁面換到磁盤上，把活動頁面保留在內存中供進程使用。交換技術是將整個進程，而不是部分頁面，所有交換到磁盤上。

　　分頁(Page)寫入磁盤的過程被稱做Page-Out，分頁(Page)從磁盤從新回到內存的過程被稱做Page-In。當內核須要一個分頁時，但發現此分頁不在物理內存中(由於已經被Page-Out了)，此時就發生了分頁錯誤（Page Fault）。

　　當系統內核發現可運行內存變少時，就會經過Page-Out來釋放一部分物理內存。經管Page-Out不是常常發生，可是若是Page-out頻繁不斷的發生，直到當內核管理分頁的時間超過運行程式的時間時，系統效能會急劇降低。這時的系統已經運行很是慢或進入暫停狀態，這種狀態亦被稱做thrashing(顛簸)。

　　能夠經過vmstat -s 查看 paged in/out 數量

　　4.如何監控操做系統的資源？（可用一個操做系統作例子）

　　(把簡歷上部份內容直接貼出來了，懶的整理了)

　　CPU監控：top(利用率)， uptime(運行隊列數)， vmstat(上下文切換數)， jprofile(方法佔用cpu時間百分比)

　　內存監控:top， free(利用率)， vmstat(page和swap交換)， pidstat -r和sar -B(page fault)， jmap -heap(堆dump)， mat和jprofiler(查看對象)

　　磁盤監控：iostat(%util)， top(iowait%)， pidstat -d

　　網絡監控：netstat(鏈接數)， nethogs(流量)， wireshark和tcpdump(抓包)

　　JVM監控：jstat(gc)， jmap(堆dump)， jstack(線程dump)， jprofiler和visualvm(剖析工具)

　　nmon(長時間全局收集數據)

　　5.如何理解內存管理和線程調度？（可用一個操做系統作例子）

　　不會

　　6.如何理解上下文切換（context switch）?（可用一個操做系統作例子）

　　每一個CPU（或多核CPU中每一個核心）在同一時間只能執行一個線程，Linux採用搶佔式調度。即爲每一個線程分配必定的執行時間，當到達執行時間，線程中有IO阻塞或高優先級線程要執行時，Linux將切換執行的線程，在切換時要存儲目前線程的執行狀態，並恢復要執行的線程狀態，這個過程稱之爲上下文切換。對於java應用，典型的是在進行文件IO操做，網絡IO操做，鎖等待或線程sleep時，當前線程會進入阻塞或者休眠狀態，從而觸發上下文切換，上下文切換過多會形成內核佔用過多的CPU使用，使得應用的響應速度降低。

　　vmstat其中cs那一列

　　7.如何理解磁盤IO？（可用一個操做系統作例子）

　　磁盤IO速度是很是慢的，linux內核就是要儘可能下降IO

　　內存不足時會進行頁交換，產生磁盤IO

　　CPU Bound類型應用，當磁盤IO過多，iowait過大時會影響性能。