應用程式效能品管 解決方案大閱兵

系統效能對企業有重大影響
以工具協助釐清問題是最有效率的方法

企業深切了解應用程式的效能品管的重要性，然而基於成本考量，相關工具始終是叫好未必叫座的產品。在分散式應用程式架構崛起，及網際網路應用日益成熟之際，企業開始正視效能品管的重要性，也帶給工具廠商新的契機。

與效能有關的議題非常廣泛，除了應用程式外，還包括資料庫、網路、伺服器等，此次採購特輯鎖定應用程式的效能品管產品，從開發、測試到上線，全方位探討各階段的效能解決方案。

關鍵性系統效能的優劣，對企業將造成深遠的影響，ERP系統攸關企業運作效率，老牛拖車的速度不僅影響工作情緒，也降低工作效率。試想如果一個員工的工作型態與應用系統密不可分，當系統效能提升25%，平均一天節省兩小時，一周多10小時，一個月就多出40小時的工作時間，放大到全體員工，企業可節省的人力工時，及員工可創造的貢獻將不容忽視。

對外為企業創造利潤的網站應用程式，效能更顯得重要，客戶對系統的穩定性及執行效能有一定的容忍度，由於選擇性多，因此忠誠度低，在久候不耐的情況下，不但流失商機也賠上企業形象。

要掌握商機就要先了解使用者的需求，叡陽資訊建設整合與管理產品部協理陳美瑛表示：「可用性、效能及處理問題的效率，是使用者對資訊系統的要求。」可用性即工作期間系統可正常運作；效能方面的要求，是系統執行的回應時間夠快，且單位時間的處理量夠多。天有不測風雲，不幸當系統出現狀況時，資訊人員要能迅速排除問題。

硬體升級是解決效能問題最直覺的方法，然而效能瓶頸可能緣自於不佳的程式碼設計邏輯，Borland資深產品經理李匡正表示：「以硬體設備提升程式碼效能問題，是最不智也是最昂貴的方法。」然而當企業的資訊環境因不同的業務需求，而夾雜各種作業平臺及資料庫應用架構，效能問題的釐清也變得困難，對資訊人員而言，維持良好的服務水平是一大挑戰，唯有藉助工具才能有效提升效能管理的品質與效率。開發階段
測試階段

傳統的Win32應用程式，因為是Native Code原生程式碼，無法在程式執行的過程中插入偵測點，如果要偵測效能或處理器執行的狀況，勢必要藉助程式庫（Library），才能搭配效能調校工具控管品質。而Java與.NET由於是VM（Virtual Machine；虛擬機器）的架構，帶給測試工具新的契機，可以從VM層級蒐集效能資訊，因此目前市面上開發階段的效能品管工具，均針對Java與.NET設計。

沒有人比撰寫程式的開發人員更了解他們自己產生的程式碼，開發階段的效能品管，是開發人員在將程式碼交由測試單位前，第一線自身檢視程式碼品質的工具。Java與.NET架構複雜，不藉助工具透視黑盒子裏的執行狀況，很難得知問題點。

不同的開發方法論 對於效能調校的作法

在專案開發接近尾聲時才調校效能問題，往往隱藏過高的成本，新式開發流程強調隨時將效能及穩定性處於可控制的範圍內，進而降低風險以節省時間，並在應用軟體部署前搭配壓力測試軟體，以模擬真實應用環境。

以IBM Rational的RUP（Rational Unified Process）方法論來看，在標準作業規範中，測試從開始就進行，當客戶的需求被具體化與文件化後，測試人員即配合擬定測試計畫，當模組開發完成，即立即進行測試工作。

雖然XP（eXtreme Programming）方法論強調不做用不到的設計，所以認為在開發階段不特別臆測應用程式的效能及延展性，以免開發初期精心設計的暗椿，卻沒有很高的使用機率，導致開發資源的浪費。不過不代表不解決效能問題，如果客戶認為效能是關鍵性的因素，即在程式碼重構的第一輪迴（Iteration），把效能列為首要調整的項目。

李匡正說：「沒有一種開發方法論會把效能問題留到上線後，把客戶當測試人員發現問題才解決。」所以測試與調校如何執行是策略問題，在時間、人力及經費有限的情況下，尋求最精簡成本的方案。可預見的是，專案的風險會隨著開發流程的推進越來越高，導致成本失控或專案失敗的結果。所以在開發階段解決效能問題的成本，遠低於後期付出的代價。

