最近被內部問了太多關于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代理的目的）

　　近期做一下測試比較，給出一些結論性的東西，不過希望大家做測試一定要考慮場景和真實的需求，切勿僅僅為了容器測試而作容器測試。