前言
What is the Cause of the Performance Problem? 或者是How to Improve the Performance?
这是我们在系统开发、部署过程中都会面对的问题，但是却很难回答。从下面的这幅图就可以看到，一个系统的性能瓶颈（bottleneck)，可能在网络、防火墙，也能在Http Server，Application Server，或者是数据库；系统中一个或者多个“短板”的存在，就能让系统无法达到设计时的目标，无法满足已经签在合同里的SLA……
虽然性能问题牵涉到方方面面，但是本系列关注点在于中间件这一层。希望能用合理的配置避免诸如OutOfMemory（某些情况下）、数据库连接不够的发生，同时能应用一些参数使系统在不优化代码的情况下有5%到100%的提升。
言归正传
池（Pool）是WebSphere中最常涉及的概念之一。从网络、Web 服务器、Web 容器、EJB 容器，一直到数据源，每一个环节都线程池、连接池的影子。要想恰当配置这些池的大小，首先要了解漏斗模型。
通常，WebSphere应用中的一个请求到达服务器，到真正开始处理，要经过一系列的连接池。广域网上可能有大量的并发用户同时访问Web服务器，Web服务器上同时活动（Active）的连接可能高达10000个。但Web服务器到应用服务器（Web容器）的连接池大小可能只有200。Web容器到EJB容器的连接池更小，可能是80。然后，经过数据源（Data source）到数据库的连接最大可能只有25个。从Web服务器的连接池到数据库的连接池尺寸逐渐变小，像一个漏斗（funnel），所以称为漏斗模型。
摘自第二章
IBM 000-253中有这么一道题：
According to the Upstream Queuing model for performance tuning, what reflets the correct application of recommended settings for maximum concurrent clients?
A Web Server=75, Web container=75, Datasource =25
B Web Server=75, Web container=50, Datasource =25
C Web Server=50, Web container=50, Datasource =50
D Web Server=25, Web container=50, Datasource =75
根据漏斗模型，那么很显然应该选B。
那么实际生产环境中就如此依样画葫芦就可以了么？后面的池一定比前面的小么？如果当前性能不行，增大池的大小就能提高么？
绝没有那么简单。后面的池小于前者，比如数据库连接池小于web线程池，默认的假定是：并非每个JSP和Servlet都需要访问数据库。如果你的应用是数据库密集型的应用，基本上每个JSP和Servlet都需要访问一次或多次数据库，而且系统中还有一些不经过jsp或Servlet的后台进程。那么数据源的连接池就必须大于web容器线程池，否则会报无法得到连接的错。
下面按照我的经验讲述一下每层池大小设置值
对于Web服务器
IBM HTTP Server的优化就是对Apache的优化。一般需要调整httpd.conf中如下参数：
：用来定义Web服务器可以同时支持的最大并发连接数或并发用户数，默认值是600。这个值需要根据你所希望的同时支持的并发用户数来设置，一般是峰值的120%。当然这个值不能设的太大，毕竟Apache吃内存也是很厉害。我遇到的项目一般是不用调整的，大家可以根据实际负载动态的调整MaxClients。
将 IBM HTTP Server 配置为显示状态页面：
- 编辑 IBM HTTP Server 的 httpd.conf 文件，从此文件的下列各行中注释注释字符（#）：
#LoadModule status_module, modules/ApacheModuleStatus.dll, ##SetHandler server-status # - 保存更改，然后重新启动 IBM HTTP Server。
- 在 Web 浏览器中，转至 http://yourhost/server-status。并且，单击重新装入以更新状态。
- （可选）如果浏览器支持刷新，那么转至 http://your_host/server-status?refresh=5 以便每 5 秒钟刷新一次。
上图给出了一些其它参数的推荐值。注意Windows平台和其它平台的不同（ThreadsPerChild相当于Maxclients）。关于, , 和 等的设置，以及MPM使用prefork或worker模块时的不同，可以阅读。
如果你的应用访问量很大，那么也许你需要优化一下操作系统的tcp/ip相关参数。
并修改“负载均衡”选项和“重试时间间隔”Web 服务器插件属性设置以提高性能
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状态占用率的情况，如果接近10%，甚至超过10%，那么可以肯定系统在进程切换上面消耗的资源太多了。下调线程池的大小反而会提升吞吐率，而且会由于吞吐率的提升降低页面平均响应时间。
这篇文章也许会使你对线程池大小对性能的影响有个感性的认识。
设置的地方大家应该都晓得，单击服务器 > 应用程序服务器 > server_name > 线程池。
数据库连接池
连接池的最小值，应该和性能测试时TPV观察到的jdbc平均大小一样，最大值根据实际需要设置，每次增长可以设置成大于1，增长一次到位。总之尽量避免连接池频繁的增长和收缩，减少wait的情况发生。
可以使用 Tivoli Performance Viewer 查找池中最优连接数。如果并发等待者的数目大于 0，但是 CPU 负载未接近 100%，那么考虑增加连接池大小。如果使用百分比值一直低于正常工作负载，那么考虑减少池中的连接数。
Application Server 将在使用该数据源的每个应用程序服务器中创建连接池的单独实例。例如：
- 如果运行包含三个服务器的集群，这三个服务器都使用 myDataSource，并且 myDataSource 的“最大连接数”设置为 10，那么可生成多达 30 个连接（3 个服务器乘以 10 个连接）
这是需要考虑的，别数据库端的连接大小不够了。此外，inactive timeout和timeout的时间应该大于收集时间。
总结
这篇文章参考了IBM的inforcenter和developworks，给出了优化WebSphere池大小的一些经验值，但是真正合适的大小还要参考实际的情况，总之调优是个循序渐进的过程。
继续逛逛
调整完了各种池的大小，接下来你需要对内存参数做些优化，这篇是纲领性的。
针对不同的JDK，你可以参考：