應用系統測試及效能監控管理解決方案

為避免應用系統因效能問題而被迫回收，企業應正視效能問題，明列壓力測試於驗收規格中。系統上線後，效能也會隨著時間的久遠而漸漸變慢，因此搭配APM工具，在使用者察覺異狀前，發現並排除問題，才能避免停機時間，保障企業營收。

在應用系統上線前，即使已經過多次的沙盤演練，上線後仍難免經歷一段陣痛期，其中效能不彰是最常見的瓶頸。企業及資訊廠商應正視開發及測試階段的效能測試，才能有效避免應用系統因效能問題而被迫回收。即使系統順利上線，系統效能也會隨著時間的久遠而漸漸變慢，因此搭配APM（Application Performance Management；應用程式效能管理）工具，在使用者察覺異狀前發現並排除問題，才能避免停機時間，保障企業營收。不同類型的產品，各有千秋
何時該關注效能問題

Borland Optimizeit ServerTrace專精在J2EE領域，屬於部署前（Pre-Deployment）測試階段的程式效能剖析工具，不包括硬體效能分析，必須搭配壓力測試產品，以產生數據分析效能。其特色在於可提供原始程式碼層級的效能資訊，可與JBuilder結合直接開啟整合開發環境，顯示可能有問題的程式碼段落。

Mercury Interactive LoadRunner是壓力測試工具，支援廣泛的企業環境，可產生大量的虛擬使用者，並以監控模組蒐集包括軟硬體所有環節的效能數據；Veritas i3則在應用程式上線後，以Veritas i3方法論為基礎，監控應用系統實際的使用情況，並可透過詳細的歷史記錄，回到過去發生問題的時間點，分析當時的數據找出效能下降的原因。

測試階段及上線後的效能監控管理工具，差別在於訴求的對象，及提供資訊的詳細程度不同。在系統上線前的開發測試階段，使用的效能監控管理工具，所蒐集到的資訊，對於解決問題的技術人員而言，提供更深入、底層的剖析，確保應用程式本身的效能無虞；而適合在系統上線後使用的效能監控工具，則更廣泛地監控系統的軟硬體，著重在使用者察覺異狀前發現問題，即時反應給管理人員，並分析可能影響效能的原因，以提供修改的建議，可據以要求開發單位或資訊廠商改進。

不論任何開發方法論，都不會把效能問題留待到客戶手上。Borland資深產品經理李匡正說：「軟體出貨前解決問題的成本，遠低於到客戶手上才修正所付出的代價。」開發階段留意效能問題，透過教育訓練培養良好的開發習慣，避免不合理的程式邏輯；測試階段搭配壓力測試及效能監控工具測試效能，不能把客戶當作測試人員來驗證效能。

即使應用系統通過壓力測試順利上線，系統效能也會隨著時間的久遠，因為資料量變大、使用者人數攀升及實體線路負荷量等因素而慢慢變差。因此針對企業的關鍵系統，仍需持續監控即時的狀況。通常很難要求使用者清楚描述問題發生當時的情形，只有藉助即時監控系統的記錄（Log），可回到發生問題的時間點了解問題。

壓力測試更不僅是開發測試階段的工作，作業系統、資料庫等系統廠商推出修補程式（Patch）、應用系統改版及硬體更新等因素，均需執行壓力測試以確保系統可靠度。

在效能分析上，請原廠協助排除問題可能存在盲點，廠商以各別效能監控工具單一面向地檢測，不見得可以抓到瓶頸，而發生互推責任的情況。因此透過全面的效能監控，剖析點對點的數據，彙整所有環節的資訊，才能準確找到效能下降的主因。J2EE市場大，效能監控產品多

許多應用系統測試及效能監控管理工具，是針對J2EE領域設計的產品，容易給人Java效能問題比較嚴重的錯覺？根據分析機構Gartner的統計，80%的企業已採用Java程式語言，但有50%的J2EE系統部署後，因效能問題回收。Giga更指出75%新式J2EE系統上線後，必須採用更高級的硬體設備，以解決效能問題。李匡正認為：「Java技術已相當成熟，技術複雜度高且架構龐大。」藉由工具的協助才容易從Servlet、JSP、EJB、JDBC、JNDI及JMS等，所組成的黑盒子中找出效能瓶頸所在。

