熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java高級技術 >> 正文

管理人員如何編制性能計劃

2013-11-23 19:45:47  來源: Java高級技術 

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

From:http://tw.wingwit.com/Article/program/Java/gj/201311/27414.html
  • 上一篇文章:

  • 下一篇文章:
  • 推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.