Deployment scenario

[dke at mac.com (David K. Every)]

Ute,

By consecutive hits, I assume you mean "almost simultaneous". If you meant
consecutive, the next question is "how consecutive". (How much time).

It really *REALLY* depends on your app, database, business complexity,
optimizations and so on. My first response is "no way". (2 app servers+1 db
server). 

This is all very loose. But with Apps I did the in past, you could get 5 -10
simultaneous users per instance (starting to slow down). And each instance
was in the say 50MB+ range (over time). And beyond like 10 instances per
machine, you were pretty saturated. So that's 100 simultaneous users per
machine.  We always had leaks, and so were rotating in and out instances.
(So pretend that one instance is just waste).

Now that was 5 years ago. (Slower machines). An older version of WO. That
was a very DB and Business Logic heavy app, with heavy pages. And with a low
cachability of data (high mutability of data). Others may have different
experiences. But I'd put modern numbers at more like 500 simultaneous active
sessions per machine. (Rough). You're asking for about 15 times that number?
I'd be very cautious about assuming that will fly.

Other Apps I've written cached everything (DB) into RAM (only changed
infrequently and recached when they got a trigger) and could be stateless or
mostly, and could handle 75+ simultaneous users per instance. (And multiple
instances). The same with Apps that use the DB to populate static or
psuedo-static sites, then use only/mostly apache to do the serving.  (The
machine restarts nightly to avoid leaking problems). I never loaded it to
failure, but I would assume on a modern G5 with enough RAM, it could be
easily above 7,500 simultaneous users per machine. So could meet your needs.
But that's a fairly rare type of App.

The nastiest part of that was that users persistence problems (timeouts
until you flush them out) is basically reserving spots for users (sessions)
that are inactive, but you don't yet realize are inactive. So if you have
hundreds of users that are going to be starting sessions each minute, then
going away, you're going to fill up a ton of space with these ghost-users
(even with your timeout pretty low). If you have users that are more
persistent, then things are a lot more predictable and better. (Not the CPU
overhead of starting and flushing sessions, and not the memory or retaining
them). 

As for what's the bottleneck question -- it seriously depends on the App and
load. I've seen cases where any of the following were the bottleneck; CPU,
RAM, HD, DB, Network, Apache (actually I think it was the adaptor). Again,
what are you doing. I suspect with that many users, you'd be doing tons of
light stuff -- most likely to run out of RAM or saturate CPU before anything
else. But hard to say...

Hope this helps...

Dave Every


On 1/27/05 5:58 AM, "Ute Hoffmann" <uteho@xxxxxxxxxxx> wrote:

> Hallo,
> I know I asked similiar questions before, so please be patient.
> 
> When I want to make sure 1500 consecutive Hits are possible for a WO App,
> what do I need in Hardware terms?
> 
> Xserve 2GB Double Processor with maximum memory...- How many approximately?
> A server for the DB in Addition?
> 
> How many instances? 1500? Probably not...
> 
> Can Apache be a bottleneck? I need to run more than one WebServer probably?
> 
> A similiar App was programmed with aspx and runs on two Application servers
> with a load balancer in between and with a third server for the database.
> Will that be enough for WO to meet the criterion of 1500 consecutive hits?
> 
> Thanks for some input.
> 
> Regards
> 
> Ute
> 
> Yes, I know it depends on the App, but ...