怎樣才能測試WEB系統支持多少用戶
|
1 怎樣的性能測試結果纔是有效的 1.1 錯誤觀點 性能測試工具運行一定用戶數都成功，則表示該服務器能支持這麼多用戶數。這是錯誤的。 解答： A. 因爲一次有效的測試結果，不只用戶都運行成功，同時需要保證訪問一個頁面或一次交易的響應時間在合理範圍。“2-5-8原則”，簡單說，就是當用戶訪問一個頁面或一次交易能夠在2秒以內得到響應時，會感覺系統的響應很快；當用戶在2-5秒之間得到響應時，會感覺系統的響應速度還可以；當用戶在5-8秒以內得到響應時，會感覺系統的響應速度很慢，但是還可以接受；而當用戶在超過8秒後仍然無法得到響應時，會感覺系統糟透了，或者認爲 系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。 B. 測試場景不一定模擬了真實業務場景，因爲瀏覽器是併發多線程多TCP完成一個頁面的，而測試工具基本都是1，2個線程；對服務器的壓力是不一樣的，真實環境的TCP壓力是性能測試工具虛擬環境的幾倍。 2 影響WEB服務器性能指標的因素有哪些 爲什麼性能測試工具，需要提供事務（頁面或交易、全腳本）指標、TCP連接、吞吐量、服務器資源監控、請求數/響應數。 1) 硬件資源：如CPU、內存、網卡吞吐量、I/O能力、SWAP交換能力 2) 線程數：這裏介紹JAVA的WEB服務器，默認每線程佔用的內存爲2M，而32爲系統JAVA進程（如tomcat、JBoss）佔得空間只有2G（一般比這個小），因此線程數有限制；64爲無限制線程，但CPU要跟得上 3) TCP連接數：操作系統的TCP連接數理論值一般很大，操作系統對TCP連接設置有默認值（怎麼配置，可以網上搜索，這裏不介紹）；但實際測試中TCP連接在幾百，就出現測試的響應時間很長。抓包分析，原來是三次握手的SYN包服務器不及時響應，導致SYN重傳（3秒後，9秒後）。  如果SYN丟了，則會重發，但是第一次是3秒後，第2次是在9秒後，如果重發才收到的SYN_ACK，則導致TCP連接超長，從而導致業務響應時間延長。  4) 響應時間：服務器響應時間小，用戶體驗纔好，在大量用戶併發的情況下，HTTP響應時間在用戶忍受度下才是有效的，一般採用“2-5-8原則”。 5) 軟件本身代碼性能算法：這個不做介紹，如差的算法、查詢數據庫時間長等等。 3 測試人員經常遇到的一些常見問題及解答 3.1 爲什麼使用瀏覽器訪問頁面響應很快，1-2秒就完成；而使用測試工具卻需要10幾秒，甚至幾十秒才完成腳本 解答： A. 這是由於瀏覽器訪問頁面響應是併發的，同時併發多個線程（多個Socket），而性能測試工具基本是串行發送請求的。如果一個頁面有100個資源（CSS、HTML、JS、圖片），需要發送100個HTTP請求，如果使用6個線程（瀏覽器），則每個大概請求14個HTTP；如果使用一個線程（測試工具），則需要請求100個，時間當然大很多。下圖爲chrome瀏覽器調試工具顯示的併發情況：  B. 另外瀏覽器具有緩存功能，如果之前訪問了www.qq.com，會把一些圖片緩存在瀏覽器臨時目錄，下次請求時發送的HTTP請求會帶上If-Match或Etag等頭域，WEB服務器判斷資源沒改變則會304響應，而不是回200 OK，這樣減少資源的傳輸，所以時間就小。而有些測試工具是不攜帶這些頭域（包括Loadrunner），因此回的響應是200 OK。所以測試人員默認真實測試時，可以考慮部分有緩存，部分沒緩存。 3.2 性能測試工具是怎麼模擬WEB虛擬用戶 A. 錄製 使用瀏覽器進行正常業務操作，性能測試工具錄製下HTTP請求信息。一般需要記錄URL與頭域、內容、響應碼。雖然不同的性能測試工具錄製方式不一樣（如loadrunner採用Hook，JMeter採用代理或badbody，kylinPET採用網卡抓包與代理），但都能實現錄製正常業務的HTTP請求。 測試工具最好能錄製出緩存頭域，即If-Match或Etag，loadrunner好像不支持錄製緩存頭域。 B. 模擬用戶 根據錄製的腳本發送HTTP請求與接收響應，發送前替換參數（實現多用戶不同參數值）、接收時關聯參數（從接收的響應消息獲取參數值，如Cookie、JSessionID） 下面簡單列舉使用過的性能測試工具是如何模擬的（工具運行一個用戶，然後使用wireshark抓包分析得到的結論）： Loadrunner：根據錄製腳本發送HTTP請求，如果HTTP請求包括內嵌資源（如圖片、CSS、JS），會啓動第二個線程執行內嵌資源，即Loadrunner支持同時兩個線程兩個TCP連接。 kylinPET（國產）：可通過配置設置一個線程或者多個線程併發發送HTTP請求，多個線程併發及TCP連接數跟瀏覽器行爲一樣。 JMeter：只有一個線程，一個TCP連接 其他工具：本人沒用過，請用過的兄弟姐妹可以補充下。通過wireshark抓包分析。 3.3 怎樣才能測試出WEB服務器能支持多少真實用戶，怎樣的服務器調優參數才合理 解答： 這需要性能測試工具可以模擬出真實用戶的行爲，包括HTTP請求數、每用戶併發線程與TCP連接數、思考時間、有無緩存。 爲什麼需要模擬真實用戶的線程數與TCP連接數呢，上面提到過，WEB服務器的線程數與TCP連接數往往很低，這不是提高硬件就能輕鬆解決的，這也是服務器調優比較複雜的配置。 因此，只有盡最大能力模擬真實用戶（瀏覽器或其它WEB客戶端，可能不同瀏覽器的併發線程與TCP數都不一樣）的行爲的測試場景，測試結果才最真實，服務器調優才最有意義。 4 怎樣才能測試系統支持多少用戶 4.1 模擬真實用戶的行爲 只有模擬用戶一樣的行爲纔可以系統支持的測試用戶數有效，因此需要模擬一樣的併發數、TCP連接數、甚至可以是HTTP請求的時間間隔。用戶可以是瀏覽器、智能手機、智能機頂盒，測試工具模擬他們一樣的行爲纔是最有效的測試。 4.2 測試結果數據在合理範圍 4.2.1 用戶統計 成功數、失敗數、每秒在線數、最大在線數，通過這些指標分析此次測試結果支持的用戶數、用戶最大數 4.2.2 點擊率 每秒平均HTTP請求數、響應數。分析系統的處理能力 4.2.3 事務 事務成功、失敗、時間，事務一般是整個腳本運行時間、或者一個頁面或一個交易，通過結果分析，得出每個事物的時間是否合理，符合“2-5-8”原則，如果測試結果顯示事物時間非常大，則表示系統支持不了此次測試的用戶，因爲用戶的響應時間太大（像火車訂票一樣，太多用戶導致響應時間長，用戶無法忍受，則認爲這個系統爛）。 當然，還需要查看事務的百分比，分析90%、80%、70%、60%的事務時間是否在合理範圍。 4.2.4 TCP連接信息 TCP連接成功數、失敗數、TCP三次握手時間。因爲此次測試結果可能是由於服務器系統或網絡的TCP的丟包與重傳才導致延時大的。如果是服務器的原因，服務器收到TCP的SYN而不處理，可以通過調試服務器的TCP配置來優化。 怎麼才知道是服務器的問題呢，這個需要性能測試工具能給出TCP連接時間（當前瞭解只有kylinPET可以支持），如果顯示超過3秒，這時需要檢查是網絡還是服務器問題，可以在服務器端抓包（tcpdump或wireshark）然後分析TCP的SYN信息（個數、時間） 4.2.5 資源佔用 服務器的CPU、內存、帶寬、I/O是不是已經不足，導致系統上不去是哪個原因，根據原因進行調優或升級。 測試時需要考慮性能測試工具的CPU佔用率，如果性能測試工具佔用CPU很高，此次測試可能瓶頸是在工具，而導致測試結果是無效的。 |
