服務器硬件瓶頸-〉網絡瓶頸（對局域網，可以不考慮）-〉服務器操作系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）
注：以上過程並不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（併發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。
服務器在不受壓情況下，內存佔用率最佳爲25%，多了影響服務器性能；
壓力負載測試中也需要注意：
1、注意區別內存泄露和動態內存分配問題；
2、注意壓力端和服務器端的網絡流量，一般來說目前的網絡不會是系統的瓶頸，但是也需要注意；
3、單機的壓力用戶數不要過多，否則會影響測試結果，最好不要超過300；
4、分不同的組來運行不同的事務腳本，應真實的模擬系統情況；
-----------
網絡時間是從發出第一個http請求到收到ACK的時間。
服務器時間是從收到ACK到第一個字節返回的時間。
ACK是TCP首部中的確認標誌，對已接受到的TCP報文進行確認。
-----------
壓力系統必須超越功能測試，要同時遍歷多條代碼路徑。至於怎麼做到這一點取決於具體的產品。例如，一個 Web 服務壓力測試需要一次模擬多個客戶機。Web 服務（或者任何多線程代碼）通常會訪問多個線程實例間的一些共享數據。因額外方面的編程而增加的複雜性通常意味着代碼會具有許多因併發引起的錯誤。由於引入併發性意味着一個線程中的代碼有可能被其他線程中的代碼中斷，所以錯誤只在一個指令集以特定的順序（例如以特定的定時條件）執行時纔會被發現。把這個原則與重複原則結合在一起，您可以應用許多代碼路徑 和定時條件。
-----------
頻率*時間=端口數
這個公式可以延伸到很多額定的場景內。
-----------
應用服務器都通過線程去處理相應的請求，不管容量規劃也好，不管做性能測試也好，都要找到比較根本的源頭，這裏指出的是：線程數（端口）。
-----------