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