在云上成功采用應用性能管理(APM)涉及幾個關鍵的步驟：

設置資源邊界，限制性能變量;

對云情況應用監控實踐;

在直接資源不能解決體驗質量(QoE)問題時，部署補償措施。

首先介紹一下定義：APM是一種監控流程，通過應用業務用例，調整應用資源滿足具體體驗質量標準集。技術上，QoE是應用執行時間和網絡交付時間的綜合，而且這些在云端都可以實現多樣化。

處理云性能變量

實際上，云計算最明顯的真相之一就是：當潛在云資源池巨大且位于不同的地理位置時，不同位置的資源池之間，網絡響應時間必然有所區別。遠一點的托管點通常要用更多的路由跳數到達，會導致更多的延遲，但是你的用戶和云托管點之間的精準跳數數量，在潛在云網絡提供商之間可能會存在明顯差異。

簡單測試為例，用路由跟蹤診斷工具可以從每一個主要的員工位置到云端不同的點，建立連接性能，有助于用最佳性能識別網絡提供商。

監控性能 衡量響應時間

一旦你做了所有能夠控制與應用托管點云分布相關的應用性能變量的事情之后，下一步就是為云重構應用監

控實踐和工具。

通常，APM開始從用戶層面衡量響應時間，隨后穿過連接和功能連續層“回退到應用”。APM工具可以應用在用戶服務點，也可以應用在內部應用/組件本身，為數據中心所使用的云應用部署相同的工具和實踐成為可能。

對于云APM唯一的要求就是：期望工具能夠同必須成為部署軟件鏡像一部分的應用/組件共存，這樣意味著必須兼容云服務硬件和軟件平臺。

一些APM用戶會部署網絡探頭或者其他的網絡管理工具，在關鍵點檢測應用包，隔離延遲資源并識別出問題，一些顯然不能在公共云中做的事情。唯一現實的監控策略就是檢測包只能在網絡邊界點，意味著這個連接點連接到用戶以及應用的組件。很可能APM工具已經監控用戶邊界，因此可能需要的就是整合網絡監控和應用鏡像，以便工具和應用能夠部署到云端，且能夠訪問。

云服務涉及到數個運營商提供的連接點，邊界點監控很難實現，除非一個或者兩個運營商在連接時都提供一個監控探頭式樣。還可能通過跟蹤路由發現問題，但是僅僅在運營商暴露了自己的基礎架構來控制所用協議時才可以。如果不是的話，后面的故障隔離和特定網絡補救(通過服務水平協議)就會很難。

隔離問題源的目標就是為了修復具體問題導致的性能問題——重選路由連接、改變托管地點等等。當由于缺少資源控制，不能夠隔離問題或者作出所需的改變，需要采取補償性能增強措施改善云APM。

加速云應用性能

有效APM技術分成兩個主要的群組：網絡加速和針對負載共享的組件復制。在IT人員可能犯的錯誤中最大的一個就是認為前者可以用于網絡問題，后者用于計算問題。任何改善性能的都可以用于補償增強性能上，不管是否基于性能問題，因為目標就是為了補救問題。

網絡性能增強通常涉及數據壓縮、多路徑傳輸和流量優先次序的結合。大約一半企業在其應用中應用某種形式的網絡性能，因此他們自然期望能夠將相同的工具遷移到云端APM來使用。

問題在于技術需要一對設備，一個在每一個網絡路徑的兩端，但是不可能在云端安置應用的另一端。希望網絡性能工具可以操作服務器端軟件，而不是一個設備。但是要確保軟件同云的硬件和軟件兼容，因為必須為部署整合機器鏡像。

應用組件復制提供了額外的并行處理容量，能夠改善負載下的性能，但是這種機制只有在應用負載導致的性能問題時才能在云端應用。如果你對這種情況表示懷疑，最好的選擇就是更高性能的服務器或者專用服務器。

然而，如果服務器性能不能解決問題，而且的確和負載相關，那就考慮復制。為了實現復制工作，應用必須設計成能夠運行一套并行實例那樣，通過負載均衡器分配工作。為了在云端應用，負載均衡器可能必須是云托管的軟件組件。

大多數云性能問題可以通過調諧云和網絡連接解決，遵從用于私有數據中心應用托管的相同通用程序。風險在于這個程序需要在邊界之中保持QoE，會導致特定服務額外的云托管費用，可能危害運業務案例。