如果需要深入分析复杂问题，可以借助 IBM 提供的性能分析工具做进一步的研究。
参数优化建议
WebSphere ">Commerce 是基于 WebSphere 应用程序服务器开发的大型电子商务应用程序。在初次成功安装 WebSphere Commerce 应用程序之后，安装程序已经对服务器上的关键参数进行了初始化调整。这组默认值是 WebSphere Commerce 测试团队经过反复测试总结出来的一组初始化的参数值。建议维护人员以这组默认值作为初始值进行测试，比较测试结果与期望值的差距，从而有计划的对应用程序服务器的部分参数进行优化。如果您正在维护的生产环境运行正常，系统性能可以达到预期要求，我们不建议您对现有的环境进行优化。
其实调优本身并没有一个最优解。系统是否能够满足客户的需求并尽可能多的发现和解决系统存在的隐患，很大程度上取决于维护人员的经验。生产环境不允许做实验，所以在测试环境上进行完整充分的测试是非常必要的。另外生产环境和测试环境规模存在差异，在设置参数时需要考虑参数的适用性。
图 1. 性能调优的生命周期
WebSphere Commerce 参数优化原理
WebSphere Commerce 是一个数据库密集型的应用程序，大多数 JSP 和 Servlet 请求都需要访问后端的数据库，同时系统后台还运行着多个任务。所以它并不完全满足漏斗模型的假设条件。在参数调优过程中可以借鉴漏斗模型的原理，但是要针对特定部分做一些调整。
图 2. 数据库密集型应用程序的参数调优模型
在某一特定的测试环境中，假设有 200 个并发用户同时到达 Web 服务器，Web 服务器的并发处理能力为 75，应用程序服务器 Web 容器连接池的值为 50，之后请求从 Web 容器到数据库连接池的大小设置为 61，对于 WebSphere Commerce 这里不仅需要考虑 Web 容器处理的请求数，同时也要考虑预留一部分资源满足后台工作的需要，其中包括：1. 后台计划工作 2. 管理员登录管理控制台操作 3. 处理数据拷贝（data prop）。
* 数据库连接池的大小 = Web 服务器转发的客户请求 + 后台计划工作 (Scheduler Job) + 管理员连接后台数据库所产生的数据库连接请求 + 处理 data prop 的请求所需要的连接数
上面的例子说明，Web 容器和数据库连接池的大小之间的比例要根据具体应用程序的需求进行调整，不能盲目应用漏斗模型。