測試階段的工作包括需求分析、擬定測試計畫、功能測試、工作負荷分析、壓力測試及資源預測。其中壓力測試是此階段效能品管的重頭戲，從壓力測試開始，效能問題不再單純只與應用程式有關，系統搭配的伺服器、資料庫、作業系統、網路等各環節都是影響效能的因子。

根據Newport Group研究報告指出，已上線的網站應用程式，平均只能支撐62%的預期負載量，而52%的系統無法隨著實際的負載量變化調整。在應用程式上線前實施壓力測試，了解是否有潛藏的效能瓶頸，及系統的效能極限是否符合企業需求，才能避免系統上線後因效能問題回收。

壓力測試前的 工作負荷分析

壓力測試成功的先決條件是要進行工作負荷分析，正確預測系統可能的負荷，才能給予精確的壓力，過多或過少的加壓，都將導致錯誤的評估報告。

預測系統可能的工作負荷，與工具的技術層面無關，是工具廠商在事前必須提供的專業協助。使用人數估得太少，導致企業信心滿滿上線，卻還是無法應付實際使用量；使用人數估得太多，企業白花很多成本，在購買測試授權及擴充硬體設備。

尤其針對電子商務系統，企業往往也無法預估可能的使用量，工具廠商應提供必要的協助，根據市調結果或過去的經驗，對客戶說明測試方法。例如會員型態的購物網站，即使同時上線人數高達1000人，系統並沒有同時服務1000人，多數使用者是在瀏覽網頁或閒置，可能只有100人真正在執行購物功能，以1000人執行壓力測試豈不成了冤大頭。

壓力測試工具功能的 細緻度決定價格

傳統常見的壓力測試方式，是利用假日或非交易時間，發動大量的人力搭配電腦設備，在同一時間操作系統，以碼錶計時，透過人工蒐集效能資訊，憑直覺判斷是否可負載大量的交易。如果順利發現問題，在修改程式後，或者未來更新版本的時候，仍必須再次重複這樣勞師動眾的過程，不但浪費人力、物力、金錢與時間，而且粗糙的測試方式與數據，並不夠準確只能求心安。

透過自動化的工具執行壓力測試，量測效能數據，不但精準且更節省成本。壓力測試工具的基本功能包括模擬使用者的行為、可以修改腳本、設定加壓方式、監控測試過程、提供即時的測量資料並提供詳細的分析報告。

綜觀各家壓力測試產品列出的功能，基本上大同小異，價位從免費到上百萬之譜，Apache基金會Jakarta計畫的JMeter即為免費的壓力測試工具。隨著壓力測試工具價位的不同，功能細緻度及數據精確度也有天壤之別，企業選擇的取捨，在於模擬的精緻程度、腳本客製化及加壓模式設定的彈性、效能數據提供的詳細程度及平臺系統支援的廣度。許多資訊大廠指名特定壓力測試產品為標準測試工具，就是為了確保測試數據的可信度。

葛莉數位技術經理王大興認為：「對外開放的網站應用程式，在企業內部與網際網路都要進行壓力測試。」主要目的是釐清效能不彰的原因，是否與網際網路有關。兩者差別在於路由器或防火牆。內部測試可確認效能問題是否與伺服器端有關，外部測試則確認頻寬、路由器及防火牆的問題。王大興進一步說明：「防火牆的問題最大。」可能防火牆設定的策略（Policy）順序不佳，導致網頁需經過層層檢查而拖慢速度。

壓力測試後的資源預測

當系統效能未達要求時，是修改軟體程式還是升級硬體設備？壓力測試工具可提供企業正確的投資方向，錢花在刀口上，才能提高投資報酬率。透過壓力測試把效能調到最好，減少硬體支出是經濟的方案。在確定程式碼無從調校起，必須升級硬體以解決效能瓶頸時，可透過資源預測了解投資的方向。

從資源預測的角度分析，壓力測試分為兩種用途，一種是已知可能的壓力，確認應用系統能否負荷這樣的使用量。另一種是未知壓力，除了以工作負荷分析預估可能的上線人數，就是在壓力測試時持續加壓直到出現瓶頸點。找出瓶頸點後再作資源預測分析，規畫上線後當壓力逼近臨界點時的因應措施。

