工具箱和方法论    
   
    高效的性能管理包含两个同等重要的组成部分。首先是方法论——定义为确保系统运行于最佳状态下所必须执行的任务的过程。第二个组件是工具箱——对工具的选择，通过收集性能相关的信息用来执行这些方法。当决定应用性能管理（APM）解决方案时，关键是确保所选择的工具能够作为有效且经过验证过的方法的一部分。    
   
  实际的交易    
   
  一些性能管理解决方案依赖于模拟交易的性能评价（计算机产生的用于测试应用程序性能的周期性处理过程）的性能测试。尽管这种方式能够有效的考察系统开销，但是模拟交易无法精确的洞悉真正最终用户的操作体验或者真正的事物处理的性能。模拟交易无法检测意料之外的性能问题。当决定APM解决方案时，关键之处在于确保解决方案能够对真实系统的交易性能提供24×7的评价。    
   
  对生产环境的友好性    
   
  对于实际交易性能指标连续收集的需求往往转化为对于“生产环境友好”的解决方案的需求。该方案对被监控系统造成的开销最少。在大多数情况下，使用追踪技术获取信息的方法（典型的情况是，依赖通用API函数获取系统中所有活动的全部信息）伴随着难以承受的系统开销。避免这种问题的最有效的方法之一是使用高频率、低开销的采样技术。它提供的性能测量结果具备统计学上的精确性和细粒程度，而同时将相关的系统开销保持在较低的水平。当确定APM解决方案时，保证它自身不会对系统性能起到负面作用是颇为必要的。    
   
  即时可用工具(out-of-the-box   instrument)    
   
  在大多数情况下，出于监控性能目的修改系统代码是不可能的，或者至少是不现实的。做出必要的改动并进行维护的成本很高，而且也缺乏通用的工具标准，即使这些信息大有用处，仍然使得试图采用这种方法的企业望而却步。反之，在大多数情况下，企业更倾向于使用针对已有应用的即时可用工具（out-of-the-box   Instrument），这通常是一种运行于内存中的程序。当决定APM解决方案时，很重要的一点是确保无需对现有的应用做出大量改动或进行复杂的定制。    
   
  相互关联的信息    
   
  在监控复杂、多层架构应用的性能时，应用程序的数据将变得孤立（独立地呈现各层的信息）。在一些情况下，甚至层内信息也会变得孤立；例如当用户、操作系统以及应用的统计数据间没有联系的时候。当试图解决运行问题时，使层内以及层间的活动关联起来是很重要的，这样才能将故障现象与导致问题的起因联系在一起。由于层到层的处理性质的变化，与层间关联性能相关的复杂性在迅速增加。Web请求将转变为多重SQL请求（SQL是一种标准查询语言，它是在关系数据库中定义数据获取或修改查询的最通用的方式）。多重SQL请求可能转变为更多的针对存储系统的I/O请求。在某些情况下，通过使用各层间的通同标识符可以将数据关联起来；然而，在大多数情况下，需要更加一般性的关联方法。运行一个统计行为分析工具并标识出重现模式是关联层间活动的一种方法。通常情况下，这种方法可用于提供一个关于应用性能的历史视图。当决定APM解决方案时，确保应用的层内及层间的信息相互关联是非常重要的。    
   
  数据一致性    
   
  如果各种产品之间的信息不一致，利用多种工具进行性能管理将是一件非常棘手的事。报警所依赖的信息、应用所报告的信息以及分析工具所提供的信息应该保持一致性，这点非常重要。此外，如果通过关联环境启动了in-depth分析软件，各种产品能够自动完成从症状到原因的分析过程，则可以节省弥足珍贵的时间。当选择工具箱实现APM方案时，确保各种产品之间的信息一致性是至关重要的。    
   
  主动管理    
   
  处理性能问题通常导致很长的恢复时间和高昂的企业成本。有效的APM解决方案必须支持主动性能管理，必须能够在性能问题（事实上的或者潜在的）的发展初期及早识别出来并向员工发出警报信号。    
   
  分析能力    
   
  APM解决方案收集的信息必须同样支持更具预防性的分析过程。它必须有助于识别性能的负面趋势、相对于基准线的偏离、主要的调整点并能够协助性能规划。