現今許多企業應用程式都會提供Web介面存取，甚至自開發時就完全打造為Web應用。而應用程式執行的狀態，攸關整體運作效能，但企業資訊系統隨著業務擴展日漸龐大之後，一旦出現問題，往往難以診斷出其根本原因，此時即可利用應用程式效能管理（Application Performance Management，APM）工具來協助。
依據Gartner定義APM的管理目標，應可達到執行程式的即時追蹤、計算實體資源耗用量、確認是否成功、執行步驟中延遲相關紀錄、執行失敗因素與資源耗用過多及其延遲之處。不僅讓複雜的程式碼可視化程度較高，更可藉其提供數據統計與分析的結果，來判斷可能造成效能瓶頸之所在。如今隨著企業應用環境變遷，APM受關注的程度更是日漸加重。
架構變遷促APM興起
APM需求的產生，主要是隨著企業應用系統架構的演進而增加。HP軟體事業群資訊系統資深技術經理王秉慎觀察，早期由大型主機轉成Client-Server架構，之後又轉換成Multi-tier、Web Services，甚至讓某一執行程序開始跨越許多應用系統來運作，結構變複雜後，才讓應用程式的可管理性問題浮上檯面。因為終端使用者接觸的是應用程式系統，而不是基礎架構，當接收到使用者反應存取有問題時，如何準確地診斷問題核心，對維運單位而言，就會需要有APM這類工具來協助。
Compuware產品經理Werner Breitfuss觀察，此現象在2005年之後漸趨明顯，因Java與.Net成為主流程式語言，且各有其不同維持效能運作的作法，例如記憶體回收（Garbage Collection）等機制。當時對應用程式執行效能的概念是以Component-based為主，較偏重在單一系統的執行環境，但近年來隨著企業環境雲端化，分散式運算（Distributed Computing）遂成為現代化應用模式，單筆交易行為往往會牽涉到多個應用系統，所以只監看單一系統，很難看出整體運作全貌，「因此需要運用Compuware dynaTrace來追蹤整個交易鏈，也就是從用戶端到資料流皆可整合串連，建立彼此之間的關係，如此一來才有能力釐清問題所在。」
 |
| ▲應用程式效能管理（Application Performance Management）隨企業應用系統架構變遷逐漸演化，至今提供的是以應用程式交易為中心的管理模式。（資料來源：Compuware） |
非侵入式監控應用
就目前會有APM需求的企業來看，王秉慎分析，不管是製造業、電信、金融或政府單位，現在都在談端到端（End-to-End）的管理程式，其中亦包含以往較容易被忽略的程式分析。此管理程序已不再只有基礎架構，還必須涵蓋到應用程式、資料庫，甚是中介軟體的監看，或是自動化執行的程式。
「對金融業而言，APM的重要性相當高，」王秉慎提到，仰賴資訊系統越深，越容易意識到欲維持正常業務營運，不能單只穩固基礎架構，應用程式的問題診斷分析同等重要。只是對於某些證券業而言難度較高，若其應用系統是由Delphi、VB等程式語言撰寫，這方面就不是APM這類工具可協助，因為APM可管理的範疇較著重在Java與.Net平台。
追蹤程式碼執行結果
雖然完整的應用程式管理方案，不管有沒有中介軟體應該皆可應用，但以目前技術成熟度來看，套裝軟體本身若有支援中介軟體，可讓導入難度降低，是比較可行的方式。通常如果談到建置應用程式管理機制，開發團隊最擔心的部分，莫過於要進行程式碼的修改作業，才能夠達到監控管理。除了需額外耗費人力開發外，修改程式碼更是牽一髮動全身，有時甚至會因此反而使系統陷入不穩定狀態。因此導入套裝軟體，或是運用具備支援Java與.Net的APM，以非侵入方式來達到應用程式監控的目的，才不致讓原本工作就吃緊的開發團隊又增添額外負擔。
可分析程式的確是APM基本具備的能力，但有時往往會與程式碼檢測（Code Review）混淆。王秉慎強調，APM主要是針對已經上線運作的應用程式，例如Java程式經過編譯（Compile）後的Bytecode，而非對原始碼執行Code Review。一般談Code Review會是在應用程式生命週期管理（Application Lifecycle Management，ALM）領域，而APM並非是分析每一行的程式碼，較著重是在Function（函式）、Method（方法）、Class等元件。
「因此APM的流程，首先會先找出是哪一個Function Code有問題，並交給開發團隊Checkout（簽出）後，再細部去查看造成例外狀況（Exception）或執行時間過長的原因，加以修改後，也會先進入測試環境，確認沒問題才發佈到線上更新。」
若以電子商務應用程式而言，客戶點選的功能、瀏覽的頁面，都可透過APM來加以記錄其行為。追蹤程式碼的執行行為，重點在於觀察網頁回應時間是否夠快，萬一回應速度變慢，亦可清楚指出拖慢速度之處；或者是出現程式碼例外狀況或執行錯誤時，會發出告警通知，因此APM比較著重在執行結果，而非在後續的資料分析。
至於行動裝置普及後，App的執行效能監控，同樣可運用APM來達成。Werner Breitfuss說明，可藉助dynaTrace UEM（User Experience Management）安置代理程式到行動平台上，來記錄App在執行過程中的所有行為資訊，並且是從手機到應用伺服器、資料庫，完整的執行路徑，萬一應用程式當機，即可追蹤是哪一個環節出現問題，以方便作診斷。
加入App與巨量診斷
且由於APM會擁有應用程式執行紀錄資訊，因此Werner Breitfuss認為，可利用APM事先蒐集有用的資訊，像是使用者操作行為、交易項目等資料，再傳送到Big Data分析環境，還可應用此資料進一步分析。因此dynaTrace進一步加入支援Cassandra、mongoDB、Hadoop等NoSQL技術，這種以分散式架構的儲存資料，而非是關聯式資料庫，該如何得知資料分散式儲存的位置與狀態，在哪一個環節進行查詢動作時會影響效能，皆是不容小覷的細節。
只是王秉慎不諱言，基本上去監看程式碼執行的動作，仍舊會需要耗費運算資源，因此降低應用程式執行效能的影響程度，減少效能消耗（Overhead），會是APM要努力的方向之一。同時增加對新技術的相容程度，像是HTML5、Silverlight等，APM廠商要持續投入研發能量，畢竟軟體功能設計得再好，還必須要能夠趕上前端應用程式變化的速度，才能夠適用於現代企業應用環境。