叡陽利用BMC的解決方案中，有包含資源預測的工具，可輔助企業作為決策的參考，不過最後還是必須仰賴專家的判斷。王大興即表示：「當資訊系統變複雜時，以工具預測的價值剩多少？」單純的系統及硬體架構，藉助工具預測準確率較高，但是當企業營運的系統參雜多種平臺、資料庫及程式類型時，還是必須由專家彙整資訊提出建議，更何況當企業的預算有限時，決策及調整的方向也需彈性應變。上線後

即使系統從開發階段的品管到測試階段的壓力測試都有落實，也不代表企業從此可以高枕無憂，因為單純的測試環境，與實際上線的環境及可能發生的狀況存在盲點。這不代表前面的努力都是白搭，萬全的準備可確保系統本身的品質，降低上線後因效能問題而回收的風險。但是個別品質良好的個體所組成的資訊系統不代表就一定良好，因為交互作用之下，可能發生彼此衝突與不相容的地方。

上線前未經測試的系統，也只能透過APM（Application Performance Management）工具釐清責任，一個系統的問題通常不是一個癥結點造成，必須根據問題的迫切性循序解決。即使系統上線時效能沒有問題，經過長時間的演變，也會因為使用者人數增多、資料量變大、應用程式增加或設備版本變更等因素影響執行效能。

網站應用程式的8秒定律

根據2000年Zona Research的調查，網站使用者對網頁反應時間容忍極限是8秒以內，也就是說從按下網址到網頁完全呈現，若超過8秒使用者就很有可能選擇放棄，此即所謂的「8秒定律」。時至2004年，使用者要求的效率應更為嚴苛，反觀國內各大網站的執行速度，企業是否該捏一把冷汗？

目前多數企業對於實際上線的網站應用程式效能監控的概念，普遍仍停留在以網管的角度監控流量，而非監控效能，然而網路流量高、處理器及記憶體使用率高未必就效能不佳，只表示物盡其用而已。相反的，使用者反應效能不佳時，檢視硬體使用率及網路流量也未必會很高，可能是不良的設計架構所導致。所以應該透過APM工具，捨棄以硬體使用量為出發點，改從使用者的角度出發，檢視效能數據。

APM的基本功能

APM產品的標準特色是Web化的使用者介面，以方便管理者遠端監控。陳美瑛表示，上線後的APM產品應包括 : 效能問題通知、問題診斷與排除及問題預防的機制。

依據實際的情況，企業往往等到客戶打電話罵人，才被動得知系統出現問題。在緊急的情況下，要短時間內找出問題並迅速解決，不但困難而且壓力很大。若能在災難發生出現前兆時，即時發現並提供預警，便可在使用者察覺異狀前找出癥結點，進而解決效能瓶頸。

因此APM產品透過持續的監控機制，蒐集資料庫、網路、伺服器及用戶端等的效能資訊，並藉由明確的設定應用程式的SLA（Services Level Agreement；服務等級協定），一旦效能超出服務等級時，即發出警訊通知管理者，以確保服務品質。例如設定可容忍的系統反應時間是8秒以內，當反應時間略微超過8秒時，使用者並不會馬上察覺，但管理者可設定6秒的達成率不到90%即發布警示，更嚴重8秒的達成率不到90%發布嚴重警示。如此即可爭取足夠的時間，在災難擴大前發現並排除問題。

目前新的概念認為，SLA的解釋是企業與使用者雙方同意的契約，保證服務等級應有的品質，不過目前應用上仍偏向管理者單方面主觀定義的門檻，所以意義不大。因此傾向於由系統自動計算每日的效能平均值，當系統的效能超出平均值，表示系統出現不正常的情況，使效能不及一般水準，即發布警示。

問題解決方面，目前APM產品分為兩種類型，一種是提供初步的判斷指出影響效能可能的問題點是在用戶端、網路或伺服器，作為企業調校的參考；另一種可提供詳細的資訊包括網頁及程式的剖析，再搭配專業的顧問服務，協助企業解決問題。兩者訴求不同，價格上也有顯著的差異。

