性能调优的基本步骤
部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的 J2EE应用，一个请求到来时，往往需要经过多次转发：网络 > Web服务器Web容器 > EJB容器 > 数据库。而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。 如果我们把每一次转发的待处理资源都看成一个队列，如图3：

待处理资源队列
对于WAS调优，要记住的一个基本原则就是，使得在队列中等待的请求的数量最小化。在实践中我们发现，为了达到这个目的，最有效的配置方式 就是使得队列成为一个“漏斗”。也就
是说，越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于或等于前面的队列。按照这个原则，调优的基本步 骤如下：
∙ 设置的是Web Server的最大并发用户：
o 这个设置是在f这个文件里面配置的。在Unix系统中，对应的属性是MaxClient；在Windows系统中，对应的属性是ThreadsPerChild。
∙ 设置Web Container的最大、最小并发用户：
o 在管理控制台中点击应用程序服务器 > server1 > 线程池 >WebContainer，根据观察的性能情况和应用情况输入合适的最小、最大进程数。
o Web容器线程池要 点就是：“通常，对于每个服务器 CPU，5 至 10 个线程将会提供最佳吞吐量”（现在的一个cpu可以用核来代替）。比如你的Pc Server有2块CPU，每块CPU都是4核，那么你一个Application Server可以设置的最小值和最大值可以分别为40、80。但是一般考虑到能充分利用CPU和Memory，或者为不同的应用启用不同的 application server，一台Pc Server上并不仅有这么一个appserver，而且还有别的进程在占用着CPU，
所以默认的10到50（Linux 系统上 25 个）是一个比较合适的值，当然更准确的值需要通过性能测试来确定。在 进行性能测试的时候，如果吞吐率不是很满意，或者在TPV中看到线程池占用一直是最大值，不要立刻就调大线程池的设置——往往吞吐率会更一步下降。这时候 要注意CPU占用率的情况、vmstat的r列值，特别是System状态占用率的情况，如果接近timeout was reached10%，甚至超过10%，那么可以肯定系统在进程切换上 面消耗的资源太多了。下调线程池的大小反而会提升吞吐率，而且会由于吞吐率的提升降低页面平均响应时间。
o
∙ 对象请求代理（ORB）的线程池大小：
o 在管理控制台中点击应用程序服务器 > server1 > ORB 服务 > 线程池，根据观察的性能情况和应用情况输入合适的最小、最大进程数。
∙ 设置数据库的连接池属性：
o JDBC 提供者 >数据库JDBC驱动名称 > 数据源 > 数据源名称> 连接池 ，根据观察的性能情况和应用情况输入合适的最小、最大连接数。
∙ JVM堆参数设置的性能调优：
o 应用程序服务器 > server1 > 进程定义 > Java 虚拟机，根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。
∙ ORB参数调用方式的性能调优：
o 应用程序服务器 > server1 > ORB 服务>选中按引用传递。
∙ 关闭动态加载开关：
o 企业应用程序 > 应用名称 > 关闭启动类重新装入开关。
o 关闭会话序列化，应用程序服务器 > server1 > 会话管理 > 分布式环境设置 > 分布式会话选择无即可。
这个调优的步骤只是涉及了利用WAS服务器参数的调整来优化应用程序的性能，实际上性能的好坏很大部分是取决于应用的设计。好的性能源自好的代码设计。一般说来，性能调优大概可以提高10％－40％效率，而糟糕的代码设计却会使得性能几倍的下降。
对于一般的 J2EE 应用程序而言， WAS 中最重要的优化参数包括针对 JVM、 Web Container和 Data Source等的。
  JVM
  Heapsize（-Xms 和-Xmx）：heapsize的大小依赖于系统平台和具体的应用等多种因素。最大 heapsize需要小于机器的物理内存，一般来说，设置最大 heapsize 为 512m 是一个常见的起点。同时，在生产环境中，最好将 Xms 设置为小于 Xmx的值。
 
  GC（Garbage Collection）：一般来说，良好的 GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少 5-6倍。GC的调优是通过在模拟压力的情况
  下不断调整最大最小 heapsize 来实现的。
  Heap Fragmentation：heap 碎片的问题在 JVM 中存在大对象的情况下尤为突出。减少碎片的方法包括调整 pCluster（-Xp）和 kCluster（-Xk）参数。
