如何优化应用中间件的参数以期提高系统的性能？

说到优化，往往用到的词是调优，既然是调优，就是case by case的调，N个参数这个一会儿调高，那个一会儿调低。中间件的参数也是这样，参数很多，互相牵制。参数有默认的设置，根据自身系统运行的情况，可以进行调节，不能太大也不能太小，找到一个接近最优的组合。

一般情况下，一个新的系统隆重出场，安装上之后，参数都是默认。所有调优的起点都是这套默认的参数。然后根据预期的性能模型（例如并发用户数、操作频度、业务类型、吞吐量等等）施加压力。如果是已经在生产上运行的系统，那么可以直接在业务高峰期抓取监控信息。

根据各个监控指标看看哪个指标不够用了，例如jdbc连接池利用率90%，jdbc连接等待时间较长，那就谨慎考虑是否增大jdbc连接池的数量。但前提是，调整某一个指标，需要考虑对其副作用。例如，如果数据库这时候资源利用率很高，SQL语句执行时间较长，这时候如果把jdbc连接池这个大口子给打开了，会导致灾难性后果，要么就是吞吐量更低了、响应时间更长了，要么就是系统瘫痪了。

再例如，会话数、线程数到达最大值，接收不了新请求了，要么增大会话数、线程数看看，要么缩短每个会话的时间。如果增加会话数、线程数，就要考虑这个应用服务器现在的资源利用情况能不能撑住更多的业务，后端的数据库能不能撑住更多的业务。

增大这些指标有一个终极影响，就算别的影响都没有，占用更多的内存总是有的吧。这一点和增大高速缓存、数据源语句缓存大小有点像。这里的性能提高了，而别的地方因为缺少内存而性能下降了，没准整体的性能也下降了。

如果是生产环境的调优，一定要评估其影响后，采用渐进的方式调，即目标是从10调到50，但一次只增加一点，10-20-30-40-50，这样慢慢调上来，这样不至于因为未知原因一下子把系统拖垮。

另外，调什么参数，一定要了解其含义、原理、调整后的收益和风险是什么，最好是N个参数能在脑子里缠绕为一个整体。