進一步的預防工作則屬於APM進階的應用，即預估未來可能的使用者成長率及設備需求，BMC、Tivoli、Unicenter等多項APM產品均有提供趨勢分析及容量規畫功能，並再搭配顧問服務，而Mercury Interactive則由原廠提供ProTune解決方案，是以現有的環境再加壓，直到效能出現瓶頸為止，再提供專家建議。當然，隨著系統環境的複雜度增加，專家的建議報告超越工具提供的實質意義。

美工與效能的拉鉅戰

網頁設計是企業專業形象展現的重要戰場，尤其網站首頁的重要性猶如企業的門面。同質性的網站相較之下，具特色的網頁設計，對使用者較具吸引力。但是過於細緻的美工處理，對網頁下載的效率是很大的負擔，所以網頁設計人員不能只站在美工的角度，思考網頁構圖，關於網路下載的原理及罩門應有所了解，才可避免不適當的設計。

網頁下載有所謂的下載時間（Download Time），組成網頁的所有內容包括表格、按鈕、Applet元件、圖檔及PDF檔等，都是個別的元件，雖然電腦可多工處理，不會一次只下載一個元件，但也無法同時下載所有的內容。元件的下載時間雖有重疊的部分，但是越多的元件，耗費越長的下載時間。

一個圖檔就是一個元件，當一個網頁包含10個圖檔，就必須累加10個下載時間。很多網站首頁放很大的底圖作為背景，但擔心一張底圖的下載時間太長，所以切成九宮格，變成9張小圖拼成一張大圖，事實上，下載9個物件的時間大於下載1個物件的時間，反而拖慢網頁呈現的速度。

當然，一張圖檔的大小也會拖慢下載速度，所以即使是一大片空白的圖，也會佔下載時間。美工人員應盡量將圖檔的修邊修到最小，減少不必要的空間浪費。另一個重點是圖檔的解析度，企業尤其喜歡在首頁擺放充滿專業形象的照片，模糊或有巨齒邊的照片會影響網頁的質感，但過於清晰的照片相對降低下載的速度，適度犧牲樹葉及髮絲的完美呈現，可以大幅提升執行速度。

首頁最重要的部分，莫過於代表企業的商標圖檔，因此花費最多的心思在於設計有創意的圖案，然而，當商標置於網站時，精美絕對不是最重要的考量因素，否則商標將成為拖慢網頁下載時間的最大元兇。透過APM的下載時間分析圖表，可了解各元件耗費下載時間的長短，若企業商標是佔用下載時間最長的元件，表示使用者進入首頁後，始終缺了一角，最後才出現的部分，竟是代表網站精神的企業商標。

美工是網站必要的付出，陽春又單調的網頁內容，即使執行效能良好，也會降低使用者的興趣。首頁是影響使用者是否繼續瀏覽網站的關鍵門面，所以美觀與專業之餘，最好不要擺放影響效能最致命的Applet元件，也應避免過多且精緻的圖檔，取捨之間的衡量，可以8秒定律為依歸，求得美工與效能兩者之間的平衡點。

代理程式的取捨

安裝代理程式必須考量相容性問題，而且執行代理程式難以避免會佔用系統資源，最重要的是，銀行及證券等安全性要求較高的系統，並不允許加裝任何代理程式。

不可諱言，安裝越多的代理程式，取得的效能資訊越底層也越詳細，但相對所需付出的成本也相對提高。當然，面臨效能瓶頸，必須藉助代理程式取得最詳細的資訊時，企業可與廠商簽定保密合約，以確保安裝代理程式後，資料的安全性。企業選擇工具輔助監控及調校效能時，所需資訊的深入程度及經費都是考量的重點。

效能調校與否的抉擇

李匡正說：「軟體出貨前解決問題的成本，遠低於到客戶手上才修正所付出的代價。」隨著開發時程的演進，程式調校困難度及成本相對提高，應用程式牽一髮而動全身，解決一個問題可能引發其他問題，也可能越改越糟，或者評估起來修改的成本大於硬體升級的成本，種種考量因素，也是效能調校往往需要藉助專業顧問的原因。

在上線壓力與調校與否的拉鉅戰及經費的考量下，先升級硬體以控制效能在合理的範圍內，再依重要性優先次序慢慢修改程式，可能是折衷的辦法。

不管最後的決定是升級硬體還是調校程式，前提還是要先找出問題，再衡量解決之道，有實際的案例因為調整資料庫結構及程式邏輯，效能提升4倍；也有案例花費上百萬升級硬體，卻毫無幫助等於白搭。

