监控系统所有层的性能
我使用多种负载测试工具（Loadrunner、JMeter、NeoLoad）来测试不同应用程序的性能。我想知道是否可以监视应用程序堆栈的所有层，例如。假设我有以下数据链。
负载均衡器<-x->应用服务器<-x-> RMI<-x-> Java 应用程序<-x-> MQ<-x->旧应用程序<-x->数据库
我在链中标记了我有兴趣监视的x，例如平均响应时间。
显然，我们可以简单地在所有端点上创建一个包装器，为我们收集统计数据，也许我们可以将其导入到 loadrunner 或其他负载测试工具中，并使用工具内置的性能统计数据进行边线处理，但也许有些工具/应用程序已经做到了这一点？
如果没有，我们应该如何进行才能收集此类统计数据？
I use several loadtesting tools (Loadrunner, JMeter, NeoLoad) to performance test different applications. Im wondering if it is possible to monitor all layers of an application stack so for example. Say i have the following data chain.
Loadbalancer <-x-> Application Server <-x-> RMI <-x-> Java Application <-x-> MQ <-x-> Legacy application <-x-> Database
Where i have marked the x in the chain i am interested in monitoring, for example avg responsetimes.
Obviously we could simply create a wrapper on all endpoints which would gather the statistics for us and maybe we could import it into loadrunner or other loadtesting tools and sideline hem with the tools inbuilt performance statistics, but maybe there is tools/applications which already does this?
If not, how should we proceed, in order to gather this kind of statistics?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
其标准应该是应用程序响应测量 (ARM)。它是一组跨语言的 API，可以满足您的需求。问题在于，实现此规范的产品往往都是大型且昂贵的“企业”级监控工具。想想多周的安装、顾问、更多的基础设施和大量的流行语。
不过，如果这是一个具有关键任务预算的关键任务应用程序，那么这可能就是您所需要的。但您也许可以构建自己的，无需太多努力即可完成足够的工作。如果您仍想使用该 API，快速搜索至少会找到一个开源 ARM 实现。
另一种选择是简单地让您可以针对系统的每一层运行事务来检查总体响应能力。例如，您可以在 LB 上有一个静态网页、在应用程序服务器上有一个无操作 tx、在 Java 应用程序上有一个“hello”servlet、直接将消息放入队列等。在性能/负载测试期间，这些可以由负载测试工具直接命中，或者您可以编写一个包装器 servlet/应用程序调用，将其作为单个 HTTP（RMI？）调用来执行。每分钟运行几次不会给系统增加太多负载，但它应该可以帮助您确定哪一层速度较慢。这种方法的好处是它也适用于生产环境，只需注意安全问题即可。
对于单用户类型的测试，你知道你有问题（例如，这个交易“慢”），我在网络跟踪方面也有很好的运气。这非常乏味，但是当您不确定哪一层速度慢时，在几台机器上启动网络跟踪并运行单个 tx 通常可以很好地了解系统正在做什么。
The standard for this was supposed to be Application Response Measurement (ARM). It was a cross language set of APIs that did just what you were looking for. The issue is that the products that implement this spec all tend to be big, expensive "enterprise" level monitoring tools. Think multi-week installs, consultants, more infrastructure and lots of buzzwords.
Still, if this is a mission critical app with a mission critical budget, this may be what you need. But you may be able to build your own that does just enough without too much effort. A quick search turns up at least one open source ARM implementation if you still want to use that API.
Another option is to simply to have transactions you can run against each tier of the system to check general responsiveness. For example you can have a static web page on the LB, a no-op tx on the app server, a "hello" servlet on the Java app, put a message directly on the queue, etc. During a performance / load test, these could be hit directly by the load testing tool or you could write a wrapper servlet / application call that does this as a single HTTP (RMI?) call. Running these a few times a minute won't add too much load to the system, but it should help you pinpoint which tier is slower. The nice thing about this approach is that it also works in production, just watch out for security issues.
For single user kind of test, where you know you have problem (e.g. this tx is "slow"), I have also had pretty good luck with network tracing. It's very tedious, but when you aren't sure what tier is slow, starting up a network trace on a few machines and running a single tx usually gives a good idea of what the system is doing.
我过去曾通过多种方式处理过这种分解。第一种方法是在非常低的级别上使用协议分析器转储的数据来查找对话离开第 X 层并进入第 Y 层的时间点。第二种方法是通过使用各个层的日志检查。在这种情况下，可以让您的检查非常有用的是所有组件（syslog、Rsyslog 等）的通用日志服务器和一个不错的日志解析工具，例如免费提供的 Microsoft Logparser。第三种方法利用存储在数据库中的应用程序的审计跟踪。在处理企业服务总线样式应用程序时，您可能会发现这一点，这些应用程序具有消费者/生产者模型和用于传递信息而不是直接连接的总线。我看到的审计跟踪通常存储在数据库中，并允许通过整个应用程序基础设施跟踪单个事务。您的负载均衡器作为一种网络设备，可能无法解决这个问题。
请注意，如果您使用协议分析器或日志路由，请确保将所有源信息设备同步到公共时间服务器。当您进入分析阶段时，根据时间戳关闭其中一个收集器（分析器、应用程序日志）确实是一种令人烦恼的体验。
至于如何从收集的数据转移到 LoadRunner，这部分非常机械。分析程序支持导入外部数据点的接口。该格式非常具体，并且在帮助和在线文档中都有记录。这个导入过程非常有效，因为我经常必须使用它来从主机收集统计信息，我没有直接监视访问权限，但需要将其作为受监视的测试基础设施的一部分包含在内。
James Pulley
版主（YahooGroups LoadRunner、Advanced-Loadrunner；GoogleGroups lr-LoadRunner；Linkedin LoadRunner、LoadRunnerByTheHour；SQAForums LoadRunner、WinRunner）
I have handled this decomposition a number of ways in the past. The first is at a very low level using protocol analyzer dumped data to find the time points where a conversation leaves tier X and enters tier Y. The second method is through the use of log examination for the various tiers. Something that can make your examination quite usefule in this case is a common log server for all of your components (syslog, Rsyslog, etc....) and a nice log parsing tool, such as the freely available Microsoft Logparser. The third method utilization of the audit trail for an application stored in the database. You may find this when working on enterprise services bus style applications which have a consumer/producer model and a bus to pass information rather than a direct connection. The audit trails I have seen are typically stored in a database and allow the tracking of an individual transaction through the entire application infrastructure. Your Load balancer, as a network device, may be out of the hunt on this one.
Note, if you go the protocol analyzer or log route, then be sure and synchronize all of your source information devices to a common time server. Having one of your collectors (analyzer, app log) off on a time stamp basis can really be a hair pulling experience when you get into the analysis phase.
As to how you move from your collected data into LoadRunner, that part is very mechanical. The Analysis program supports an interface to import external datapoints. The format is very specific and is documented in both help and the online docs. This import process works very well, as I often have to use it for collection of statistics from hosts which I do not have direct monitoring access to, but which need to be included as a part of the monitored test infrastructure.
James Pulley
Moderator (YahooGroups LoadRunner, Advanced-Loadrunner; GoogleGroups lr-LoadRunner; Linkedin LoadRunner, LoadRunnerByTheHour; SQAForums LoadRunner, WinRunner)