如何将性能问题与应用程序基础结构的特定组件隔离开来？具体来说，结果日志中是否有不同的标记来区分Web，应用程序和/或数据库服务器级别的瓶颈？
我在接受采访时被问到这个问题并且对此一无所知。似乎这些信息无处可用。
答案 0 :(得分：1)
除了SiteScope和其他无代理监视系统组件之外，您还需要确保您的方案和脚本按预期工作。这包括正确的错误检查和事务的使用（以及许多其他事情）。如果事务足够精细，这将使您至少了解出现性能问题的请求。获得这些指标后，请与基础架构团队一起审核日志和其他信息。作为一个迭代过程，可以使测试专注于基础设施中越来越小的部分。
此外，loadrunner脚本不必严格“通过前门”进入。如果您有一个多层系统，可以使用脚本直接访问Web / app /数据库服务器。
要寻找什么，请关注任何具有“膝盖”或“曲棍球棒”行为的测量。您可以直接在控制器中挂接任何服务器资源类型测量，并在分析阶段集成其他团队的统计数据。与较低虚拟用户级别的基准进行比较，以确定可接受和不可接受的内容。
祝你好运！答案 1 :(得分：1)
如果访谈的重点是LoadRunner和SiteScope，我会得出结论，它更关注HP / Mercury解决方案。在这种情况下，我建议您研究一下HP Diagnostics及其LoadRunner集成功能
答案 2 :(得分：0)
通过查看性能测试的标准结果，通常无法获得此类信息。
通过使用SiteScope监控测试中的所有相关服务器，可以找到您要查找的部分信息。 SiteScope提供了许多计数器，例如CPU，内存，磁盘I / O和网络I / O--如每台服务器上所示。
这些信息可能提供了关于瓶颈在哪里的线索，以及您添加到SiteScope的计数器越多，确定瓶颈的变化就越大。
一个非常普遍的误解是AppServer和DBServer瓶颈只能通过查看原始响应时间或命中，页面等（Web协议）来识别，除非访问的URI定义了确切的组件。系统...