Maximum Connections - Reasonable Limit

[DebiJo]

We are looking to purchase a new piece of software that uses SQL 2000. This package would have upwards of 1,500 concurrent users. This application does not use connection pooling and will require multiple connections to the database per user. So, I could easily be looking at 9,000 connections at any one time. YIKES! That scares me. Should it? Does SQL Enterprise handle connections better than Standard? Does memory really make a difference?

I know that the maximimum "limit" is like 32,000 connections or something, but saying it is the maximum and actually having it perform are two different things.

Thanks in advance,
Debi

 

[mrdenny]

You shouldn't have to many problems, as long as the queries don't tred on each other. I've seen SQL standard handle that many connections with out to many problems. The only reason that you might want Enterprise in this case is for more memory.

With more memory the system will deffinetly run better, as more information that the users are constantly quering can be loaded into memory. What drives SQL nuts isn't connections per say, it's active connections. Of those 9000 connections how many will actually be doing something at the exact same time.

Since the app doesn't support connection pooling, that tells me that odds are most of those connections will be idle most of the time. Most apps that use databases spend about 3% of the day actually doing something with the database, most of the rest of the time is the user reading what is on the screen, or typing additional data into the screen.

All that being said, If you can afford it, get a server that can hold more CPUs and more memory than you think you will currently need, so that if you need to do an upgrade, all you have to do is through in more CPUs and more memory.

Denny

--Anything is possible. All it takes is a little research. (Me)