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

2019-11-18 12:21:10

字體：大中小

來源：轉載

供稿：網友

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

上一篇：Daemon線程

下一篇：高性能Java設計與開發