Reputation: 13655
I don't know much about .Net Application Scalability and I'm sure some SO users know more about it and could help me out.
I know some questions have already been asked in the past, about having Connection Pool Overflows. Most of the time, it ends up talking about "How to close your connections properly" (which I highly think it's not my case, since all of my LinqToSQL queries are Disposed
accordingly, using this kind of code):
using (MyDataContext context = new MyDataContext())
{
return (from o in context.t_Orders
where o.order_id.Equals(_id)
select o).ToList();
}
Also, most of the answers I've read end up saying "A website should not require many concurrent connections, even for hundreds of users". But I'm talking about a massive WebApp, having over 500 concurrent users (who might be logging in in the same 2 minute range). Also, every page access is logged in a table (so consider multiple reads and inserts).
Now, I wonder if the default MaxPoolSize
of 100 connections is enough or could be a risk? If it might represent any risk, how should I modify the Connection Pooling settings?
Should I increase the MaxPoolSize
to a certain % of the concurrent users. Would it have any negative effect? Or should I increase the ConnectionTimeout
in order to prevent any InvalidOperationException
?
By the way, I entirely red William Vaughn's article "The .NET Connection Pool Lifeguard - Prevent pool overflows that can drown your applications", but I'm still pretty worried.
Upvotes: 1
Views: 1616
Reputation: 171168
Concurrent users doesn't mean anything. Concurrent requests is more meaningful. Will you have more than 100 requests in-flight at the same time? In that case I'd definitely increase max pool size because increasing the setting has no cost by itself.
You can safely increase it to at least 250. If you want to do more, you need to test (or redesign the application).
Upvotes: 1