报告 › 分析 › 多层应用程序的性能 › 分析多层应用程序的性能

分析多层应用程序的性能

使用管理控制台可以按照分析单层应用程序的相同方式来分析多层应用程序，但有两点不同：

• 低层应用程序的性能通常取决于高层应用程序的性能。
• 在报告每个层时，将上面的层设置为网络，将下面的层设置为服务器和应用程序。

在前一部分的示例中，第 2 层 HTTP Web 应用程序的性能是第 3 层 Oracle 数据库服务器性能的函数。 由此得出，第 N 层 HTTP Web 服务器在报告中显示为客户端，而第 N+1 层主机显示为服务器/应用程序。

在分析 N 层应用程序时，从最高层（距离最终用户最远的层）开始并向用户的方向前进。 请注意相关层上的相关性能点的影响。 各层之间的公共相关性能遵循可能的发生次序。

1. 第 N+1 层的服务器响应时间 (SRT) 会影响第 N 层的 SRT。
   • SRT 是服务器资源使用率的函数。 该值较高表示，服务器可能没有足够的内存、CPU 或磁盘 I/O 资源来为给定负载的应用程序提供服务。
   • 查看会话和 QoS 视图，以确定哪些会话或用户在慢速 SRT 的实例期间对服务器施加了过多负载。
2. 第 N 层和第 N+1 层之间的网络往复传输时间 (NRTT) 很高，并且会影响数据吞吐量。
   • LAN 环境中的 NRTT 是交换机背板速度和交换机之间共享上行链路上带宽争用的函数。 最佳实践是始终将 N 层应用程序的主 NIC 放在同一交换机上并在同一 VLAN 之内，以消除上行链路带宽争用问题，并取消服务器之间的两个额外的交换机跃点。 这可以显著提高 N 层应用程序的性能。
   • 查看“通信量”和“数据量”视图，以确定 NRTT 是否随着数据量的增加而增加。 如果是这样，则可能是两个服务器之间没有足够带宽用于应用程序。
3. 第 N 层和第 N+1 层之间的数据传输时间 (DTT) 恰好为零或趋向于零。 查看“响应大小”和“数据传输时间(按响应大小)”视图，了解应用程序是否使用了大于 1.45  KB（适合一个数据包的数据量）的各种响应大小。 DTT 为零或接近于零通常表示，后端办公室服务器正为每个用户请求发送单个数据包。 对于数据库服务器，通常的形式是一次查询请求一行数据并执行多次，而不是在单次查询中请求所有行。 可以重写查询以优化性能。
4. 第 N 层和第 N+1 层之间的重传时间表示显著的数据包丢失。
   • 查看“通信量”和“数据量”视图，以确定在高重传期间是否正在传输大量数据。
   • 查看“会话”和“网络连接时间”视图，以确定 TCP 会话启动经历的延迟量。 值较高表示这两层之间存在拥塞。

下图说明了应用程序体系结构中的第 2 层和第 3 层之间的“服务器响应时间”依存关系。 在高响应时间期间，第 2 层服务器的 SRT 在第 3 层服务器的 SRT 之后。

这两层之间的尾部数据点表示第 3 层服务器性能会影响第  2 层服务器性能。 第 3 层服务器是此应用程序体系结构中的瓶颈。

当第 N 层应用程序延迟与第 N+1 层应用程序延迟在高峰延迟期间具有相同的常规曲线时，第 N+1 层应用程序很可能对第 N 层应用程序产生了不利影响。

找出 N+1 层应用程序中的性能瓶颈（高 SRT 表示服务器存在问题；高 NRTT 和重传次数表示网络存在问题；以及 SRT 和 NRTT 偏低时零次或很多次数据传输通常表示应用程序存在问题）并更正相关问题后，请重复分析过程以找出其他次要瓶颈。