傳統上瀑布式開發(Analysis > Design > Code > Test)會在測試階段進行效能測式，當效能結果不符合要求，調整代價可能很高，因此在擬定需求時就需要將效能指標定義出來，由需求驅動開發過程中各階段的效能測試
- 期望的throughput為多少？
- 期望latency為多少？
- 要能負載多少的 concurrent users 或者 concurrent tasks？
- 在最大數量的 concurrent users 或者 concurrent tasks負載下，可接受的latency 或者throughput為多少？
- 最糟糕狀況下可接受的latency為多少？
假設某些use case可能造成高度的效能風險，那應該在Analysis階段之前製作prototype驗證效能的可行性
- garbage collection 引入的延遲否容許？
使用自動化的效能測試
自動化佈署、自動化效能測試、自動化統計與分析效能數據，利於追蹤早期的效能問題
兩種效能分析方法：Top Down and Bottom Up
Top Down方式適用於應用開發者從software stack層次、調整程式，調整程式設定，選擇JVM GC collector、調效JVM command line options來分析效能
Bottom Up方式適用效能專家從CPU架構、CPU數量，作業系統、JVM版本，收集CPU statistics資訊分析無效率的指令、cache misses狀況等問題，來選擇合適的軟硬體環境
選擇合適的平台與評估系統
Sun 的SPARC T-series CPU針對多 thread 切換造成的CPU cache misses效能問題，在每顆CPU core 中設計多組的hardware thread，相較一般CPU在一顆core一組hardware thread的設計有更好的效率
No comments:
Post a Comment