效能解決方案的春燕來了嗎？

陳美瑛表示：「應用程式的效能解決方案，叫好卻未必叫座。」此類產品的需求其實一直存在，但是國內企業對於應用程式品質及效能管理的概念仍待持續教育。各家廠商舉辦的研討會，從兩年前乏人問津的尷尬場面，到近來場場爆滿的盛況，確實表示開發人員已意識到效能管理工具的重要性，但是企業購買的意願仍然低落。

現今有意願參考效能品管產品的企業，多是已遭遇嚴重問題才會想尋求解決之道，但往往因為昂貴的價格而退避三舍。企業必須意識到關鍵性系統，停機的損失可能遠大於工具的投資，在問題發生前偵測出前兆，才有充分的反應時間，解決問題避免停機。

不過隨著Java及.NET分散式應用程式的出現，及電子商務的普及，將迫使企業重視效能問題，也帶給解決方案廠商新的商機。從近年來多家工具外商積極來臺試水溫的情況來看，外商的確嗅到了春天的氣息。

顧問服務的價值未抬頭

陳美瑛表示：「沒有一個工具可以解決所有的問題，所以工具不等於解決問題的能力。」目前並沒有公認效能品管的認證，只有以工具為主的認證，但會使用工具不等於解決問題的能力，所以工具只是協助，雖然工具可提供問題的剖析，但並沒有辦法人工智慧到可明確點出問題所在及如何解決，多透過警訊通知管理者效能不彰的部分，仍要藉由專業的顧問服務協助企業，分析數據解決問題。

顧問服務的價值在臺灣一直不被肯定，端視事情的急迫度決定專家建議的價值。不過，山不轉路轉，已有資訊廠商改以主打顧問服務，再由顧問服務衍生工具的商機。叡陽及網星資訊均表示，不少客戶初次採取租賃工具及服務的方式解決燃眉之急，後續再次遭遇效能問題時，企業主即有意願採購工具。

資訊系統也該買份保險

企業應建立觀念，將壓力測試列入驗收規格，以避免系統上線後因效能問題而回收，卻求助無門，更以此迫使軟體開發商注重程式品質。就因為企業的觀念認定壓力測試及APM工具是一次使用性的產品，所以不願花錢投資。許多軟體開發商是為了取得測試報告，以通過驗收才尋求壓力測試工具，事實上壓力測試並不是只有測試階段才用到，未來應用程式改版、硬體、作業系統、資料庫升級或安裝修補程式，皆需執行壓力測試以確保品質。

APM工具更是確保服務不打烊，以使用者的角度量測效能的依據，才能了解使用者的真實感受。在系統西線無戰事的時候，效能品管工具的投資看似一種浪費；當效能出現瓶頸，工具發揮作用提供實質的幫助順利排除問題，才能真實體會價值的存在。所以此類投資類似保險的觀念，在保險意識抬頭的今天，企業是否也該為關乎營運命脈的關鍵系統買份保險？這些專有名詞你搞懂了嗎？

分散式架構的問題複雜，不藉助工具很難發現記憶體漏失、過多的物件配置、執行緒競爭、匱乏及鎖死等程式邏輯上的問題，了解這些繞舌的專有名詞，也有助於避免撰寫程式時犯錯。

記憶體漏失：

過去傳統的C、C++等語言，可自由操控指標（Pointer）配置記憶體，但如果開發人員忘了釋放，將無法回收佔用的記憶體空間，此即典型的記憶體漏失。

Java與.NET都具有自動GC（Garbage Collector；資源回收）的特色，因此傳統記憶體漏失的情況不再發生，但仍會產生物件閒置（Loiterer）的狀況，即因為程式邏輯上的錯誤，使短暫使用的物件持續被某個長時間執行的物件參照，導致記憶體永不釋放。

過多的物件配置：

過多暫存物件的不良寫法，會造成GC頻繁回收記憶體而影響效能。李匡正舉例：「Data=Data+“Hello”與Data=Data.concat(“Hello”)兩種方式語法都對，但同樣執行3000次，前者使用的記憶體空間為後者的3倍。」透過工具可找出產生暫存物件的程式碼所在，以檢視是否有更好的程式寫法。

