最近被內部問了太多關于jetty測試的問題了，所以這里先寫一點開頭，后續再全面的做一下測試，想說的就是測試需要你去關注場景，需要去區分什么是表象和本質。
你的系統是什么系統：（一步一步的做判斷）
流入系統 or 流出系統？
流入系統（系統完成請求無外部系統依賴，緩存可以考慮成為非外部依賴）
瓶頸在CPU，帶寬，內存（容器連接數，線程數）？
流出系統（系統完成請求有外部系統依賴）
瓶頸在CPU，帶寬，內存（容器連接數，線程數） or 第三方系統？
第三方系統：
1． 強依賴，無法降級和后備切換
2． 弱依賴，可降級跳過或后備可切換。（多個服務提供者提供同樣的服務）
模型建立：
1． 同樣資源情況下處理能力的比較。（不要僅僅去比較線程數，因為你的資源是cpu,memory等等，線程是表象）因此不要簡單的認為容器間的平等就是設置線程數的平等，不同容器采用的處理模式是不同的，就好比不要用NIO和BIO去比較他們的線程數一樣。這類測試需要關注同等資源這個標準如何建立（load，memory等），同樣的資源下再比較兩者的TPS。適用于流入系統來做壓力測試。（本身的系統消耗決定了處理能力）
2． 模擬不同RT范圍的場景，不同容器對于資源的消耗程度。（比如模擬后端系統響應時間的范圍，來觀察不同容器并發處理能力及穩定性）。適用于流出系統的強依賴模式。
3． 通過采用類似于Jetty Continuation或者servlet3的模式來將業務和系統線程池切分開來，加上帶有業務性隔離的服務線程池實現服務切換和降級，比較帶來的損耗是否可以接受，判斷是否換容器。適用于流出系統的弱依賴模式。
總體來說：
1． 建立統一的資源消耗模型（用實際的消耗來判斷服務器的能力瓶頸）
2． 根據依賴系統的響應時間來實際模擬場景判斷帶來的影響。（連接消耗在某些場景下已經是九牛一毛的case了，優化本身就沒有太大實際意義）
3． 對于系統本身是否有除了性能以外的更多需求，比如系統穩定性要求的服務降級和切換。
4． 容器本身的模式可改進點及可維護性（模塊化等）。
5． 最后對于慢請求的支持（內部網絡請求往往無法模擬慢請求對java容器的“傷害”，這也就是為什么要加一層http代理的目的）
近期做一下測試比較，給出一些結論性的東西，不過希望大家做測試一定要考慮場景和真實的需求，切勿僅僅為了容器測試而作容器測試。（同時把封裝的jetty層異步調用+業務性隔離的線程池代碼包共享出來）