如何（动态）确定最佳数据库连接数？
您将如何动态配置数据库连接池中的最大连接数？
我几乎放弃了使用“硬编码”（配置文件，但仍然）的连接数。有时，更多的连接可以提供更好的性能。有时，连接越少效果越好。 您将使用什么衡量标准来确定您是否打开了太多连接并且实际上是否因此损害了性能？请记住，我不能只是“停止世界”来运行性能测试 - 我需要一些我可以自己查询响应的东西（我没有具体的衡量标准 - 有些很慢，有些很快，我可以事先不知道哪个是哪个）来确定。
（请注意，我正在使用带有底层 DataDirect 驱动程序的 Java JDBC）
这种方法是否在某处使用过（并且是否成功）？如果没有，当您必须同时支持 Oracle 和 MS SQL 时，您将如何解决“最佳连接数是多少”，两者都适用于多个版本，并且查询本质上差异很大（索引查找/非索引查找/批量数据获取/条件匹配（索引和非索引，带或不带通配符））？
[我知道这类似于 optimal-number-of-connections-in-connection -pool 问题，但我问的是动态配置，而他问的是静态配置]
How would you go about dynamically configuring the maximum number of connections in a DB connection pool?
I've all but given up on using a "hard coded" (configuration file, but still) number of connections. Some of the time, more connections provide better performance. On other times, less connections do a better job.
What measurement would you use to determine if you've opened too many connections and are actually hurting performance by it? Please keep in mind I can't just "stop the world" to run a performance test - I need something that I could my own query responses (of which I have no specific measurement - some are slow, some are fast, and I can't know in advance which is which) to determine.
(please note I'm using Java JDBC with underlying DataDirect drivers)
Is this approach used somewhere (and was it successful)? If not, how would you go about solving the "what is the optimal number of connections" when you have to support both Oracle and MS SQL, both for several versions and the queries vary wildly in nature (indexed lookup / non-indexed lookup / bulk data fetching / condition matching (indexed and non indexed, with and without wildcards))?
[I know this is similar to optimal-number-of-connections-in-connection-pool question, but I'm asking about dynamic configuration while he's asking about static one]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您将用户排队等待空闲的数据库连接，那么他们正在等待未知的或人为强加的东西。
如果您让它们访问数据库，您至少会发现正在争夺哪些资源（如果有）。例如，如果是磁盘 I/O，您可以移动文件以将活动分散到更多或不同的磁盘上，或者购买一些 SSD 或更多内存用于缓存。但至少您知道自己的瓶颈是什么，并可以采取措施解决它。
如果存在某些查询或服务占用资源，您应该查看资源管理器来隔离/限制这些会话。
您可能还想关闭未使用的会话（因此您可能在午餐时有 500 个会话的峰值，但当几个较大的批处理作业正在运行时，将其降低到 50 个）。
If you queue users to wait for a free database connection, they are waiting on something unknown or artificially imposed.
If you let them through to the database, you'll at least find out what resource is being fought over (if any). For example, if it is disk I/O, you may move your files around to spread activity against more or different disks or buy some SSD or more memory for cache. But at least you know what your bottleneck is and can take steps to address it.
If there is some query or service hogging resource, you should look into resource manager to segregate/throttle those sessions.
You probably also want to close off unused sessions (so you may have a peak of 500 sessions at lunch, but drop that to 50 overnight when a few bigger batch jobs are running).
您需要自由流动的连接池，它可以根据负载自动调整。所以它应该有：-
1) 最小尺寸：0
2) 最大大小：根据您的数据库配置
3) 如果可用连接缺货，则加 1
4) 如果空闲时间为 X（配置的时间）秒，则放弃连接
5) 连接池应释放废弃的连接。
通过此设置，连接池应根据负载动态管理连接数。
You need free flowing connection pool which auto adjusts according to the load. So it should have:-
1) Min size: 0
2) Max size: as per ur DB configuration
3) increment by 1 if available connections are out of stock
4) abandon connection if it is idel for X (configured time) seconds
5) Connection pool should release the abandoned connections.
Witht this settings the connection pool should manage the number of connections based on the load dynamically.
接近缺乏兴趣。我们最终使用了一个很高的最大值，它似乎并没有对数据库造成太大影响。
closing to lack of interest. We ended up using a high maximal value and it didn't seem to bother the DB much.