Linq 到 SQL 连接
我正在将 Linq to SQL 用于一个相当复杂的站点，上线后我们遇到了多次数据库超时。 我注意到的第一件事是有相当多的数据库连接。
由于具有 ADO.net 背景，我们过去常常对其进行编码，以便任何站点都只使用一两个池连接，即使并发用户数量相当少，这也会产生可接受的性能。
所以我的问题是，这种旧的方法是否有缺陷，或者有没有办法通过 LINQ 来实现？ 看来我们的性能问题是由如此多的数据库连接引起的，但如果这是一个问题，我想它会在所有 LINQ 教程中提到。
有什么建议么？
I'm using Linq to SQL for a fairly complicated site, and after go live we've had a number of database timeouts. The first thing I noticed was there are a fairly large number of connections to the database.
Coming from an ADO.net background we used to code it so that any site would only use one or two pooled connections, and this resulted in acceptable performance even with a fair few concurrent users.
So my question is, was this old way of doing it flawed, OR is there a way to do it LINQ? It seems our performance issues are being caused by so many connections to the DB but if this was an issue I'd have thought it would be mentioned in all the tutorials for LINQ.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我猜测您保留了 DataContexts，并且在完成后没有对它们调用 Dispose（或者至少将它们留在周围）。
相反，您应该初始化 DataContext，执行操作，然后在完成后将其释放。 您不应该在操作之间保留对它的引用。
最好使用 using 语句来处理对 IDisposable 的调用。
关于连接池，SqlClient 默认情况下会池连接，因此除非您明确将其关闭，否则您应该已经在利用它了。 当然，如果您不释放正在使用的连接，那么池化只能带您到目前为止。
I'm guessing that you are keeping DataContexts around and not calling Dispose on them when done (or leaving them around, at least).
Rather, you should initialize your DataContext, perform your operation, and then dispose of it when done. You shouldn't hold a reference to it between operations.
Preferably, you would use the using statement for handling the call to IDisposable.
Regarding connection pooling, the SqlClient pools connections by default, so unless you explicitly turn it off, you should be taking advantage of it already. Of course, if you aren't releasing connections you are using, then pooling will only take you so far.