執行緒競爭：

多個執行緒同時運作時，共用的資源例如變數值可能會相互干擾，開發人員可採取保護機制，讓執行緒依序執行。萬一某個執行緒「佔著茅坑不拉屎」，在資源有限的情況下，致使其他執行緒排隊等待，就會造成效率低落。

執行緒匱乏：

伺服器端應用程式常見的狀況，電腦可用的資源是固定的，在多執行緒同時執行的情況下，當某個執行緒佔用過多處理器或記憶體資源，相形之下，其他的執行緒就分不到資源。

執行緒鎖死：

也就是執行緒彼此互等，導致整個程式停頓。工具與服務的完美結合才是最佳解決方案

根據IDC的調查，企業資訊系統發生問題急需解決時，卻花費70%的時間在找問題，剩下30%才用於討論如何處理及實際解決問題。可見加速釐清問題及責任歸屬的效率，即可強化處理問題的速度。

由於效能品管的議題敏感，企業對於這方面的問題往往不願多談，以免自曝其短影響企業形象。因此，此次採購特輯尋求願意採訪的案例相當困難，A電信業者因為肯定叡陽資訊的專業服務，願意以匿名的方式，提供自身的經驗實屬難得。

電信業對於網路及服務的品質相當注重，因此即使了解效能管理產品高價位的特性，仍然視為必要的投資。A業者在參考比較數家產品後，選擇叡陽資訊的Compuware Network Vantage及Application Vantage的原因，除了產品符合需求外，過去與叡陽已有合作的經驗，認為叡陽可提供專業的顧問服務，也是主要的原因。

Compuware解決方案主要應用於A業者的企業內部，過去透過網管工具雖可得知網路的流量，無法了解應用的情況，哪個應用系統才是始作俑者，造成網路流量爆增卻不得而知。由於各單位的系統管理獨立運作，但使用共同的網路架構，當網路流量增加時，若無法得知癥結點，便會發生互相推諉責任的情況。

雖然封包監聽工具可取得更詳細的資料，但也因為資料量太大，不適合長期使用。A電信業者傾向主要先以Compuware的產品，初步了解網路行為，再決定是否進一步使用封包監聽工具蒐集封包的內容。

為確認Compuware是符合需求的產品，A電信業者先試用一段時間後，確認Compuware可以透視應用程式層級的資訊，協助管理者掌握網路上的行為，才確認導入Compuware。當網路流量出現異常時，即可透過Network Vantage迅速釐清原因，了解哪個人或哪個系統在大量佔用網路資源，並剖析使用的用途。

監控機制保留網路行為的資料，也可產生報表作為主管決策及管理的依據。A電信業者的資訊主管表示：「效能管理是合理的投資。」面對遍及臺灣各地的分公司，以監控機制確保系統的穩定及效能，後勤單位才能支援服務單位的運作。

專業效能管理工具的導入，不像使用辦公室套裝軟體一樣單純，使用者無法在短時間內輕鬆上手，因此顧問服務及技術支援佔有相當的比重。A電信業者在導入的過程中，叡陽提供充分的教育訓練及技術支援，並協助客戶分析效能瓶頸。資訊主管說：「廠商本身對工具接觸時間的長短及專業能力是重要的考量，因此工具與服務兩者重要性相當。」如果廠商對工具的了解不夠深入，常常需要尋求原廠協助，對於企業解決問題的時效及可靠度將大打折扣。

為完整蒐集各區的效能資訊，A電信業者在各重要骨幹網路建置探測點（Probe），作為分析效能瓶頸的依據，Compuware可彙整所有探測點傳回的資料，成為統一的報表，管理者一眼即可得知導致效能瓶頸的癥結點。

經過長時間監控網路的封包，取得流量及反應時間的數據，即可計算平均值作為基準點，當流量或效能超出基準點，即可能是異常狀況，可設定Compuware自動發出警訊，管理者再藉由網路流量與伺服器反應時間的分析，找出效能瓶頸。

管理者也可自行設定的效能門檻值（Threshold），當潛在問題發生徵兆時，即發出警訊通知負責人員，在使用者發現異狀前排除問題。

A電信業者未來希望能建立QoS（Quality of Services）平臺，提供更完整的服務品質報告，以確保應用系統的服務不打烊。文⊙李延華