最近做了一些壓測工作，藉此機會做一些工作流程的梳理，經驗的總結等。
壓測的工作流程大致如右: 明確壓測目的，設計壓測方案，進行壓測的前期準備，監控壓測效能指標，分析壓測效能瓶頸與調優，編寫壓測報告。
在開始壓測時，我們需要明確壓測的目的，了解本次壓測主要的關注點是什麼，是看新功能會不會對效能有影響？還是看功能是否滿足業務需求？還是找瓶頸？還是看長時間執行有沒有問題？
根據不同的壓測目的，大致可歸納為如下幾種壓測型別：
有了我們的壓測目的後，我們就可以設計我們的壓測方案，這些壓測方案總體思路有一些套路可循。
例如做基準測試時，我們要先壓乙份線上版本用來做基準的效能指標參考，然後壓乙份新的版本，觀察新版本的各項效能指標至少要不不弱於基準效能。
負載測試時，需要先調研使用者需求或線上實際的負載情況並確定一系列期望的效能指標值(qps,響應時間等)，然後以該負載的併發量為起點，以乙個固定併發增量逐步增大併發到2倍左右，觀察效能指標是否仍然在可接受範圍內。
如果是壓力測試，就要繼續增大壓力直到拐點出現，記錄拐點前的各項指標即為指標的最大值，以及分析效能瓶頸。
如果是疲勞強度測試，則是在某個固定負載下做乙個長時間的壓力保持，觀察一些可能發生問題的效能指標的曲線圖是否保持穩定。
知己知彼，百戰不殆。我們只有在壓測前準備充分，才能保證壓測的結果可用，可信。前期準備包括調研，編寫壓測指令碼與準備資料，搭建壓測環境，配置監控等。
調研一方面，我們需要調研入口處資料情況，從而更好為後面壓力機產生壓力提供參考:
另一方面，我們需要調研資料處理時的情況,也即待壓測功能或服務的情況:
壓測指令碼與資料的準備
調研完畢後，我們需要編寫指令碼和準備資料來壓測。
一般來講，編寫壓測指令碼和準備資料的總體原則是逼近真實情況，這樣壓測時觀察到的結果才能為系統上線提供最大的參考價值。
編寫指令碼方面，盡量模擬實際業務操作流程，例如某些業務是多個介面按順序呼叫，某些業務介面呼叫時需要前一步驟成功才能進行下一步等。指令碼空轉（沒能讓業務實際成功執行）這種最壞情況下，會導致壓測結果完全沒有參考價值。
資料準備方面，同樣要盡量讓資料模擬線上實際情況。主要要考慮：
我們可以完全自己寫**來完成壓測指令碼並讀取資料實現併發產生壓力和壓力控制，當然更快速便捷的方法是使用已有的壓力工具或框架來實現。
壓測環境搭建
壓測環境最理想的情況是完全和生產環境一樣，例如伺服器配置，資料庫配置，網路頻寬等統統一樣。當然，理想理想，現實是這麼做一套費時費力費錢，所以一般來講壓測環境都是生產環境的縮略版，為了盡量保證我們的壓測環境的壓測結果能反應真實線上情況，準備壓測環境時我們可以考慮如下一些點：
壓測監控配置
在正式開始壓測之前，為了能夠更方便的檢視各項效能指標，特別是觀察指標的變化曲線，我們還需要進行壓測監控的配置。
完善的監控可以有效的幫助我們分析問題，定位瓶頸。監控的指標可以從資源（cpu、記憶體、磁碟、網路i/o、程序數），資料庫（crud數，效率低下sql、鎖、快取、會話、程序數）,中介軟體（執行緒池、jdbc連線池、jvm),
應用（qps、耗時、錯誤、同步非同步、執行緒數、快取佇列）等方面考慮。
這些監控自己蒐集資料並展現工作量巨大，幸好已經有成熟的監控工具能幫你做這些事，常見的監控工具有zabbix、open-falcon、prometheus等。
你需要做的是，和開發運維協作，用監控工具蒐集到需要的資訊，配置監控物件來展現相應效能監控圖表。
在監控配置時，效能指標蒐集的越多越好，但在監控的時候，這些指標我們常常會感覺眼花繚亂，不知到底該重點關注哪個。其實萬變不離其宗，google總結了4個**指標：延遲、通訊量、錯誤及飽和度，來衡量使用者體驗及業務影響，幫助發現服務故障和定位問題。
延遲服務請求所花費的時間。
要注意需要區分成功請求和失敗請求。有的時候失敗請求可能會以非常低的延遲返回錯誤結果。而如果把這種快速返回的錯誤請求的延時也記錄到延時統計中，會導致統計的結果與實際差異很大。
除此以外，在微服務中通常提倡「快速失敗」，開發人員需要特別注意這些延遲較大的錯誤，因為這些緩慢的錯誤會明顯影響系統的效能，因此追蹤這些錯誤的延遲也是非常重要的。
另外，還需要關注系統的io等待、網路延遲等耗時情況。
流量流量對於不同的系統可能代表不同的含義，例如，流量指標可以指系統層面的網路和磁碟io，服務層面的qps、使用者數等資料。
流量和突增或突減都可能預示著系統可能出現問題。
錯誤錯誤是指當前系統發生的錯誤請求和錯誤率。
對於失敗而言有些是顯式的(比如, http 500錯誤)，而有些是隱式(比如，http響應200，但實際業務流程依然是失敗的)。
對於一些顯式的錯誤如http 500可以通過在負載均衡器(如nginx)或壓力機端捕獲，而對於一些系統內部的異常，則可能需要在服務中新增鉤子來獲取並統計。
宕機、磁碟（壞盤或檔案系統錯誤）、程序或埠掛掉、資料丟失等故障在監控時也需要保持警惕。
飽和度用於衡量當前服務的利用率。
飽和度與流量息息相關，流量的上公升一般也會導致飽和度的上公升。通常情況下，每種業務系統都應該有各自的飽和度指標。
在很多業務系統中，訊息佇列長度是乙個比較重要的飽和度指標，除此之外 cpu、記憶體、磁碟、網路、記憶體堆疊利用率、檔案控制代碼數等系統資源利用率也可以作為飽和度的一種體現方式。
基礎監控：cpu、記憶體、磁碟和網路利用率、記憶體堆疊利用率、檔案控制代碼數、tcp 連線數等；
在壓測是，我們要重點關注監控指標的異常情況，包括指標隨著壓力的增大超出了預期範圍，指標曲線的突變等情況。
而且異常發生時常常不是只有一處，而是牽一髮而動全身，例如jvm記憶體過小可能導致過多的full gc，由此可能引發cpu消耗過大曲線陡增，從而引起一系列效能指標下降的情況。
這種情況下，需要和開發一起仔細排查原因，反覆嘗試，直到找到問題的真正原因。我們可以從如下方面入手排查問題：
調優時，可以遵循由簡單到複雜，由軟體到硬體的原則，如果一上來就是直接增大系統資源很可能會掩蓋真正的問題和瓶頸。
最後，我們需要編寫壓測報告，壓測報告主要包括目的，結論，環境配置及版本，壓測方法，壓測結果與分析等內容。另外注意存檔所有監控指標圖，以供後續查閱。
參考鏈結
阿里巴巴 pts
乙份運維監控的終極秘籍
Struts工作流程
文章分類 招聘求職 乙個使用者的請求是通actionservlet來處理和 的。那麼，actionservlet如何決定把使用者請求 給哪個action物件呢？這就需要一些描述使用者請求路徑和action衍射關係的配置資訊了。在struts中，這些配置對映資訊都儲存在特定的xml檔案struts c...
zf工作流程
zend controller是使用mvc模式來構建乙個站點的基礎。zend controller體系是乙個輕量的，模組化和可擴充套件的體系。它只提供最核心的必要的部分，允許開發者有很大的自由來靈活地構建自己的站點。使用zend controller的站點，其檔案組織和 結構會比較相似。zend c...
spring MVC 工作流程
1 首先來配置一下dispatcherservlet spring mvc和大部分mvc框架一樣,底層也是依賴servlet api的,所以spring mvc的請求處理也是從乙個servlet開始,這個servlet就是dispatcherservlet.以下是在web.xml中dispatche...