本文針對當下市面上存在的監控技術問題給出的四點四大優化意見，旨在幫助Web 2.0開發者有效利用APM解決方案解決上述難題的。
隨着Web應用程序速度與效率快速增長，網站已經成爲企業與其客戶進行交互的第一途徑——某些情況下甚至成爲惟一途徑。在線電子商務網站的爆炸式發展就是這種情況的集中體現。
根據Forrester研究公司最新發布的報告，美國國內在線零售業務總銷量至2017年將達到3700億美元——相當於在未來幾年內美國在線零售業年度複合增長率都將保持10%以上。爲了保持自身競爭力，經營實體店鋪的零售商們被迫將其關注重點轉向在線銷售渠道，從而避免成爲Amazon.com及其它電子商務網站的免費展示設施。當然，這股風潮的涉及範圍遠不止於零售行業。
網站能夠以成本更低的解決方案爲客戶帶來產品與服務，此類機制與在物理位置提供現場服務的傳統機制相比顯然更具成本效益。
IT消費化趨勢同樣對網絡經濟體系的發展起到了推波助瀾的作用。消費者希望能夠在任意所處位置、通過任意設備訪問更多服務。根據Flurry Analytics公司的調查，智能設備的普及速度比上世紀八十年代的PC革命快了十倍還不止，即使是上世紀九十年代的互聯網風潮與近年纔出現的社交網絡覆蓋在速度方面也分別只達到其二分之一與三分之一。
有鑑於此，在線體驗——以及對網站在速度與功能多樣性所提出的要求——已經成爲關鍵甚至是核心。一系列趨勢性特徵已經在Web應用程序的設計當中顯現出來，通常藉由Web 2.0技術實現、例如JavaScript與AJAX，其中包括：
降低頁面加載數量。很多電子商務網站會通過減少用戶瀏覽與結賬所需要的頁面數量來簡化整個購買流程。舉例來說，消費者在填寫計算機配置單的過程中，完全可以在無需重新加載整個頁面的前提下變更自己的選項、從而快速搭配出能夠滿足需求的組裝機方案。
異步頁面加載機制。通常情況下，我們所使用的大多是HTML頁面，這種方式能夠大大提高網頁的性能表現。具體來說，系統會首先加載體積較爲小巧的HTML代碼，而後以異步方式逐步加載其它體積更龐大的元素。舉個例子，主頁面會快速加載完成、全部信息與功能都以異步方式率先交付給用戶。在此之後，宣傳廣告以及內容區信息（通常在操作後才需要顯示）才逐步載入完成，並異步顯示在我們眼前。
純客戶端處理。現在對頁面中各事件的渲染已經可以在完全不必與後端服務器產生交互的前提下完成。在這種情況下，對應內容由Web服務器作爲頁面的組成部分加以交付，但並不會直接予以顯示——除非大家在操作中觸發了相應事件。舉例爲說，當用戶將鼠標懸停在某個下拉菜單上時，對應選項纔會顯示出來。
內容分發網絡（簡稱CDN）。通常情況下，來自瀏覽器的HTTP請求會由CDN或者其它緩存技術負責填寫，這就避免了時刻觸及後端Web服務器所帶來的性能折扣。這種處理方式旨在爲圖片等靜態內容提供更爲出色的訪問速度表現。舉例來說，Akamai（網絡存取加速服務）會在Akamai邊緣處對全部頁面進行緩存處理。
調用第三方服務供應商的解決方案。另一類常見情況是，由瀏覽器生成的調用會直接指向第三方服務供應商，因此根本不會觸及到相應Web服務器。此類實例包括嵌入式社交媒體插件以及用於提供位置信息的谷歌地圖工具。
單頁面應用程序。這是一類新近興起的異步式交互機制，其中整套應用程序都被容納在單一頁面內部、而且其使用體驗與桌面應用非常相似。該頁面的加載過程由一系列異步式調用組成，而且完全由用戶的操作實現觸發。此類解決方案徹底擺脫了根據所需內容向服務器發送單一調用的傳統機制，從而顯著提高了性能表現並降低網絡負載。Gmail就是此類方案中的傑出代表。
儘管優勢明顯，但Web 2.0卻也給APM領域帶來了不少挑戰。在Web 2.0誕生之前，大家只需要對HTTP頁面請求及其相關響應加以監控即可輕鬆追蹤用戶活動。在那個時候，Web服務器會將返回內容以完整頁面的形式響應到用戶瀏覽器當中。有鑑於此，監控機制只需要關注高級頁面中的獨立請求，也就是說整體與單一請求性能表現都可在HTTP請求層面實現監控。由於所有請求都會被髮回到Web服務器，我們只需通過Web服務器層中的代理機制或者對通過線纜傳輸的數據包進行採樣即可有效完成監控任務。這也是APM解決方案早期曾經採用過的常見處理方式。
在Web 2.0時代，各類瀏覽器都擁有了在單一網頁內部執行嵌入代碼的能力，這就消除了代碼執行需要調用後端應用程序服務器的必要需求。JavaScript是目前在此類應用領域中普及程度最高的語言選項，憑藉着自身在速度、效率以及降低網絡負載方面的優勢（通過運行在終端用戶本地硬件之上實現）、它甚至在全部主流編程語言中也保持着旺盛的人氣。JavaScript的適用範圍極廣，其中包括處理頁面動畫元素、播放音頻與視頻以及驗證Web輸入數據等等。
AJAX（即異步式JavaScript與XML）編程趨勢的普及則進一步拓展了瀏覽器在處理異步式請求方面的能力，進而使其能夠僅對頁面中的特定部分加以更新、而不再需要重新加載整套頁面。舉例來說，用戶在處理結賬頁面以及運費請求時，他或者她完全可以在與專家溝通後直接查看價格變化而無需重新載入整套頁面。
AJAX與JavaScript強大無比，但也給利用傳統方法監控Web應用的管理人員帶來了一系列挑戰。
下面來看其中一些與上述方法相關的主要盲點，包括：代碼級分析缺乏，傳統角度講APM解決方案專注於通過在數據中心服務器內安裝代理機制以實現對代碼執行情況的監控。但現在這類方案只能反響一部分實際情況。
在現代Web應用程序當中，約有八成的代碼執行在瀏覽器內部完成。應用程序服務器內的字節碼也存在類似的情況，換言之，必須將測試工具轉向瀏覽器端纔能有效監控JavaScript執行與錯誤狀態。
不正確的頁面響應時間。時至今日，單純監控網絡流量本身已經無法準確衡量頁面的實際響應時間。利用這種方式，只有每一個獨立對象（或者點擊）所引發的HTTP請求與響應纔會返回到Web服務器（或者原點）處、並接受時間檢查。然而在Web 2.0時代，很多請求根本不會返回到原點，而更多地被路由至CDN或者利用緩存技術被填充在其它環境當中。
我們同樣無法利用網絡採樣方式處理指向第三方Web服務（例如谷歌地圖工具）的調用操作。爲了對廣告、地圖、購物車、網絡分析、社交媒體模塊、CDN與DNS響應時間等進行全面調查，必須通過身處瀏覽器內部的監控方案對頁面載入時間加以審查纔有可能實現。
背景信息不足
在理想條件下，網絡流量監控能夠將後端調用與將其發出的頁面關聯起來。對於傳統應用程序而言，由此帶來的背景信息已經足以用於進行故障排查，但在AJAX領域卻無法順利起效。在AJAX環境下，單一頁面發出的調用可能成百上千。而更具挑戰的是，大量JavaScript事件（例如鼠標點擊菜單選項）根本不會創建出指向Web服務器的調用，這就讓此類純瀏覽器事件消失在了網絡採樣方案與Web服務器監控機制的視野當中。
隨着網站自身對於動態內容及第三方服務依賴性的持續提升，終端用戶的實際使用體驗往往只能依靠瀏覽器自身加以衡量。
四種方式讓你的APM戰略步入現代化軌道
隨着一系列新興技術成果的出現，Web 2.0在帶來挑戰的同時也蘊藏着巨大機遇。儘管傳統方法已經不能單憑自身力量完成任務，但將令人振奮的新興檢測技術作爲補充、進而與原有方案相結合則能夠提供遠超以往水平的洞察能力。下面我們就來介紹四種足以應對Web 2.0新時期下新型難題的APM戰略升級思路。
1. 捕捉功能性問題並建立背景信息
在處理面向外部的應用程序時，性能表現並不是惟一需要關注的重點。應用程序的功能性問題在出現頻率上要遠高於性能問題，這同時也是導致用戶放棄甚至轉而使用其它站點的首要原因。由於Web應用程序通常扮演着企業與其客戶進行交互的惟一渠道，因此故障排查人員往往不太可能親自與用戶進行溝通以瞭解到底是哪些環節出了問題。
試想一下，假設由於應用程序的設計存在缺陷、其在處理開頭爲零的郵政編碼信息時出現了錯誤。
在這種情況下，採用能夠捕捉瀏覽器事件的解決方案，例如鼠標點擊以及鍵盤輸入數據，顯然能夠重現用戶的會話活動、從而幫助我們主動識別並解決這些問題。
2. 捕捉JavaScript錯誤並對其進行故障排查
考慮這樣的場景，如果某家企業希望推出一項全新AJAX功能以實現網上下單操作、但卻不斷返回JavaScript錯誤，結果會怎樣。這一切在Web日誌當中可能根本沒有體現，而且所有響應時間看起來都極爲正常。結果呢，故障排查人員甚至根本感受不到問題的存在——直到客戶們的抱怨之聲鋪天蓋地而來。在這種情況下，糊塗不再是福、而意味着潛在營收的大量外流。
我們的APM解決方案應該能夠檢測JavaScript錯誤並就此發出警告，從而敦促技術人員儘快着手加以處理。
3.關注來自頁面加載時間的細節信息
爲了將廣告、地圖、購物車、網絡分析、社交媒體模塊、CDN與DNS響應時間等因素確切納入監控範疇，我們必須在瀏覽器內部對頁面加載時間進行高度關注。幸運的是，現在新一代IE、火狐以及Chrome瀏覽器都已經提供HTML 5導航定時功能。它能夠將完整的頁面加載時長拆分成DNS查找、重新定向、SSL握手、處理以及緩存訪問時長等具體項目。務必選擇一套具備此類功能的APM解決方案。
4. 將問題隔離在特定頁面元素當中
目前瀏覽器所能捕捉的信息還僅限於完整頁面加載內容，也就是說無法針對個別頁面提供定時信息，例如載入圖像或者圖片、CSS樣式表、指向Web服務器或者REST API的後端調用所用去的時間。具備網頁分析功能的網絡採樣工具則可以爲指向單獨頁面對象的HTTP請求與響應計時，從而幫助故障排查人員將問題固定在特定頁面元素身上。在選擇網絡監控解決方案時，請大家務必確保自己採購的產品具備這項功能。
APM對Web 2.0應用程序實施監控原理
好的APM產品要以客戶爲中心、且能夠與APM相協作的解決方案，能夠在數據之外爲IT以及業務部門帶來更爲確切的答案。除此之外，大家可以選擇將其與數據庫、虛擬化或者網絡性能監控機制結合起來，從而進一步發揮APM在整體企業監控戰略當中的全能實力。
結合傳統與現代解決方案中的諸多優勢要素，APM產品應該具備如下卓越特性：
能夠捕捉每位用戶的每一次點擊並重現Web用戶的實際活動，從而真正複製用戶使用體驗、從而實現背景信息取證並完成故障排查。
利用強大的應用程序運行時架構自動發現機制將我們的應用程序與基礎設施關聯性加以映射。
確保精確的問題區域識別、詳盡的響應時間分解以及完整的傳輸路徑可視化呈現——從應用程序層到終端用戶，整個流程盡在掌握。
將所有用戶以及追溯信息容納在一套以“事務”爲核心的通用型框架當中——從而保證數據與工作流程以無縫化方式進行協作，並提供獨一無二的可視化顯示效果。
彌合虛擬化與共享資源衝突給Web應用程序帶來的影響，保證數據與關係在所有事務維度中的和諧統一——從瀏覽器到數據庫、從代碼層到虛擬機管理程序。
利用細緻的根本原因分析機制，在Java與.NET應用程序服務器內部揪出代碼層瓶頸。
追蹤每項請求的調用堆棧並捕捉相關支持證據，包括內存（堆）統計、方法參數以及SQL綁定變量等。
利用豐富的監控數據與高可擴展性分析機制提供開箱即用的分析與可視化處理方案。
總結
以JavaScript與AJAX爲代表的Web 2.0技術體系爲Web應用程序帶來了優勢顯著的處理速度提升，同時也讓性能表現與執行效率邁上新的臺階。希望APM產品能夠爲開發者給予幫助。