views:

649

answers:

3

I am creating a website that I want to offer as a service. Each customer will have their own database, and each site requires two databases. If I have 100 active customers and they are all working in their sites, I could have 200 distinct connection strings.

How do I find out how many is too many? I don't want to wait until I encounter a problem - I want to plan for it way in advance.

+1  A: 

Are you using ASP.NET? .NET reuses the SQL connections with connection pooling. The real question, how many connections are open directly:

select COUNT(*) 
from master.dbo.sysprocesses p
join master.dbo.sysdatabases d on p.dbID = d.dbID
where d.name = '<database>'

You can call this statement from your DAL, but I think it's not neccessery. Why? I have experiences with MSSQL 2000. It's stable with houndreds of open connections.

If your webservices are stateless (and that's a common and good pattern I think), you can avoid that connection-problem.

With statefull (I mean there is an permanent open connection) services it's hard to plan and I think you should rethink your design.

boj
Are connection pools shared across app boundaries? IIS App pools?
Bryan
"ADO.NET searches for the pool associated with exact match for the connection string, in the same app domain and process. If such pool is not found, ADO.NET creates a new one, if it is found, it tries to fetch the usable connection from that pool."
boj
+2  A: 

Load test.

Write a little multi-threaded console application that opens many connections that you would like to establish and check it out for yourself. Try to determine how much query execution each connection will be performing and make sure that you include that in your test. When you're running your test, open up the performance monitor on the db server and watch the CPU cycles. Figure out what your benchmark is for CPU cycles and when you have gone over that then you have your answer. Make sure the db server that your testing is set-up exactly like the server that your going to be running in production.

Don't wait until you have a problem. Your customers will not be happy with that.

matt_dev
This response falls under the "easy for you, maybe..." column. I am not very adept at writing "little multi-threaded console applications", but this does sound like an interesting test.
Bob Jones
Heh, I hear you Bob and remember when I was there. It's just a suggestion but you may want to check out this blog I wrote about writing multi-threaded apps. The code is practically written for you. http://blog.swipht.com/2008/9/29/multi-threading...
matt_dev
O...therwise maybe find a 3rd party test suite to help you out that may make things a little easier on you. However you go about it you really should Load Test though with that many db connections, it's the only true indicator of what is going to break your system.
matt_dev
+1  A: 

The number of connections isn't a particularly useful resource to place limits on. The load on your server is a lot more sensitive to what is being done on those connections. What would you do with the knowledge? Refuse connections once a limit is reached? How will you know that exceeding that limit will start to degrade the user experience?

le dorfier
So true, the volume of connections you can support is initialy more of a function of available memory.
John Sansom