怎麼作性能測試--響應時間

時間 2019-12-02

原文原文鏈接

作性能測試先要懂性能，響應時間(response time)做爲性能測試過程當中兩大重要指標之一是咱們必須關注的。

從用戶角度來講，用戶最討厭等待。在大量的處理環境中，超過3秒以上的響應時間將會嚴重影響工做效率。然而最終用戶的感覺不只僅是絕對時間問題，他們對於響應時間的指望是參照以往的經驗，而這種指望是相對於他們使用該應用的基準性能。若是使用該應用的當前感覺和以往的經驗有很大的差異時，抱怨以及須要支持的電話就會成倍地增長。響應時間對於用戶來講既有客觀成分，也有主觀成分。

例（1）：對於小說網站來講，頁面的主要功能是向用戶提供可閱讀的內容，那麼用戶極可能會將「小說內容」這個時間做爲本身感覺到的響應時間；

例（2）：對於報稅系統來講，頁面的主要功能是提供給用戶申報納稅的頁面，那麼用戶只有用戶打開申報頁面，申報納稅成功後，纔會以爲頁面響應完成。

對於例（1）而言，小說內容徹底能夠分段加載，先加載500字內容，等待以前500字加載完成以後，再加載以後的內容，當看完必定內容，用戶作鼠標滾動或翻頁操做時再加載以後的內容。

對於例（2）而言，申報納稅須要等待，服務器處理、數據庫處理、外部系統通訊、瀏覽器前端加載等整個流程處理結束以後，才能算做響應成功。

對於例（1）能夠將響應時間理解爲「應用系統從請求發出開始到客戶端收到響應所消耗的時間」。而對於例（2）而言響應時間定義爲「應用系統從請求發出開始到客戶端接收到最後一個字節數據所消耗的時間」。形成這種差別的緣由是能夠採用一些技巧在數據還沒有徹底接收完成時進行呈現來減小用戶感覺到的響應時間。

下圖爲Web應用的頁面響應時間簡要構成。從圖中能夠看到，頁面的服務端響應時間可被分解爲網絡傳輸時間（N1+N2+N3+N4）、應用處理時間（T1+T3）、數據庫處理時間（T2）和前端瀏覽器加載時間（T4）。之因此要如此細分響應時間，主要目的是可以更準確地定位性能瓶頸。

N1&N4

這個階段用戶點擊頁面，利用Http協議創建鏈接，作get 請求或post 請求。http鏈接實際上就是TCP鏈接和一些使用鏈接的規則。TCP鏈接是因特網上的可靠鏈接。（詳細TCP協議知識，詳見《 TCP 的那些事兒（上）》 http://coolshell.cn/articles/11564.html、《 TCP 的那些事兒（下）》 http://coolshell.cn/articles/11609.html ）

TCP爲Http提供了一條可靠的比特傳輸管道。從TCP鏈接一端填入的字節會從另外一端以原有的順序、正確地傳送出來。

N2&N4

JDBC（Java Data Base Connectivity,java數據庫鏈接）是一種用於執行SQL語句的Java API，能夠爲多種關係數據庫提供統一訪問，它由一組用Java語言編寫的類和接口組成。JDBC提供了一種基準，據此能夠構建更高級的工具和接口，使數據庫開發人員可以編寫數據庫應用程序。

簡單地說，JDBC可作三件事：與數據庫創建鏈接、發送操做數據庫的語句並處理結果。

數據庫創建鏈接通常經過鏈接池管理鏈接，當鏈接池中某條查詢語句執行完成，鏈接池所獲取的鏈接不會當即釋放，而會等待下次查詢調用鏈接。由於創建鏈接也是極爲耗時的操做。

T1&T3

java servlet做爲線程安全的服務器程序（注：這裏所說的線程安全並不能保證開發人員所作的業務代碼也是線程安全的），幾乎全部的java web程序都是以此爲基礎發展而來。（固然你也能夠本身用java實現一套cgi，至於什麼是cgi，詳見 http://baike.baidu.com/subview/32614/12037322.htm?fr=aladdin ）

servlet生命週期