璨碩科技認為，從經濟規模及成本效益的觀點來看，由於效能測試與監控管理工具的價位頗高，動輒數百萬甚至上千萬的J2EE解決方案，較願意搭配效能測試與管理工具，以保障投資。而微軟的解決方案多數經濟規模較小，因此採購效能管理工具的意願自然降低。

不過Java以外的應用程式也有效能問題，一般認為主從架構的應用程式，執行程式的負擔已分散在各別電腦，除非寫了離譜的程式邏輯，例如不合理的迴圈，否則不會有嚴重的效能瓶頸，因此解決效能瓶頸多從資料庫著手。

但是，璨碩科技表示，主從架構的效能問題只在於資料庫是不正確的觀念。常見的狀況是，在資料庫命令提示列直接執行SQL陳述式很順暢，但在應用程式執行時卻很慢。所以效能監控不能只看前後兩端，問題可能出現在其他環節，例如網路設備、實體線路、硬體設備、甚至資料卡在佇列（Queue）。測試及效能監控管理工具的挑戰

對開發團隊而言，開發及測試階段的效能監控工具，必須深入黑盒子，提供原始程式碼層級的效能資訊，才是方便的工具。

壓力測試牽涉的層面更為廣泛，必須精確模擬用戶的真實作業，例如網路銀行必須模擬大量的使用者，以相對的帳號密碼對應到各別的虛擬使用者，並精確執行查詢、轉帳、繳款等對應的交易行為。

若企業採用的壓力測試產品，只能支援有限的技術與標準，未來導入其他應用系統時，就有不敷使用的可能。因此，壓力測試工具必須支援現在的技術與協定標準，除了目前最流行的Java、.NET、Web Services及熱門的ERP產品，甚至包括使用族群不多的小眾產品。所以工具支援技術與標準的速度、廣度及完整度都是競爭的重點。

壓力測試及效能監控初步的目的，是了解系統回應使用者要求（Request）所需的反應時間，及同時間可負荷的上線人數，以確認是否達到企業要求的標準。更進一步是要抓出效能下降的原因，因此必須有完整監控的機制，監控應用系統的所有環節，找出導致效能瓶頸所在。 效能監控機制必須蒐集執行應用系統的效能資訊，然而監控效能也可能反成為效能的負擔，所以各家廠商均致力於降低本身對系統的負荷。Mercury Interactive強調，多數效能監控產品透過代理程式（Agent）蒐集資訊，而LoadRunner對於大部分的系統均不需安裝代理程式，而是以API直接取得數據。不過由於Java沒有標準的效能計數器，所以Borland、Mercury Interactive及Veritas的產品均需安裝代理程式。專業能力不足，可能越改越糟
正視效能管理問題，才能保障企業IT投資

效能測試及監控的產品，都是高價位的產品，為避免企業試用產品後，找到問題即不購買的投機取巧心理，各家廠商對於產品的POC（Proof Of Concept）授權均相當嚴格。不但限制天數且不假他人之手，由專業人員展示性能，以微量的壓力證實工具的可用性，而企業必須購買授權才能取得具意義的資訊。

除了價格昂貴，也需要足夠的專業能力解析數據，再加上修改系統架構牽一髮動全身，如何調整才不會愈改愈糟，需藉助專業的顧問服務。因此產品的採購方案相當富有彈性，多數廠商可提供產品租賃，Mercury Interactive甚至可租賃專業顧問駐點指導。所以系統測試及效能監控管理工具與其說是產品，不如說是解決方案。廠商在深入了解系統架構後，分析需求並考量企業預算，提供量身訂作的解決方案。

在國外相當注重軟體開發流程，雖然效能測試及管理產品的單價高，一般上軌道的企業，仍會視測試團隊及工具為合理的投資。而國內的企業由於軟體品質及效能管理的概念尚未成熟，往往以硬體升級解決效能問題。

目前公家單位已開始推動，明列壓力測試為驗收規格，企業也應建立正確的觀念，保障自身權益。以硬體升級解決程式碼效能問題，是最昂貴且治標不治本的方法，若升級硬體仍未緩解效能瓶頸，一切的投資等於白花。投資必要的測試及效能監控管理工具，企業才有具體投資的方向，可大幅降低採購成本。確認程式碼沒有問題，也無從調校效能了，再投資高效能的硬體設備也不遲。文⊙李延華