性能监视系统的所有层

对此的标准应该是应用程序响应度量（ARM）。这是一组跨语言的API，可以满足您的需求。问题在于，实施此规范的产品往往都是大型，昂贵的“企业”级监控工具。考虑数周的安装，顾问，更多的基础设施和大量流行语。 但是，如果这是一个具有关键任务预算的关键任务应用程序，则可能是您所需要的。但是您可以构建自己的功能，而无需花费太多精力。如果您仍想使用该API，则可以进行快速搜索找到至少一个开源ARM实现。 另一种选择是简单地让您可以针对系统的每一层运行事务，以检查常规响应能力。例如，您可以在LB上有一个静态网页，在应用程序服务器上有一个无操作tx，在Java应用程序上有一个“ hello \” servlet，直接在队列中放置一条消息，等等。测试时，这些负载可能直接被负载测试工具击中，或者您可以编写一个包装servlet /应用程序调用，将其作为单个HTTP（RMI？）调用进行。每分钟运行几次不会给系统增加太多负载，但是它应该可以帮助您确定哪个层速度较慢。这种方法的好处是它也可以在生产环境中工作，只是要注意安全问题。 对于单用户类型的测试，在您知道自己有问题的情况下（例如，此tx是“慢”），我对网络跟踪也很幸运。这非常繁琐，但是当您不确定什么层速度较慢时，在几台计算机上启动网络跟踪并运行单个tx通常可以很好地了解系统的运行状况。     

过去，我已经以多种方式处理了这种分解。第一种方法是使用协议分析器转储的数据以非常低的级别查找会话离开X层并进入Y层的时间点。第二种方法是通过对各个层使用日志检查。在这种情况下，可以使您的检查变得非常有用的是所有组件（syslog，Rsyslog等...）的通用日志服务器以及不错的日志解析工具，例如免费提供的Microsoft Logparser。对存储在数据库中的应用程序使用审核跟踪的第三种方法。在使用具有消费者/生产者模型和用于传递信息而不是直接连接的总线的企业服务总线样式应用程序时，您可能会发现这一点。我所看到的审计跟踪通常存储在数据库中，并允许在整个应用程序基础结构中跟踪单个事务。您的负载均衡器，作为网络设备，可能在这一方面难以捉摸。 请注意，如果您使用协议分析器或日志路由，请确保将所有源信息设备同步到公用时间服务器。当您进入分析阶段时，以时间戳为基础关闭您的一个收集器（分析器，应用程序日志）确实是一件令人毛骨悚然的体验。 至于如何从收集的数据转移到LoadRunner，该部分非常机械。分析程序支持导入外部数据点的接口。该格式非常具体，在帮助和在线文档中都有记录。此导入过程非常有效，因为我经常不得不使用它来从我没有直接监视访问权限的主机收集统计信息，但这些主机必须包含在受监视的测试基础结构中。 詹姆斯·普利 主持人（YahooGroups LoadRunner，Advanced-Loadrunner； GoogleGroups lr-LoadRunner； Linkedin LoadRunner，LoadRunnerByTheHour； SQAForums LoadRunner，WinRunner）