我在 Webpshere Application Server 6.1 中运行一个 webapp。这个 webapp 有一个规则类型的引擎，每个规则都从 websphere 数据源池中获取自己的连接。因此，我看到当一个用例运行时，对于 100 条输入记录，从池中获取大约 400-800 个连接并释放回池中。我有一种感觉，如果这个引擎投入生产，完成处理可能需要太多时间。
频繁地从池中获取连接是一种不好的做法吗？从池中获取连接所涉及的间接成本是多少？我的猜测是，所涉及的成本应该是最小的，因为池只不过是一个资源缓存。如果我错了，请纠正我。
连接池可以让您的连接在预期中保持活动状态，如果另一个用户连接到数据库的就绪连接被移交并且数据库不必再次打开连接。
这实际上是一个好主意，因为打开连接不仅仅是一次性的事情。有很多次访问服务器（身份验证、检索、状态等）因此，如果您的网站上有一个连接池，那么您可以更快地为您的客户提供服务。
除非您的网站没有被人访问，否则您不能没有为您工作的连接池。
游泳池似乎不是你的问题。真正的问题在于您的“规则引擎”在完成整个计算之前不会将连接释放回池。引擎不能很好地扩展，所以看起来。如果数据库连接的数量以某种方式取决于正在处理的记录数量，那么几乎总是非常错误！
如果您设法让引擎尽快释放连接，那么您可能只需要几个连接而不是几百个。如果做不到这一点，您可以使用一个连接包装器，每次规则引擎要求一个连接时都重新使用相同的连接，但这在某种程度上否定了拥有连接池的好处......
更不用说它引入了许多多线程和事务隔离问题，如果连接是只读的，它可能是一种选择。
连接池是关于连接重用的。
如果您在不需要连接的时候保持连接，那么您正在阻止该连接在其他地方重新使用。如果你有很多线程这样做，那么你还必须使用更大的连接池来运行以防止池耗尽。更多的连接需要更长的时间来创建和建立，并且需要更多的资源来维护；随着连接变老，将有更多的重新连接，并且您的数据库服务器也将受到更多连接的影响。
换句话说：你想用尽可能小的池运行而不用尽它。做到这一点的方法是尽可能少地保持你的联系。
我自己实现了一个 JDBC 连接池，虽然那里的许多池实现可能更快，但您可能不会注意到，因为池中发生的任何松弛很可能与执行查询所需的时间相比相形见绌。数据库。
简而言之：当您返回他们的连接时，连接池会非常喜欢它。或者他们应该无论如何。
我认为这是一个糟糕的设计。听起来像 Rete 规则引擎运行异常。
如果您假设每个线程（例如堆栈等）最小为 0.5-1.0 MB，那么您将消耗大量内存。检查进出池的连接将是最少的问题。
最好的了解方法是进行性能测试并测量内存、每次操作的挂起时间等。但这听起来不会很好。
有时我看到人们认为将所有规则都放入 Blaze 或 ILOG 或 JRules 或 Drools 只是因为它是“标准”和高科技。这是一个了不起的简历项目，但有多少解决方案可以通过更简单的表驱动决策树得到更好的服务？也许您的问题就是其中之一。
我建议您获取一些数据，看看是否有问题，如果数据告诉您有必要，请准备重新设计。
要真正检查您的游泳池是否是瓶颈，您应该分析您的程序。如果你发现池有问题，那么你就有调优问题。一个简单的池应该能够处理每秒或更多或大约 10 微秒的 100K 分配。但是，一旦您使用连接，将需要 200 到 2,000 微秒来执行一些有用的操作。
您能否提供有关您的规则引擎的具体功能的更多详细信息？如果每个“触发”规则都在执行数据更新，您可能需要验证连接是否被正确释放（将其放在代码的 finally 块中以确保连接真正被释放）。
如果可能，您可能需要考虑将数据更新捕获到内存缓冲区，并仅在规则会话/调用结束时写入数据库。
如果数据库操作是只读的，请考虑缓存信息。
就像您认为创建并释放到池中的 400-800 个连接一样糟糕，我怀疑如果您必须创建和关闭 400-800 个未连接的连接，情况会更糟。