2.9 确定服务器和网络的关键性能指标
您需要确定应用程序中关键的服务器和网络性能指标哪些是需要监控的,这一信息对于在性能测试中任何可能出现的问题的精确定位是至关重要的。最理想的情况是把这些监控集成到您的自动化性能测试解决方案中去。然而,缺乏这种集成也不应成为不解决这一重要需求的理由。
您的目标是要建立可用于服务器每个应用层的一套监控模式或模板,这些模式的结构将取决于创建和部署应用程序的技术。
2.9.1 服务器关键性能指标
服务器的性能是通过一些软件配置对指定的性能指标和计数器实现监控的。该软件可以包含或集成到您的自动化性能测试工具中,也可能是一个独立的产品。
·模拟负载(负载系数)
也许您已经熟悉了Perfmon(性能监视器)这个Windows自带的工具。如果是这样的话,那么您一定知道在特定的服务器上有数百种性能计数器可以监控。从这么庞大的计数器中,有十几个可以看出很多关于(Windows)服务器性能问题的核心指标。
在UNIX/Linux环境下,有一些监控命令,像top、vmstat、iostat和SAR,可以提供同样的信息。同样,大型主机也有自带的监控工具,可以作为性能测试设计的一部分。
服务器关键指标的监控方法最重要的是使用一个合理的方式,理想的情况是,使用多层监控。最上层称为一般监控,重点是建立一组少量的计数器,它们将很快告诉您服务器(Windows或UNIX)是否处于压力之下。第二层的监控应侧重于应用层的具体的技术:Web、应用程序以及数据库服务器。
技巧
最理想的做法是为每一层监控建立单独的性能指标模板。一旦建立后,这些模板可以形成未来的性能测试可重用的资源。
最后一层包括应用服务器(如果有的话)和将注意力从计数器转移到组件和方法级的性能。从本质上讲,这是从应用程序服务器内部的技术角度分析通过一般监控中发现的性能问题的原因。为每个应用技术都提供一份推荐使用的指标显然是不切实际的,因此,您应该参考相应的技术厂商所提供的文档决定监控什么指标,为了在这一过程中帮助您,许多性能测试工具都提供了针对流行应用技术的推荐的计数器模板。
总而言之,根据不同的应用架构,可能使用以下模式或模板中的任一种或者全部。
通用模板
这是一套通用的指标,将适用于相同的操作系统下,在同一个应用层的每个服务器。其目的是提供对负载和压力影响的第一层监控。典型的指标将包括监控CPU的繁忙程度和可用内存数量。附录D包含了通用模板和其他模板的例子。如果应用程序很复杂,那么您可能要有多个版本。
根据我的经验,一个通用模板进行监控的Windows服务器操作系统应至少包括以下计数器(其中包括关键的CPU、内存、磁盘I/O,以及一些常见的网络方面的错误):
·Processor utilization percentage
·Top 10 processes
·Available memory in bytes
·Memory pages/second
·Processor queue length
·Context switches per second
·Physical disk:average disk queue length
·Physical disk:%Disk Time
·Network interface:Packets Received Errors
·Network interface:Packets Outbound Errors
Web和应用服务层
这些模板关注某些特定的应用服务器技术,该技术可能会涉及不同于微软Perfmon工具提供的性能计数器。相反,这种模式利用监控技术研究特定的应用服务器的性能,如Oracle、WebLogic,或者IBM的WebSphere。这项技术使分析性能不佳或配置组件细化到底层的方法一级。例如:
·IIS(Microsoft Internet Information Server)
·Oracle application server(OC4J)
·Oracle WebLogic(JRockit)
·IBM WebSphere
JBOSS
数据库服务器层
一些厂商所提供的企业级的数据库技术,其架构和原理大同小异,但从监控的角度看,差异却很大。因此,每种数据库都需要自己独特的一套模板。最常见的有:
·Microsoft SQL Server
·Oracle
·IBM DB2
·MySQL
·Sybase
·Informix
主机层
如果在您的应用程序部署有一个主机层,您需要把它列入性能监控之中,以此实现真正的端到端的覆盖。主机监控往往侧重于一小部分基于每个Job和逻辑分区(LPAR)的内存和CPU利用率的指标。一些工具厂商可以将主机性能数据纳入到性能测试解决方案。主机的性能监控工具往往相当专业。常见的一些商业案例如下:
·Compuware公司的Strobe
·IBM的Candle