更多的 JVM调优参数内容，参考 JDK diagnostic Guide：www.ibm/developerw
orks/java/jdk/diagnosis/
  以及 WAS V6.1 信息中心的相关内容：
  publib.boulder.ibm/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunejvm_v61.html
Web Container
  对 Web Container 的调优是通过对 Web Container 传输链中各个通道（TCP、HTTP、WebContainer）的参数调整进行的。这些参数包括诸如 ThreadPool 的最大最小值，buffer
  大小， timeout 时间的大小， keep-alive 的值等等。各个参数的含义及具体调整方法参见 WAS V6.1信息中心：
publib.boulder.ibm/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunechain.html
 
Data Source
对 Data Source的优化包括两个方面。一是 JDBC Driver 的选取，尽可能应使用 Type 4 的JDBC driver，这种 driver 是纯 java 的，适用于 client/server 模式，并提供比 type2 和legacy/CLI 的 driver 更好的性能。另一方面是 Database 连接池的参数设置，主要包括最大和最小连接以及 timeout的设置。具体的设置于应用程序的特性和并发用户量相关，一般来说，可设置最小连接为 1 且最大连接为 30，作为一个继续调优的起点
Application Server 将在使用该数据源的每个应用程序服务器中创建连接池的单独实例。例如：
∙ 如果运行包含三个服务器的集，这三个服务器都使用 myDataSource，并且 myDataSource的“最大连接数”设置为 10，那么可生成多达 30 个连接（3 个服务器乘以 10 个连接）
除了 JVM，Web Container 和 Data Source之外，WAS 的性能调优还包括很多其他方面的内容，如 JMS、EJB、Session、Dynamic Cache等等。关于性能优化的更多内容，可参见WAS V6.1信息中心：
  publib.boulder.ibm/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc6toptuning.html
 
  另外，WAS  提供了若干工具，可以用于帮助衡量其性能。WAS  中免费提供的 Tivoli® Performance Viewer（TPV）允许客户对关键资源（如 JVM、Web 容器和 EJB 容器以及远程连接池）进行监视。这款工具使用非常方便，可以用于确定应用程序使用可用资源的方式，还可以提供针对行为不正常的远程资源的信息。例如，如果 数据库连接池显示为了获得连接进行了多次尝试，则可能表示远程数据过载，或者需要优化数据库，或者需要向不够大的池中添加更多的连接。与此类似， WAS 还提供了 Runtime Performance Advisor 功能，可以就系统中的潜在优化问题向管理员提供反馈。
 
  WAS Information Center （www.ibm/software/webservers/appserv/was/library/）
  包含了一个优化参数列表，还包括一个优化参数“热点列表”，其中描述最常用的经过调整的参数。这是一份不错的参考资料，有助于您了解在该产品内调整内存和资源的基本知识。
 
 
  其他的不错的参考资料包括 IBM®  红皮书，如  《WebSphere Application Server V6 Scalability and Performance Handbook》：
  dbooks.ibm/abstracts/sg246392.html
IHS
MaxClients  峰值的120%
yourhost/server-status
your_host/server-status?refresh=5
更改http server的配置文件参数KeepAlive。

  原因：这个值说明是否保持客户与HTTP SERVER的连接，如果设置为ON，则请求数到达MaxKeepAliveRequests设定值时请求将排队，导致响应变慢。


  方法：打开ibm http server安装目录，打开文件夹conf，打开文件f，查KeepAlive值，改ON为OFF，其默认为ON
MaxKeepAliveRequests 100默认 根据客户端的2倍 (2000)
2、更改http server的配置文件参数ThreadsPerChild值到更大数目，默认为50

  原因：服务器响应线程的数量

  方法：打开ibm http server安装目录，打开文件夹conf，打开文件f，查ThreadsPerChild值，默认为50，改到更大数目，视用户数多少而定，一般改到客户机数量的1.1倍，如200台，则设为220
关闭http server日志纪录
查CustomLog值，到没有注释的那行(行的开头没有符号"#")，将那行用符号"#"注释掉，以关闭日志纪录，提高处理性能。
更改Websphere的服务器处理线程数

    原因：线程的数量影响同时并发的请求数量

    方法：打开管理控制台，依次打开目录树，服务器->server1->web容器->线程池，修改"最大大小"的值，默认是50，改到 更大数目，具体视总用户数量和机器的配置而定，一般设置其等于或小于http server设置的MaxKeepAliveRequests的值。
Linux
本主题描述如何调整 Linux 操作系统以提高 WebSphere Application Server 的性能。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。