管理應用程式效能必學的10個字

小朱仔

文/李延華 (記者) 2007-07-29

從用戶端、網路、應用伺服器到資料庫，任何一個環節都可能是導致系統效能不彰的原因，透過APM產品，可深入每一個節點，監控效能、流量、使用率，找到瓶頸之所在。

APM，Application Performance Management
應用程式效能管理在Web世代蓬勃發展
等到Web應用程式蓬勃發展之後，系統架構複雜度大幅提升，APM產品也因而受到重視。因為在異質（Heterogeneous）的軟、硬體並存環境下，監控系統效能並剖析瓶頸之所在形成了許多挑戰。

細分APM應用的層面，可分為「開發階段」的效能剖析、「上線前」的功能測試、壓力測試（Stress Test）、資源預測，及「上線後」的持續監控與問題剖析。

開發階段主要鎖定在是否因為程式設計的不良，導致有記憶體漏失（Memory Leak）、閒置，或者透過程式碼涵蓋分析，找出未曾執行到的多餘程式碼，確保應用程式的品質。

上線前的功能測試則是要幫助企業確認部署在不同平臺下的系統，是否能正常運作。

而壓力測試則模擬大量使用者上線操作的情況，以確認系統上線後，能否負荷實際環境的交易量，或者也可以一直加壓到系統出現瓶頸，幫助企業預測目前軟、硬體及網路資源的極限，及後續的資源規畫量。

系統順利上線不代表從此天下太平，無論網路品質不穩、當機或者反應時間拖長，都會降低使用者滿意度，因此上線後的監控，主要是希望提高系統的可用性（Availability），提供良好的操作體驗。文☉李延華

Heterogeneous System
異質系統
在Web盛行的情況下，企業可以搭配的軟硬體組合更加多元，從伺服器、作業系統、程式語言、應用伺服器到後端資料庫，每一個層面都有3種以上的選擇。

產品多元化的好處，是企業可以針對需求選擇最適合的組合，但從管理者角度來看，環境複雜，監控與管理的困難度便大幅提升，因此，APM產品競爭的重點之一，便是對軟、硬體各種平臺的支援度。

Bottleneck
瓶頸
應用程式效能不彰的原因，可能是用戶端的問題，也可能是頻寬不夠、伺服器的處理器運算能力有限、記憶體太少、資料庫負荷過重，或者程式設計不良，導致記憶體逐漸被占滿。

雖然升級硬體通常是成本最高且立竿見影的方法，但唯有找到真正的瓶頸之所在，才能真正有效地提升效能。在APM的案例中，曾經有調整資料庫參數後，即解決效能問題的企業典範；也有不惜巨資升級硬體設備，卻毫無幫助的慘案。

Stress Test
壓力測試
傳統壓力測試的方法，是在非營業日把員工找來加班，同時操作系統，以測試系統能否承載多人連線的情況。

透過壓力測試的工具，只要套用腳本，即可模擬巨量交易的情況，管理者可設定固定上線的人數，檢視操作的情況；或者設定較少的初始人數，然後逐漸增加到特定的使用量。系統也可以不斷增加使用人數，直到出現瓶頸為止，以幫助企業了解目前的系統設備可以負載的極限。

Memory Leak
記憶體漏失
由於在C/C++等程式因為語言本身沒有內建資源回收（Garbage Collector）的機制，開發人員忘記釋放不再使用的物件，將無法回收被占用的記憶體空間。

Java與.NET都具備自動執行資源回收的機制，記憶體漏失的情況不再發生，但仍會因為程式邏輯上的錯誤，使短暫使用的物件持續被某個長時間執行的物件參照，導致記憶體永不釋放。

Scenario
測試情境
無論是功能測試或者壓力測試，第一步就是錄製測試情境，也就是測試案例。情境的製作通常不需要動手寫程式，而是依據使用情境或功能分類，例如網路下單、客戶資料查詢或者網路轉帳等功能，利用工具錄下使用者操作的行為，工具本身會自動產生腳本（Script）。

當企業累積了越來越多的劇本，系統上線或微幅改版之前，就有越多的測試案例可以拿來驗證系統的正確性與效能。

SLA，Service Level Agreement
服務等級協議
當使用者反應應用程式很慢，是描述一種主觀的感覺，到底是3秒算慢？還是10秒才是慢？

上線監控的APM工具中，即可設定服務等級協定，作為監控與量測的依據。當系統回應的速度，超過管理者設定的範圍，即發出警訊或電子郵件通知管理者，即可在使用者察覺有異之前，發現並解決問題，以提供穩定且有品質的服務。

Transaction
交易
不同系統對交易的認知有極大的差異，從資料庫的觀點，是指一組SQL指令例如新增、刪除、修改或查詢動作的完成。而Web應用程式所謂的交易，是指使用者點選新的連結或者提交（Submit）網頁，使得瀏覽器傳送要求（Request）至Web伺服器，這可能需要存取資料庫，或者再觸發後端的某個程式，最後回應（Response）結果給瀏覽器，上述這整個過程都是一次交易會涵蓋的範圍。

Simulation
模擬
運用工具建立自動化的測試案例，即是希望取代人工，模擬使用者操作的行為。另一個模擬的重點，是APM工具必須能以不同的使用者身分登入系統，因為許多應用系統會要求使用者必須先登入帳號╱密碼，然後根據身分類型賦予不同的權限。

測試人員可以設定資料庫，匯入事先準備好的多組帳號╱密碼，那麼APM工具在執行測試案例時，即可利用不同身分，同時模擬多個使用者的行為，測試系統的功能與負載能力。

Availability
可用性
若系統產生非計畫性地停機，或者故障的次數頻仍，即代表可用性不佳。

目前市面上有許多備援、故障復原或者負載平衡機制的產品，可以在問題發生時，避免服務暫停的情況。而從APM的角度卻不只是確保服務不停止，而是希望透過持續、即時的監控，幫助企業提早發現徵兆，以排除停機的可能性，以確保商譽。

david_chen

很有幫助的英文資料  謝謝大大分享