0

在我们的 ASP.NET 应用程序中，我们实现了一个构建在 MySQL 之上的数据层，它使用Connector/NET来实现实体框架。

这对于我们的大多数 CRUD 操作都非常有效，但是当我们运行包含数百条记录的 INSERT 语句时，它会引发“连接太多”异常。

虽然我接受我们正在进行大量单独的读/写调用（我们在每次插入之前查询重复条目，而且还有一个审计日志，它也使用每个插入的单独查询写入）但不应该连接游泳池照顾这个？

此外，在这个类似的线程中，OP 被告知使用我完全同意的using语句，在我们的例子中，每个查询都已经包含在using语句中，我假设它正在以有效的方式管理连接：即，不处理如果另一个请求已排队，则它们。

无论如何，connect timeout目前是 50，这已经很小了，对吧？将其移至 500 没有任何区别，而将其移至 10 在引发相同异常之前使我的插入量增加了大约 50%。

那么，鉴于 DbContext 的每个实例都包含在using语句中，为什么我们会收到“连接太多”异常？

更新：我们发现问题的根源实际上是由我们的一个存储库在其构造函数中打开数据库连接引起的，即使该连接从未使用过。对不起，伙计们，这原来是一个红鲱鱼。感谢您的建议。

4

2 回答 2

0

Not exactly the answer you are looking for... but:

Is there a particular reason why you aren't using the same connection for all your actions?

As an example:

If you are performing 50 inserts in a row and by consequence 50 queries (one for each insert) using the same connection would greatly improve your system performance.

于 2013-07-30T08:29:52.450 回答
0

典型插入的平均执行情况如何？是否有可能在处理前一个请求之前获得新插入（带有所有围绕插入子查询）请求的连接？您是否尝试过分析/记录您的 DAL 插入功能在这种繁重的插入负载期间的执行情况？有时，通过将部分逻辑从“纯实体查询”移动到触发器（审计日志，请参阅如何编程 MySQL 触发器以将行插入另一个表？）和存储过程（自己查询重复项+插入），因为您将减少到服务器的往返次数/对查询的更多控制。

而且，作为最后一个选项，您可以尝试挖掘 mysql 配置，增加连接限制，默认为 100 个连接。但是这个想法通常只是推迟在 DAL 中搜索瓶颈。

于 2013-07-30T10:25:58.710 回答