Dec 15, 2011

[Java Performance]Chapter 1:Strategies, Approaches, and Methodologies

在軟體開發流程中該在何時評估效能?
傳統上瀑布式開發(Analysis > Design > Code > Test)會在測試階段進行效能測式,當效能結果不符合要求,調整代價可能很高,因此在擬定需求時就需要將效能指標定義出來,由需求驅動開發過程中各階段的效能測試
  • 期望的throughput為多少?
  • 期望latency為多少?
  • 要能負載多少的 concurrent users 或者 concurrent tasks?
  • 在最大數量的 concurrent users 或者 concurrent tasks負載下,可接受的latency 或者throughput為多少?
  • 最糟糕狀況下可接受的latency為多少?
  • garbage collection 引入的延遲否容許?
假設某些use case可能造成高度的效能風險,那應該在Analysis階段之前製作prototype驗證效能的可行性




使用自動化的效能測試
自動化佈署、自動化效能測試、自動化統計與分析效能數據,利於追蹤早期的效能問題
兩種效能分析方法: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: