便於檢視請求的整個路由過程，方便後期效能問題排查。
主要的使用使用者，系統使用者使用的高峰期，方便推算系統當前最大併發數。也可通過系統日誌，來獲取系統、各場景當前最大併發數
明確本次效能壓測的待測場景，和各場景涉及的伺服器
明確各待測場景對應表的資料量，如果量不夠需要預製
伺服器名稱、伺服器ip、作業系統、伺服器型別、cpu、記憶體 等等，如果被壓環境不是生產環境，需評估該環境與生產環境的效能比。
需要確認單台壓力機是否滿足壓測需求，如果無法支援，這時候就需要多個壓力執行機來分布式的進行壓測。
本次壓測採用的是瞬時載入、逐步載入、是否迴圈迭代、持續時長、各請求之間是否有停頓？還有本次壓測工具選用。
3.2.1施壓端
常用的效能指標：tps、平均響應時間、錯誤率、總請求數，請求斷言設定
3.2.2服務端
常用的效能指標：cpu、記憶體、disk i/o、network i/o，監控過程最好可以適當拉長點，這樣就可以有個壓測前、中、後資源使用對比了。
3.2.3資料庫
活動會話連線數、是否存在慢sql、死鎖等等。
資料準備主要指的是db層面，即效能測試需要模擬實際的環境，包括資料量等，從db層面來說，同乙個庫表，資料量不同在同樣的業務模型下，其效能表現也是不同的。
預埋資料的準備，可以通過從生產備份，或者通過指令碼、sql語句來自定義準備一些可用的資料
測試場景大的可以分為4種：基準場景、單場景、混合場景、穩定性場景
需要明確各項效能指標，如：併發數、載入時間、持續時間，最大cpu、記憶體、disk i/o、network i/o使用等等。
為保證每個介面資料返回的正確性，需都配置相應的斷言
對應錄製的指令碼，需要用transaction controller管理（注意勾選generate parent sample），以免聚合報告太多不好整理。
聚合報告最好提取出來，統一生產結果，方便檢視。
可以配置常量吞吐量控制器，控制每秒傳送量。
在壓測過程中，對原始的結果資料應盡量儲存，因為前期準備和壓測過程是非常繁瑣耗時的，不要到最後因為缺少什麼資料重新返工，不划算。
在壓測過程中，對出現的問題和對應的解決方案詳細記錄，方便後續同型別問題的出現
注意文件目錄索引要詳細，方便索引查詢和定位
如果有報錯，附上報錯資訊
壓測執行需同步測試用例設計
驗收測試結論以**的形式展現，方便明了。
效能測試的一些心得
效能測試三階段 一 單個介面的壓測 基準容量測試 目的 驗證被測試介面的最高tps 基於一定的響應時間ms tps是從服務端角度驗證介面效能 方法 採用梯度壓測方法，按照設定的梯度逐步遞增壓力，觀察tps曲線變化 測試時注意遞增的粒度，粒度需要細化到tps曲線跟隨梯度壓力曲線呈梯度變化 最大tps ...
mysql效能測試 MySQL的一些效能測試
針對資料庫引擎 myisam和innodb.做了一些效能測試和比較。包括有沒有索引的情況下的比較。主要是想證實一些效能問題。資料量 6 millions,機器 dell 2950 1.alter from innodb to myisam no index has two indexes 1min3...
關於bitmapData，濾鏡等一些效能測試
注 指效能更好 1.地圖滾動 之 純copypixes 和 bitmapdata.scroll copypixes 結論 copypixes scroll copypixes 耗時差距1 15 1 20 相差不大 2.地圖滾動 之 bitmapdata alpha 對效能影響 結論 無alpha 有...