|
Hi everyone! I need to know the maximum number of concurrent connections to SQL Server 2008. When I check from Server properties in Management Studio, it is set to zero with a text description that zero means unlimted connections.
However, on a Microsoft Page here: http://technet.microsoft.com/en-us/library/ms187882.aspx[^] there is a maxiumum of 32767 concurrent connections.
Could this value be for an older SQL Server since mine has unlimited concurrent connections (zero). I need to know this in my design plans of a new project. Thanks in advance.
|
|
|
|
|
I cannot comment on the number of connections, but in your design, you might want to consider a 3 Tier approach where each client does not have a direct connection to the database; only the middle tier would connect. This would greatly reduce the number of connections to the database.
Just a thought.
|
|
|
|
|
Danzy83 wrote: I need to know this
No, you probably don't actually. You're using a "disconnected architecture", right?
|
|
|
|
|
PIEBALDconsult wrote: You're using a "disconnected architecture", right?
Bloody hell is it even possible to build a "Connected" app on sql server? No don't answer that or we will see questions here about why there are locking issues on such a design.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Oh, uh, nope, no way, nuh uh, can't be done.
|
|
|
|
|
Danzy83 wrote: I need to know the maximum number of concurrent connections to SQL Server 2008
Why would your database need to handle that many connections?
At any rate if you have a windows server which is going to run an application (regardless of the applications running) that needs to handle a lot of connections then the server itself must be configured for that.
http://msdn.microsoft.com/en-us/library/aa560610%28v=bts.10%29.aspx[^]
|
|
|
|
|
Jschell I am thinking of this as if it is a national project in design stage. In the design, data will be accessed by medical institutions so I have to consider connections to the server in advance.
|
|
|
|
|
Definitely use a Web Service.
|
|
|
|
|
Danzy83 wrote: n the design, data will be accessed by medical institutions so I have to consider connections to the server in advance.
That is a business requirement not an implementation requirement. So exactly what do you think is going to be connecting to your database?
And did you actually attempt to size this? How many requests will your product generate? How long will it take to process them? How many users will be using it? What is the expected sustained rate? What is the burst rate?
If a request took 1 second and was made once an hour then you could handle 10,800,000 requests without reconfiguring anything on the database server.
There are less than 6,000 hospitals in the US. There are less than 200,000 medical clinics. How many of those are there in your market?
At least where I am selling into medical concerns is significantly difficult, even for institutions that have money. Many institutions operate on tight budgets. So expecting to own the entire market is highly unrealistic. (And yes I have worked on products in the medical industry.) So what is your real expected market share? What is your realistic expected growth rate?
And this of course completely ignores how these places are going to connect to you. The "internet" means that you are going to expose your database directly to the internet. Which is a bad idea and I suspect (hope) that institutions would refuse to do business with that arrangement.
Most performance problems occur due to architecture and design problems. Not technological problems. Attempting to solve serious performance problems with technology is likely to fail because technology only allows for incremental impacts on performance. And this of course presumes you use the technology right in the first place.
|
|
|
|