Louis Gabriel
wrote:
What I'm wondering is what kind of architecture would one have to have in place
to handle 12,000 db backed request per second (say, for example with a three
table query for each request processed).
What I'm wondering is how you came up with this number?
Sites whose load peaks at 12,000 DB-backed requests per second
would have to have tens of millions of users. A few things
you said lead me to believe that you don't really anticipate
that kind of load. For instance, you said,
Lets say, for instance, that you have a web service used by 12,000 external
users
...
To clarify, it won't be 12,000 request per second **every second**. But it
will be 12,000 request per second several times throughout the day. 12,000 db
backed request per second is a peak load number, not an average load number
...
The users will have different points of access probably about 20,000 at least
-- from all over the United States -- but not the world.
It sounds like you are going to have 12,000 users total -- not millions
of users handling "large amounts of money." In that case, there
is no way in hell your site is ever going to receive 12,000 concurrent
requests per second. It's like saying that if Verizon has 10,000,000
subscribers in New York City, it must have the capacity to handle
10,000,000 concurrent phone calls. Guess what. Verizon doesn't have
that capacity.
If your estimate of 12,000 db-backed requests per second
is based on the historic data from an existing installation,
that's one thing. Otherwise you'd have to know about
things like queueing theory, M/M/K/K models, and crap like
that to be able to estimate the likelihood of getting
more than n db-backed requests per second.
In other words, please clarify where the number comes from.