客戶端請求該servlet
加載servlet類到內存
實例化、初始化該servlet
init()初始化參數
service()（doGet()或者doPost()）
destroy()

加載和實例化Servlet。這項操做通常是動態執行的，在weblogic這類中間件中可以配置servlet併發線程數，同時能監控servlet併發線程數。Server一般會提供一個管理的選項，用於在Server啓動時強制裝載和初始化特定的Servlet。

Server建立一個Servlet的實例

第一個客戶端的請求到達Server

Server調用Servlet的init()方法（可配置爲Server建立servlet實例時調用,在web.xml中<servlet>標籤下配置<load-on-startup>標籤,配置的值爲整型,值越小servlet的啓動優先級越高）

一個客戶端的請求到達Server

Server建立一個請求對象，處理客戶端請求

Server建立一個響應對象，響應客戶端請求

Server激活Servlet的service()方法，傳遞請求和響應對象做爲參數

service()方法得到關於請求對象的信息，處理請求，訪問其餘資源，得到須要的信息

service()方法使用響應對象的方法，將響應傳回Server，最終到達客戶端。service()方法可能激活其它方法以處理請求，如doGet()或doPost()或程序員本身開發的新的方法。

對於更多的客戶端請求，Server建立新的請求和響應對象，仍然激活此Servlet的service()方法，將這兩個對象做爲參數傳遞給它。如此重複以上的循環，但無需再次調用init()方法。通常Servlet只初始化一次(只有一個對象),當Server再也不須要Servlet時(通常當Server關閉時)，Server調用Servlet的Destroy()方法。

在執行和獲取結果前，數據庫系統對此sql將進行幾個步驟的處理過程：

當發佈一條SQL或PL/SQL命令時，Oracle會自動尋找該命令是否存在於共享池中來決定對當前的語句使用硬解析或軟解析。

一般狀況下，SQL語句的執行過程以下：

SQL代碼的語法(語法的正確性)及語義檢查(對象的存在性與權限)。
將SQL代碼的文本進行哈希獲得哈希值。
若是共享池中存在相同的哈希值，則對這個命令進一步判斷是否進行軟解析，不然到5步驟。
對於存在相同哈希值的新命令行，其文本將與已存在的命令行的文本逐個進行比較。這些比較包括大小寫，字符串是否一致，空格，註釋等，若是一致，則對其進行軟解析，轉到步驟6。不然到4步驟。紅色字體描述有誤應該轉到步驟5
硬解析，生成執行計劃。
執行SQL代碼，返回結果。

軟解析在緩衝區裏找到相同或類似的SQL語句，能夠直接利用，不用從新進行分析生成執行計劃了。硬解析則相反，即整個 SQL 語句的執行須要完徹底全的解析，生成執行計劃。而硬解析，生成執行計劃須要耗用 CPU 資源，以及 SGA 資源。在此不得不提的是對庫緩存中閂的使用。閂（latch）是鎖的細化，能夠理解爲是一種輕量級的串行化設備。當進程申請到閂後，則這些閂用於保護共享內存的數在同一時刻不會被兩個以上的進程修改。在硬解析時，須要申請閂的使用，而閂的數量在有限的狀況下須要等待。大量的閂的使用由此形成須要使用閂的進程排隊越頻繁，性能則逾低下。

數據庫利用內部的hash算法來取得該sql的hash值，而後在library cache裏查找是否存在該hash值。假設存在，則將此sql與 cache中的進行比較。假設「相同」，就將利用已有的解析樹與執行計劃，而省略了優化器的相關工做。這也就是軟解析的過程。 (關於執行計劃，詳見 http://www.cnblogs.com/snifferhu/p/3461982.html )

前端頁面大體包含html、圖片、css、js、flash等元素，對於各類元素由於瀏覽器版本的不一樣而致使加載順序不一樣。對於前端頁面加載這塊研究並非很深刻，推薦看《Javascript 裝載和執行》 http://coolshell.cn/articles/9749.html

總結

在此大體描述了響應時間的概念，以及響應時間的組成，讀懂了響應時間，纔是性能測試的開始。

系列博客：