Re: Deployment scenario

Ute --

The answer, of course, is that it all depends.

I have analyzed/fixed deployments on several sites, including some that 
were heavy.

I've never seen the webserver become the bottleneck. You might want two 
webserver machines with a random router in front to increase 
reliability but I doubt you will want them for performance reasons.

The only times I've seen a database server become the bottleneck was 
when the tables weren't indexed, the application was incorrectly 
generating lots of spurious requests (100's/page), or the database 
server wasn't a database server: it was a proprietary query processor 
that was similar to a database server from an architectural point of 
view but didn't deliver the throughput you expect from a database 
server.

The real question you (always) need to answer, from an engineering 
point of view, is how much throughput (requests processed/second) the 
site can sustain. And that's the number you are going to engineer for. 
You can then back that up to a number of simultaneous users by making 
an assumption about user-requests/minute that will certainly turn out 
to be wrong.

You can measure the throughput and you should. Almost-simultaneous 
requests are not an problem, in and of themselves, requests that can't 
be processed get queued (up to some number that should be pretty large 
and is limited by the port configurations, I believe). If you know what 
your throughput is and you know how many simultaneous requests you 
might receive than you can figure out the longest/average service time 
for processing those requests and that is what should tell you the 
point at which performance is unacceptable.

Number of instances is always a question. In this day and age, physical 
memory shouldn't be an issue so that shouldn't be a constraint. It 
appears to be popular on the mailing lists to enable concurrent request 
processing in instances, and that's probably going to reduce the number 
of instances you deploy. I can't tell you how it will affect your 
performance, my guess is that it reduces it.

I have never turned on simultaneous request processing because I've 
never found a reason to. The case against is that it makes the 
application harder to write/maintain, it increases the exposure of 
users to program errors (if you're using fewer instances with 
concurrent request processing then if the instance goes down it takes 
more users with it), and I suspect such a configuration doesn't have as 
good bandwidth to the database server, per user (I haven't measured 
this).

On current-technology processors I suggest you start with between 8 and 
16 instances/processor. Then do some throughput measurements and adjust 
the number of instances accordingly. It should only be 1-2 days work if 
you already know the app and have the site set up.

Hope that helps,

	Tom