Tomcat连接池配置：属性设置。实例和建议 [英] Tomcat Connection Pool configuration: attributes settings. Examples and suggestions

问题描述

在我的Web应用程序的context.xml文件中，我使用：

In the context.xml file of my web application, I use:

<Resource name="jdbc/mydb" auth="Container" type="javax.sql.DataSource"
          removeAbandoned="true" removeAbandonedTimeout="60"
          maxActive="30" maxIdle="30" maxWait="10000"
          username="myuser" password="mypwd" driverClassName="com.mysql.jdbc.Driver"
          url="jdbc:mysql://localhost:3306/mydb"
          factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" closeMethod="close" 
          validationQuery="select 1" testOnBorrow="true" /> 

它可以工作，但我不确定30个同时连接是否足够（Web应用程序

It works, but I'm not really sure if 30 simoultaneous connections are enough (the web application is like an auction and there are also admin accesses to count).

此外，我不知道

 removeAbandonedTimeout="60"

太多，应该怎么做

是否有任何有关连接池方案，如何平衡资源属性的文章/文章？

Are any post/articles about connection-pooling scenarios, about how to balance resource attributes?

推荐答案

如何配置数据库连接池取决于使用它的应用程序的特征。我可以提供一些提示，但最终您将必须通过（负载）测试自己找出答案。

How to configure the database connection pool depends on the characteristics of the application using it. I can give some hints, but ultimately you will have to find out for yourself via (load) testing.

首先，阅读文档仔细。例如， removeAbandoned 选项是错误代码的后备，它不会关闭/返回与池的连接（来自文档：将其设置为true可以从无法关闭连接的应用程序中恢复数据库连接）。如果使用 removeAbandoned ，则在测试应用程序时也应使用 logAbandoned （设置为true）。 removeAbandonedTimeout 应该调整为运行时间最长的查询（来自文档：该值应设置为应用程序可能拥有的运行时间最长的查询。）。

First, read the documentation carefully. The removeAbandoned option for example is a fallback for bad code that does not close/return connections to the pool (from the documentation: Setting this to true can recover db connections from applications that fail to close a connection). If removeAbandoned is used, logAbandoned should also be used (set to true) when you are testing your application. The removeAbandonedTimeout should be tuned to your longest running query (from the documentation: The value should be set to the longest running query your applications might have.).

如果您的DBA比空闲连接更喜欢新连接，请咨询您，并调整 minEvictableIdleTimeMillis 因此（一些DBA宁愿使用较少的新连接（例如1个小时的空闲超时），而另一些DBA则希望尽快关闭空闲的连接（例如30秒的空闲超时）。）

Ask your DBA if he prefers new connections over idle connections and adjust minEvictableIdleTimeMillis accordingly (some DBAs rather have less new connections (e.g. idle timeout of 1 hour) while others prefer idle connections to be closed as soon as possible (e.g. idle timeout of 30 seconds)).

A maxWait 10秒对于生产可能太低了。我将其保持在50秒（数据库用于报告死锁的超时时间）相同，这样网络和数据库的连接（将发生）不会导致应用程序错误。另一方面，在（负载）测试时，将此值设置为较低（如3秒）以指示何时池太小（即 maxActive 太低） ）。

A maxWait of 10 seconds is likely too low for production. I keep this at 50 seconds (the same timeout a database uses to report deadlocks) so that network- and database-hickups (which will happen) do not cause application errors. On the other hand, when (load) testing, set this value low (like 3 seconds) to get an indication of when the pool is too small (i.e. maxActive is too low).

如果应用程序管理员需要保证访问权限，则仅需要一个（第二个）池即可为这些特殊用户提供服务。否则，不能保证他们可以进入，并且有可能在出现问题并且常规池已完全耗尽时必须进入。

If application administrators need guaranteed access, you need another (second) pool just to serve these special users. Otherwise there is no guarantee that they can 'get in' and it is likely they must get in when something is wrong and the regular pool is fully exhausted.

我已经提到在进行负载测试之前，需要一些额外的指针：

I have mentioned load testing before, some extra pointers:

• 确保测试数据库可以代表生产数据库。在生产数据库上长时间运行的查询必须在测试数据库上长时间运行。


• 调整池参数以进行测试（这样您会很快注意到奇怪的行为）和用于生产（使其稳定为


• 以较低的 maxActive 值重复进行负载测试批运行，直到您开始注意到吞吐量（或批处理运行时）的真正差异。例如，最近我测试了一个具有24个线程的应用程序，这些线程全部执行数据库操作，并以最大池大小为16开始。然后以最大池大小为8运行，几乎没有什么区别。然后以最大池大小4进行运行，并发现差异。因此，最大池大小为8就足够了。

• Make sure the test database is representative of the production database. A query that runs long on the production database must run long on the test database.
• Tune pool parameters for testing (so you notice odd behavior fast) and for production (make it is stable as possible and ensure you will notice really bad things).
• Repeat load testing batch-runs with lower maxActive values until you start to notice a real difference in throughput (or batch runtime). For example, I recently tested an application with 24 threads all doing database actions and started with a maximum pool size of 16. Then did a run with maximum pool size 8 and saw hardly any difference. Then did a run with maximum pool size 4 and noticed a difference. So maximum pool size of 8 was good enough.

一些效率提示：

• 确保在租赁和释放连接之间的所有代码仅执行数据库操作（例如，不记录日志，因为刷新到磁盘上的文件会浪费时间）。


• 确保在finally块中释放/关闭连接，以便连接不会从池中泄漏。


• 在租用前准备查询中使用的所有数据

快乐的负载测试...

Happy load testing ...

这篇关于Tomcat连接池配置：属性设置。实例和建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！