用WebSphere监视Web站点的性能 - 技术应用子站 - 赛迪网

用WebSphere监视Web站点的性能
作者：陶刚翻译　来源：赛迪网　发布时间：2003.06.03
【Java专区】 【网络安全】 【网管专区】 【linux专区】 【进入论坛】 【IT博客】

本文译自：www.e-promag.com 　　原文名称《Monitoring Performance with WebSphere》 　　原文作者：Ruth Willenborg原文链接 　　我们听过电子商务站点在沉重的负载下崩溃，花费公司数以亿计美元这种可怕地故事。我们在等待某个Web页面下载时遇到过失败，不得不寻找执行速度更快的站点。 　　Web站点的性能就是业务量。执行效率差的Web站点会引起客户不满，失去赚钱的机会。因为这些原因的存在，使监视Web站点的性能，识别性能故障，快速找到起因并解决问题成为所有Web站点操作中关键的部分。本文将提供使用IBM WebSphere Application Server（WAS）进行Web站点性能监视的综述。 　　监视的尺度 　　成功的性能监视帮助你检测和纠正性能问题。在定义监视方案前，需要考虑下面一些因素： 　　◆ 如果你没有测量性能，就不知道有问题。 　　◆ 如果你不知道在哪儿测量性能，就找不到问题。 　　◆ 如果你不知道怎样找到问题的源，就无法修复问题。 在我们仔细分析性能监视之前，我们简单了解一下三种监视尺度--最终用户视图、系统和应用程序健康、应用程序视图。 　　最终用户视图。对于最终用户来说，你的Web站点是一个黑盒子。他们不知道（或不关心）有多少服务器、服务器在哪儿、服务器的硬件如何或者服务器使用哪种应用程序。用户只关心Web页面的显示速度。监视最终用户视图可以让你知道是否存在公共可视方面的性能问题。如果Web站点太慢，客户将放弃并离开。不应该等待客户抱怨才发现站点有问题。 　　系统和应用程序健康。第二个监视尺度是查看Web站点的内部子系统并检查每个的问题。典型的WAS Web站点有很多子系统，包括Web服务器、应用程序服务器、数据库、目录服务器和防火墙。任何一处都可能成为瓶颈！ 在这个阶段，你试图找到有问题的组件并识别受限制的资源。你可能发现网络带宽、后端连接、数据库的CPU或其它组件，它们中的任何一个都可能是资源的瓶颈。因此，你必须监视所有的组件，包括应用程序服务器、数据库、网络和路由器。查看关键的因素并与正常的（预期状态）比较。如果找到了偏差，就更精确地调查这些部分。 系统健康视图经常提供了对受约束资源的认识，但是对于识别问题的根本起因不一定是充分的。对于运行在Java虚拟机（JVM）上的Java 2企业版（J2EE）应用程序代码来说这种情况很明显。例如，如果系统健康监视发现运行应用程序的服务器的CPU利用率很高并且某几个小服务程序的响应时间很长，实际根本的起因可能是应用程序中的某个不好的循环、同步问题或者数据库索引丢失。为了解决这个问题，你必须获取更多的信息来找出问题。 应用程序视图。第三个监视的尺度是查看应用程序内部来帮助查找困难的应用程序问题。在某个快照提供给定实例的所有Java线程活动信息时，应用程序视图可以给你精确显示某个缓慢的小服务程序正在做什么的信息。深入查看应用程序的内部执行对于查找困难的性能问题是很重要的。 　　监视什么 　　在最终用户视图尺度上，监视站点的"用户负载"、服务的事务和用户经历的响应时间。这些都是相同的基本监视数据点，你能在预生产性能和压力测试中捕捉到这些信息。 　　监视最终用户视图使你能追踪Web站点的响应时间是否在增加，请求是否在增加以及增加的速度，增加是否是正常的、预期的状态。监视的三个主要因素是： 　　1、负载（并行用户的数量） 　　2、响应时间 　　3、输出（每秒钟的请求数量）图1：负载、响应时间和输出之间的预期关系 图1显示了这些规格之间的预期关系。A部分是轻负载区，显示随着并行用户请求的增加，输出几乎直线增长。在某个点开始出现拥挤并且输出增长率很慢，一直达到某个饱和点，这个阶段称为输出平稳段，它表现了输出值的上边界。其最大值由瓶颈决定--典型的情况是Web站点上饱和的资源。B部分是重负载区，随着客户端请求的增加，输出相对不变，但是用户载入的响应时间相应地增长。如果请求的数量加倍，响应时间也会加倍。C部分是波浪区，在某个点一个系统组件被耗尽。此时，输出开始降低和响应时间增加的速度比直线还要快。 通过检测用户请求的数量、输出和响应时间，你能够知道站点显示的正常响应时间是否根据请求的容量而增加，或者必须仔细研究响应时间问题。例如，大量的并行客户端载入的测试结果显示当并行用户翻倍（从10个增加到20个）时，平均响应时间也翻倍（从150毫秒到301毫秒）了（图2所示）。如果你监视到响应时间和用户请求都翻倍了，应该是站点的正常状态。监视器显示你有更多的负载，因此响应时间相应长一些。在实际运行前有效的性能测试和能力计划能帮助你确定站点的饱和点。图2：40个客户端测试的最终用户响应时间 如果站点接收到的增长的负载超过了计划估计的容量，考虑使用缩放技术处理过多的负载，同时维持响应时间不变。但是，如果监视显示响应时间翻倍了而请求没有成比例增加，你就必须使用到第二种监视尺度--系统健康，以找到系统中是否有未预计到的约束，以及在哪儿找到问题所在。 　　检测响应时间问题 系统健康监视对于检测组件层的响应时间问题是很关键的。有很多监视器可以用于检测环境的全面健康状况、趋势并帮助解决问题。每个生产站点必须开发一个监视测量并决定对Web站点的每个组件使用哪种关键的监视器。 监视系统健康使你了解Web站点上所有组件的关键信息，帮助你定位受约束的资源。一旦找到了这些资源，需要进一步发现和解决约束的起因。对于WebSphere应用程序，检查应用程序统计表和Web应用程序监视器、中间件运行时监视器和服务器监视器。本文没有仔细讨论讨论所有的监视器。 Web应用程序监视器。 前面我提到，在最终用户视图中，并行请求、响应时间和输出是用户角度的标准。这三个主要的因素对于Web应用程序组件（例如Web页面、小服务程序、企业JavaBean）的每个服务器层来说也适用。查看每一层的响应时间和请求数量能帮助你识别可以在哪儿找到问题。例如，如果应用程序服务器上的响应时间和请求数量显示正常，你就知道将研究焦点集中于Web服务器、网络和客户请求与应用程序服务器之间的其他组件。 对于典型的WAS开发，用户的请求通过HTTP服务器传递，接着调用在应用程序服务器上配置的一个小服务程序。你可以监视HTTP服务器和应用程序服务器上的应用程序性能。根据特定的监视工具和使用的HTTP服务器，你可以监视HTTP服务器的任何一个或所有三个主要因素。 40个客户端负载的状态快照运行并显示，在这种特别的刷新间隔中，处理了40个请求。不幸的是，这个特定的Apache监视工具没有提供把计数器复位为0的简单方法，因此总共的访问（请求）和每秒钟的请求覆盖了整个6个小时的服务器周期，并且没有与WebSphere监视器相应的时间间隔。 监视器为每个应用程序服务器负载、响应时间和输出。图5显示了一个使用资源分析器（Resource Analyzer）的小服务程序化监视器快照。这个图表显示了40个客户端运行的应用程序服务器因素，显示在应用程序服务器中并行请求的平均数量在35到40个之间，平均响应时间小于600毫秒。你能使用整个请求计算每秒钟的请求数（图2中与40个客户端负载测试相应的这些规格的最终用户响应时间为635毫秒）。图3：40个客户端运行的应用程序服务器各因素 　　中间件运行时监视器。你可能需要通过监视缓冲池的利用请求，监视Web站点上流动的请求的健康。图4显示了一个典型的查询网络。对于查询网络中的每个缓冲池或容器，你查看利用情况。对于IBM HTTP服务器，你监视当前正在处理的请求和空闲服务器。图4：WebSphere查询网络 　　你也能监视Web容器的线程池--对象请求代理程序（Object Request Broker，ORB）和数据库连接池。如果任何一个缓冲池达到了最大的容量，它就可能阻塞了业务流。通常，较大对于性能不一定更好，因为额外的容量浪费了资源。因此，队列和缓冲池的适当协调对于最佳性能是很重要的。图5：Web容器线程池监视器 　　图5显示了Web容器线程池的快照，它的默认线程池设置为最小25，最大50。如果你运行40个客户端负载，线程池建立的补充线程高于最小的25个，平均运行38个线程。该缓冲池永远不会达到最大容量50。一旦线程建立了，它们中的大多数就在使用中，结果很少线程被消除。这个图表显示了Web容器线程池的较好的情况。图6：较差的动态线程池示例 　　相反，图6（它是故意做的）显示了效率低下的Web容器池。在这个例子中，40个客户端负载运行在线程池设置为最小、最大都是2个线程的Web容器上运行。此外，我选择了当缓冲池超过最大容量时增加。你可以看到，缓冲池大多数时间运行在最大容量上。因为在超过最大容量时我允许缓冲池增长，建立和消灭数以百计的容器线程使系统失效了。 　　对于所有的WebSphere线程和连接池，高百分比的最大值显示特定缓冲池可能引起瓶颈。你能使用另外的监视器（例如缓冲池尺寸）和活动线程来帮助协调缓冲池。 　　服务器监视器。中间件和Web应用程序在下层服务器上执行。你必须查看所有服务器（包括Web服务器、应用程序服务器和数据库服务器）的系统监视器--CPU利用率、I/O和分页。 　　应用程序视图：Java应用程序 　　当引起性能问题的原因在Java应用程序中的时候，你必须能够监视在JVM中执行的应用程序内部发生了什么事情以识别有问题的源。典型的应用程序视图层次的监视需要大量的J2EE编码和具体应用程序的相关知识。解决表面上是负载问题的Java应用程序问题可能需要这个层次的监视。你可以从两个角度分析运行在WebSphere上的应用程序：（1）应用程序调用流和响应时间情况，（2）线程状态执行情况。 　　从应用程序调用流角度看，你需要查找消耗最大响应时间的应用程序部分。调用流可能显示某个小服务程序作了多重EJB调用，而每一个EJB调用作了多重JDBC调用。分析调用流使你识别了应用程序消耗最多时间的部分。图7显示了HitCount应用程序调用流的一部分。这个例子显示，JDBC响应时间大约为1毫秒--是整个响应时间中很小一部分，显示JDBC调用不是性能问题。 HitCount Servlet Service method (24 ms) -> Inc Bean Increment method (22 ms) -> DBPreparedStmt executeUpdate (1.28 ms) DBPreparedStmt executeQuery (1.04 ms)
示例应用程序调用流 　　作为分析应用程序调用流的补充，你可以检查JVM中的每个线程的状态。线程状态执行情况监视某个时间应用程序内的每个线程的行动。通过查看线程栈中的结构，可以识别并行瓶颈。例如，我修改了HitCount小服务程序来调用缓慢的同步日志程序（通常的问题）。在运行修改过的HitCount时，执行了线程转储。运行50个线程时，39个是栈顶部结构，9个在等待来自Web服务器的工作。线程栈信息使你能与Web应用程序程序员一起排除可伸缩性瓶颈。 　　接口和加工 　　大多数操作系统和应用程序包含了接口以获得关键的性能指示并为监视性能提供基础的工具。此外某些行业方案有具体产品的性能接口以提供端对端性能监视方案或者专业的监视方案。 　　WAS运行是允许轻量级的、关键的运行时和Web应用程序性能因素的服务器端性能数据集合。WAS的一部分--性能监视基础结构（PMI），支持多种客户端检索选择，包括Java和HTTP/XML接口。 　　维持最佳的性能 　　性能监视对于Web站点的成功是很关键的。了解每个监视尺度的角色将帮助你在性能问题反面影响Web站点前识别、定位和解决它们。有了WebSphere API和支持工具，你能监视每个尺度来确保Web站点的性能最佳