August 19, 2014 at 8:20 am
I have a DB that is currently not normalized and will be getting about 100K concurrent users that will mostly be doing Read-Only operations from multiple tables.
I am trying to figure out if I should start thinking of having a DB per client (1000 clients) or if I should normalize the database and keep it as a single DB with good indexes and partitioning.
I am looking for any ideas that you may have.
Hardware is not a problem but 100K concurrent users is.
Thoughts?
August 19, 2014 at 2:10 pm
I really don't know the answer, just responding to an interesting question, and hoping to see more comments.
I found this figure: Maximum User connections: 32,767
http://msdn.microsoft.com/en-us/library/ms143432.aspx
So if you're actually trying to connect 100k sql clients to one server, that 32k number doesn't look so hot. But if you have an app doing conection pooling, you can at least ditch the 32k number as a hard limit.
Now maybe it comes down to what the 100k connections are doing. I could certainly see building a web site for 100k connections (maybe a little web farm or something), in theory, even a single box should be able to handle 100k connections, but if thats 100k really really busy connections, that could be a different story.
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply