聚沙成塔-小哈的记事薄

好东西，赶紧拉下来，介绍的太完整了，从内存调整到各种池大小优化。developerworks上都难得一见的完整调优案例。

原文链接：http://www.ibm.com/developerworks/cn/websphere/techjournal/0909_blythe/0909_blythe.html

IBM WebSphere Application Server 是一种可靠的企业级应用服务器，它提供了一组核心组件、资源和服务，供开发人员在应用程序中使用。每个应用程序都具备特有的需求，并且经常采用截然不同的方式使用应用服务器的资源。为了提供高度灵活性并支持这种广泛的应用程序，WebSphere Application Server 提供了一组全面的参数来帮助您增强对应用程序的调优。

应用服务器已经为最常用的调优参数设置了默认值，以确保能为最广泛的应用程序提供开箱即用的性能改善。但是，由于任意两个应用程序都不可能采用完全相同的方式来使用应用服务器，因此无法确保一组调优参数能适用于所有应用程序。这也突显了对应用程序执行有重点的性能测试和调优的重要性。

本文将讨论在 WebSphere Application Server V7.0（和之前发行版）中最常使用的一些参数，以及对它们进行调优的方法。与其他相关文章提供的调优建议不同，本文将使用 Apache DayTrader Performance Benchmark Sample 案例研究作为本文的上下文。借助 DayTrader 应用程序，您可以清楚地确定所使用的主要服务器组件，对这些区域进行重点调优，并观察各种调优更改所带来的收益。

在继续阅读之前，需要记住关于应用服务器性能调优的一些事项：

• 提高性能经常会牺牲应用程序或应用服务器的一些特性或功能。在计算性能调优更改时应该仔细考虑性能和特性之间的权衡。
• 应用服务器之外的一些因素有时会影响性能，包括硬件和操作系统配置、系统中运行的进程、后端数据库资源的性能、网络延迟等等。您在自己执行性能评估时，必须将这些因素考虑在内。
• 此处讨论的性能改善仅针对 DayTrader 应用程序，并且特定于此处描述的工作负载组成及所支持的硬件和软件栈。您通过本文介绍的调优更改实现的应用程序性能提升肯定会有所不同，并且应该通过您自己的性能测试进行评估。

阅读全文…

上一篇《WebSphere和DB2性能问题的发现和处理》中提到了通过定制WebSphere的性能监控基础结构（PMI）的监控对象，然后用自带的TPV（Tivoli Performance Viewer）工具查看运行情况。简单方便实用，却又有几个缺点：

1. 一次只能监控一个AppServer：从控制台使用TPV时，一个浏览器同时只能观察一个AppServer的运行情况。就算新开窗口选择不同的Server，之前的窗口也会在刷新后变动到之后的Server运行情况。
2. 在保存数据方面存在缺陷：TPV可以开启日志记录，但是这种日志是XML格式，现在还没有很好的工具能分析，且每采样一次，就会生成一个xml文件，短短1小时后就有上G数据，对于磁盘I/O的压力以及空间大小的占用不可忽视。
3. 没有报表：我们无法查看某台WAS服务器一小时、一天、一周、一月或是任意指定的时间范围内的性能走势图。
4. 没有警报功能。

不过TPV本来就并非定位为专业的监控工具，它提供的功能虽简单，但能满足我们分析过程中80%的需求。这个系列将介绍一些WebSphere下的监控和实时分析工具，希望能对TPV是个补充。这次介绍的是Mercury出品的Loadrunner。

“LoadRunner 是一种适用于各种体系架构的自动负载测试工具，通过模拟实际用户的操作行为和实施实时性能监测，来帮助用户排查和发现问题。”我们使用Loadrunner都是作为压力测试工具，单用来作为监控工具有点大材小用。但在做压力测试时，WebSphere的运行情况是重要的观察对象之一。通过在Loadrunner中监控WebSphere，同时监控操作系统的资源占用情况、Web服务器的运行情况，可以对比各个时间点、时间段的应用表现。

比如事务响应时间上升的时候是否是Web服务器积累了许多keep alive的链接没有释放，或者JVM正在做一次垃圾回收，亦或是线程池已经到达最大值、数据库连接已经用光……

废话说完，接下去是如何监控WebSphere6.X的方法。

首先要准备好Loadrunner8.1，并打上Fp4补丁。LR8.0虽然能够连接到WebSphere，但是不能获得计数器，Loadrunner9.0和9.1是大的不像样了，一个软件上G，所以没有尝试过。

WebSphere 中的配置 – 设置 PMI 规格级别

