WebSphere 反向投资者: 调节 WebSphere 应用服务器时应适可而止

核心提示：为什么一些以前的技巧无法用于新版本在多个 IBM® WebSphere Application Server V7 研讨会上，我在过去几个月一直在为客户做演讲，WebSphere 反向投资者: 调节 WebSphere 应用服务器时应适可而止，性能总是一个流行的话题；具体来说，很多人都想知道如何调试获得最优性能

为什么一些以前的技巧无法用于新版本

在多个 IBM® WebSphere Application Server V7 研讨会上，我在过去几个月一直在为客户做演讲，性能总是一个流行的话题；具体来说，很多人都想知道如何调试获得最优性能。鉴于在这些研讨会中该话题的很热门以及对如何调试和调试什么大家普遍存在一定误解，我认为有必要简单介绍一下应用服务器调试中有哪些准则。

别调台！

即使您没用过这个短语，也一定听说过它。几年前，电视和广播上广告开始时经常出现这个短语。有了数码接收器之后，我们就不再使用调节旋钮来调电视或广播了（除非您的电视或收音机很老），但是在调试 WebSphere 应用服务器时这个短语却是个很好的指导。原因是经过一段时间，随着 WebSphere 应用服务器运行时不断改进，各种线程和连接池的默认大小变小了，因为与之前的运行时实现相比，执行相同（或更多）工作量需要的这些共享资源变少了。

WebSphere 应用服务器运行时中这种改进的一个例子就是 Web 容器线程池。在 WebSphere Application Server V6.x 之前，在并发客户端连接数和 Web 容器线程池中的线程数之间存在一对一的映射。换句话说，如果 50 个客户端在访问一个应用程序，那么需要 50 个线程来服务这些请求。在 WebSphere Application Server V6.0 中由于引入了 NIO（本机 IO）和 AIO（异步 IO），这种情况有了变化，它使连接管理能够由少数线程来处理而实际工作也能够由较少的线程来处理。

在最近的一个客户互动中，我发现公司误认为 “池大小越大，性能就越好” 并将池的大小改得比默认值大。在测试运行中，通过 IBM Tivoli® Performance Viewer 观察了实际线程使用和连接池使用情况之后，我能够通过实际降低 Web 容器线程池和 JDBC 连接池的大小将性能提高了 30%。降低池大小意味着 WebSphere Application Server 在管理运行时资源方面的开销也会减少；在这种情况下，不需要线程和连接对象，因此可以释放 CPU 和内存用于处理应用程序请求。