本文提供了十點有關性能方面的計劃安排
它們能確保你的應用得以完整實施
． 應用需要性能調整 應該認識到應用在項目的不同階段需要性能調整
而調整需求是需要必要的資源和時間的
你應該為此制定相應的計劃
下面的幾點建議可能對你確定如何安排預算會有所幫助
． 培養內部性能專家 安排兩個開發者去理解性能調整
有性能專家再好不過了
但是如果你能安排好內部資源
整體預算將會很便宜
至少
你的內部資源能處理基本的問題——建立基准規則
聲明響應時間目標
諸如此類——即使你後來雇傭了一個專家驗證處理或者提供更好的建議
對於Java項目來說
有足夠豐富有趣的Java性能調整材料和工具存在
因此性能調整可能被開發者認為是一項積極任務
Java Performance Tuning 網站列出了許多Java性能調整的資源
可以讓你的開發者從那裡開始
象為書籍和雜志在預算中撥款一樣
預算中也要包括培訓和網頁浏覽的時間
還包括為測試和購買不同測試工具的撥款
你的性能專家應該估算如下費用
剖析（profiling）工具;基線;網頁下載或者GUI抓取和重放或者其他的客戶端仿真工具
這些為測試性能和創建基線的工具的選擇
在調整時將產生的不同費用和時間
為這些做好准備
並且確保你擁有正確的方法來根據你的需要做出正確的選擇
理解性能調整和估量工具可能不是開發者的最主要的任務
如果事情進展順利的話
它可能永遠不會成為首要任務
但是
根據我的經驗
越是到了項目快結束的時候
內部的性能專家越是要在性能調整上花費更多的時間
． 在規范中規定性能需求 應用的性能需求需要在制定規范階段定義
這不是開發者的主要任務
顧客和商務專家需要確定什麼樣的響應時間能夠接受
從聲明什麼樣的不能接受的響應時間開始定義可能是較好的辦法
這個任務可能在開發的更靠後的階段被承擔
事實上
它可能比較簡單
如果原型已經寫好
運用原型和其他的商務信息去聲明可接受的響應時間
但是切記
不要在開始任何實現性能調整前忽略聲明響應時間需求
如果代碼調整在性能需求聲明前開始
那麼要實現的目標將會被不恰當定義
並且調整成就將浪費在應用根本不需要的地方
如果你的開發環境是基於層的（應用層
組件層
技術體系層）
嘗試一下在每一個層定義性能規范
使得每一個團隊有他們自己的性能目標去實現
如果不這樣
性能專家將需要能夠跨層調整並且與所有的小組進行交流
． 在分析中充分關注性能 在分析階段
主要的焦點是為應用中共享的和有限的資源分析需求
例如
一個網絡連接既是共享的又是有限的資源
一個數據庫表是一個共享的資源
線程是一個有限的資源
如果沒有正確的設計
這些在以後安裝時將需要花費最多的資源
應該分析數據卷和裝載攜帶容量
以確定系統的限制
這個任務應該融合到正常分析階段
站在安全的一方考慮或者為了突出性能分析需求
你可能希望為性能分析分配計劃分析時間的
%
分析小組明白
不同的設計選擇對於性能的影響是很重要的
因此
了解這些他們不會錯過需要分析的系統的某些方面
分析小組可能首先需要精通於性能目標設計的書籍
諸如《高性能Client/Server》（可以參考更多這方面的資料）
分析應該與技術體系結構分析聯合進行
結束時你應該有一本清楚的確定性能方面的體系結構藍皮書
． 需要從設計中得到性能預報 在設計階段中
分析階段性能考慮的進展應該聚焦於應用使用的共享資源
以及已考慮的要部署的應用物理體系結構的性能地位
確保設計者清楚不同決策的性能結果
這些決策要求性能影響預報應該包含正常設計的各個方面
客觀的設計驗證應該包含精通設計抉擇方面的性能設計專家的意見
另外
一個精通設計的副手性能專家應該檢查應用設計
如果應用了一個重要的第三方產品——例如中間件或者數據庫產品——產品的賣主應該有性能專家能夠驗證設計和識別潛在的性能問題
為了突出性能的重要性
為性能方面分配
%的預算是正常的安全選擇
設計應該包含關於用戶和數據/對象卷的可升級性
應用分布的可能數量依賴於兩個分布組件消息的需求級別
事務處理機制和模式（樂觀的
悲觀的
要求鎖
事務處理期間和鎖有效）
多用戶應用的性能理論限制是共享資源的數量和鎖有效期限
如果相關
設計也應該包含一個關於處理查詢大數據集的章節
． 創建一個性能測試環境 開發階段開始時的性能任務是建立性能測試環境（代碼性能調試時間應該確定在開發階段的末尾
參考第
點）
你需要
· 聲明基於制定規范階段的基准功能和要求的響應時間（第
點）
· 為系統確保合理精確的測試環境
· 為測試環境制定規則的唯一的性能測試時間表
如果測試環境是共享的
性能測試不能與其他活動同時發生
· 購買或者創建一個性能測試工具
這個工具能夠用模擬用戶和外部活動驅動來驅動應用
· 創建提供可再生應用活動的可重用性能測試（注意
這不是QA
測試不應該一直測試系統的失敗模式
除非所有的正常活動全在預期范圍之內）
· 准備測試和監視環境
（這是正常的系統細節
並且通常隨著測試進行而進展
你將最終既需要有網絡統計表和應用級性能（將在點
進一步討論））
還需要有性能監視工具或者監視潛在的系統性能的腳本
· 按照你的性能測試計劃
從你的開發環境到你的性能環境為代碼定版本和發行制定計劃（注意
這常常需要一輪打補丁來嚴格地運行測試
並且時間限制通常意味著等待完整的QA 證書是不可能的
因此將需要一些開發者的支持並且應該為之制定計劃）
． 為驗收測試模擬或者框架系統 創建系統的模擬
該模擬要如實表現應用的主要組件
應該實現該模擬
這樣你就能夠測試系統的可升級性
可確定共享資源如何響應增長的負載
並且確定受限資源在哪個階段開始用盡或者成為瓶頸
當組件可用時
該模擬應該允許完成組件的一體化（組件的整合）
如果預算資源不可用
可以跳過初始模擬
但是一旦有足夠的可用組件來實現系統的框架版本
就要開始測試
這樣做的目的是為了盡可能早點為設計驗收反饋確定系統的響應時間和可升級性
如果你有一個已計劃的概念證明階段
它能夠提供模擬或者一個好的模擬基礎
理想情況下
驗收會作為概念證明的一部分發生
． 將性能日志整合到應用層邊界 將性能紀錄整合到應用
這些記錄應該與發布的應用部署在一起
性能日志應該添加到所有主要層的邊界
I/O和marshaling層
小應用程序I/O和marshaling
JVM服務器I/O和marshaling
DB訪問和更新
事務處理邊界諸如此類
應該設計性能日志
它能給所有應用行為添加至少
%的時間
理想情況下
它可配置成集合大量數據
這樣紀錄能夠被配置成在每一個可配置時間單元產生一個摘要紀錄行（例如每分鐘一個摘要行）
為了更容易處理和分析
你的記錄結構應該進行完美的設計
這樣輸出可以在其他工具裡使用
． 多等級范圍內性能測試系統並運用結果信息進行調整 在代碼實現期間
單元性能測試應該與QA一起安排時間進度
在沒有為QA做好准備之前
在單元級別性能調整不會有要求
單元性能調整通過將單元整合到系統模擬
運行伸縮性測試
並作剖析(profiling)
只要可行
測試整個系統或者仿真是非常重要的
即使有許多單元是不完善的
在系統性能測試的早期模擬單元是可接受的
最初
系統性能測試的目的是驗證設計和體系結構
以及來鑒定將不scale的設計或者實現的任何部分(點
和點
)
到最後
測試應該提供詳細的記錄和概要文件
這些允許開發者直接找到系統中的瓶頸並且產生應用的更快的版本
為了在最後階段支持性能測試
應該能設置testbed(搞不明白
懷疑原文有誤
推測為測試紀錄)
不僅提供任何JVM進程的性能概要文件
還要提供除了性能日志以外的系統和網絡統計
短期（
到
天）預算一下
以獲得來自你的目標系統的系統統計
並加以分析
最理想的情況是
系統管理員已經具備了這些技術
性能測試應該測量用戶和數據的較高負載
兩次測試預期的高峰負載
· 與預期數據量高峰和預期用戶高峰一起
測試兩次預期吞吐量最高峰
· 與預期吞吐量高峰和預期用戶高峰一起
測試兩次預期數據量最高峰
· 與預期數據量最高峰和預期吞吐量峰值一起
測試兩次預期用戶最高峰
用戶活動應該盡可能精確的模擬
但是模擬數據產生預期真實的數據種類是最為重要的
否則高速緩存活動能夠產生完全誤導的結果
用對象的數量來衡量合理的數量
這對檢索測試和批量更新尤為重要
萬萬不要低估為衡量測試而創建大量現實數據的復雜性
結合性能日志特征部署系統 性能日志特征應該與發布的應用部署在一起
該日志允許為已經部署的應用進行遠程分析和持續的性能監視
最好是你自己編寫應用工具
自動分析性能日志
最簡單的能讓人接受的性能日志分析工具要能用日志和一套參考日志來比較性能和突出異常
另外還有其他一些有用的工具
包括能識別性能日志中長期傾向的
能確定什麼時候特異的性能尺度超出范圍的
一個圖形接口的或者支持標准GUI管理工具的工具也很有用
(
最後更新)
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27414.html