默认情况下，WebSphere 服务器中的基础架构性能监视（Performance Monitoring Infrastructure，PMI）的规范级别为“Standard”。 可以把它改成“全部”，这样可以监控更多的计数器。性能方面，会有5%～10%的下降，这也是没有办法的。你可以在确保应用一切正常后关闭监控功能，用Loadrunner得到更符合生产环境的结果。

1. 连接到管理控制台 – http://ip:port/ibm/console
2. 点击左侧树的“监视和调整”，点击“性能监视基础结构（PMI）。
3. 点击需要启用数据收集的服务器。
4. 点击基础架构性能监视（PMI）链接。然后启用 PMI 并为当前监视的统计集选择“全部”，应用变更。

安装perfServletApp.ear

1. 点击企业应用程序，点击安装以安装 perfServletApp.ear 文件（默认在WebSphere/AppServer/installableApps目录下）
2. 如果服务器启用了管理安全性，那么还需要“做下关联设置，perfServletApp安装完毕，进控制台重新设置这个该应用的“安全角色到用户／组映射”，选择“monitor”后点“查找用户”，然后搜索，将控制台中所有的帐户所有出现，将你需要授权访问改应用的帐户选择到右边。“确定”出来后再选择“所有已认证的用户吗”，让“monitor”关联到这个帐户。”

完成上述两步后重启服务器，让配置生效。

在浏览器中输入http://ip:port/wasPerfTool/servlet/perfservlet，若能够看到WebSpere的xml格式瞬时性能指标则配置成功。启用安全性的会让你输入用户名和密码，如果没有做过上面第二部的mapping操作，会报

Loadrunner设置

Loadrunner运行“Run Load Tests”，然后在场景的Run中，设置显示窗口为6个（默认4个）

点击新添加到一个窗口，双击左侧“Available Graphs”中“Web Application Server Graphs”中的“WebSphere 4.x-5.x”，对，你没看错，是4.x-5.x。

在新出来的窗口上右键点击Add Measurements，在出来的对话框中点击“Monitored Server Machines”下的add，选择WAS运行平台，Name中输入http://ip:port/wasPerfTool/servlet/perfservlet

或者你可以修改LR的配置文件
dat\monitors子目录下的xmlmonitorshared.ini文件，进行如下修改
[WAS4ServletMonitor]
DescrīptionFile=WebSphereDesc.xml
ServletName=perfservlet/
ServletAlias=wasPerfTool/servlet
然后添加monitor machine 时只要输入ip和端口即可

然后点击下面那个add，就会出现添加计数器画面

之后你就能在窗口中看到计数器的监视情况了

我一般会监视下面这些计数器

上副图中完美的蓝色锯齿状曲线就是UsedMemory，当然你可以根据需要添加不同的计数器，可以看缓存的使用情况、命中率，Servlet的执行时间等等。比TPV可以说更加方便和“稳定”（使用过TPV的应该会有这个感受）。

最后附上监控IHS的方法

：

编辑httpd.conf文件，将LoadModule status_module modules/mod_status.so前的注释去掉，同时去掉下述几行前的注释。把Allow from中的.your_domain.com更换为你允许监控的IP来源即可，我的是本地地址。

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

重启IHS，在http://localhost/server-status 中你可以看到运行情况的概要，http://localhost/server-status?auto.Details是详细信息。在Loadrunner中添加“Web Server Resource Graphs Apache”这个Monitor即可。

今天分享一个由IBM应用开发合作中心撰写的关于WebSphere性能调优的PDF，阐述了在目前典型的J2EE应用系统中，如何判断性能问题或瓶颈。从中间件层和数据库服务器两个方面给出了指导意见，特别是WebSphere V5的监控，采用客户端模式，而并非V6.1中的从管理控制台直接查看。现在用5版本的项目比较少，也算是一个知识点的学习。

使用“定制”性能监控基础结构（PMI）的监控对象，

在应用服务器响应慢的时候主要查看

Web Container（Web容器）中

1. Thread Creates
2. Thread Destroys
3. Active Threads（活动的线程，如果该值比较高，说明有较多的请求在被处理，如果该值和设置的最大值一样大，则Web容器无法响应新的请求了）
4. Pool Size

在JDBC连接池中

1. Num Creates（创建的物理连接）
2. Num Closes
3. Num Allocates（从池中分配给程序的次数）
4. Num Returns（程序使用完后释放给池的次数）
5. Pool Size
6. Free Pool Size
7. Concurrent Waiters（并发等待连接数，如果该值比较高，说明有较多的线程无法获取数据源。）
8. JDBC Time（每个JDBC调用时间，包括网络传输）。

具体内容，可前去阅读。