在云上成功采用应用性能管理(APM)涉及几个关键的步骤：
设置资源边界，限制性能变量;
对云情况应用监控实践;
在直接资源不能解决体验质量(QoE)问题时，部署补偿措施。
首先介绍一下定义：APM是一种监控流程，通过应用业务用例，调整应用资源满足具体体验质量标准集。技术上，QoE是应用执行时间和网络交付时间的综合，而且这些在云端都可以实现多样化。
处理云性能变量
实际上，云计算最明显的真相之一就是：当潜在云资源池巨大且位于不同的地理位置时，不同位置的资源池之间，网络响应时间必然有所区别。远一点的托管点通常要用更多的路由跳数到达，会导致更多的延迟，但是你的用户和云托管点之间的精准跳数数量，在潜在云网络提供商之间可能会存在明显差异。
简单测试为例，用路由跟踪诊断工具可以从每一个主要的员工位置到云端不同的点，建立连接性能，有助于用最佳性能识别网络提供商。
监控性能 衡量响应时间
一旦你做了所有能够控制与应用托管点云分布相关的应用性能变量的事情之后，下一步就是为云重构应用监
控实践和工具。
通常，APM开始从用户层面衡量响应时间，随后穿过连接和功能连续层“回退到应用”。APM工具可以应用在用户服务点，也可以应用在内部应用/组件本身，为数据中心所使用的云应用部署相同的工具和实践成为可能。
对于云APM唯一的要求就是：期望工具能够同必须成为部署软件镜像一部分的应用/组件共存，这样意味着必须兼容云服务硬件和软件平台。
一些APM用户会部署网络探头或者其他的网络管理工具，在关键点检测应用包，隔离延迟资源并识别出问题，一些显然不能在公共云中做的事情。唯一现实的监控策略就是检测包只能在网络边界点，意味着这个连接点连接到用户以及应用的组件。很可能APM工具已经监控用户边界，因此可能需要的就是整合网络监控和应用镜像，以便工具和应用能够部署到云端，且能够访问。
云服务涉及到数个运营商提供的连接点，边界点监控很难实现，除非一个或者两个运营商在连接时都提供一个监控探头式样。还可能通过跟踪路由发现问题，但是仅仅在运营商暴露了自己的基础架构来控制所用协议时才可以。如果不是的话，后面的故障隔离和特定网络补救(通过服务水平协议)就会很难。
隔离问题源的目标就是为了修复具体问题导致的性能问题——重选路由连接、改变托管地点等等。当由于缺少资源控制，不能够隔离问题或者作出所需的改变，需要采取补偿性能增强措施改善云APM。
加速云应用性能
有效APM技术分成两个主要的群组：网络加速和针对负载共享的组件复制。在IT人员可能犯的错误中最大的一个就是认为前者可以用于网络问题，后者用于计算问题。任何改善性能的都可以用于补偿增强性能上，不管是否基于性能问题，因为目标就是为了补救问题。
网络性能增强通常涉及数据压缩、多路径传输和流量优先次序的结合。大约一半企业在其应用中应用某种形式的网络性能，因此他们自然期望能够将相同的工具迁移到云端APM来使用。
问题在于技术需要一对设备，一个在每一个网络路径的两端，但是不可能在云端安置应用的另一端。希望网络性能工具可以操作服务器端软件，而不是一个设备。但是要确保软件同云的硬件和软件兼容，因为必须为部署整合机器镜像。
应用组件复制提供了额外的并行处理容量，能够改善负载下的性能，但是这种机制只有在应用负载导致的性能问题时才能在云端应用。如果你对这种情况表示怀疑，最好的选择就是更高性能的服务器或者专用服务器。
然而，如果服务器性能不能解决问题，而且的确和负载相关，那就考虑复制。为了实现复制工作，应用必须设计成能够运行一套并行实例那样，通过负载均衡器分配工作。为了在云端应用，负载均衡器可能必须是云托管的软件组件。
大多数云性能问题可以通过调谐云和网络连接解决，遵从用于私有数据中心应用托管的相同通用程序。风险在于这个程序需要在边界之中保持QoE，会导致特定服务额外的云托管费用，可能危害运业务案例。
