Re: Deployment scenario

Tom, 

Excellent points. One more thing though.

You said,

On 2/3/05 8:27 PM, "Tom Blenko" <[email protected]> wrote:
 
> 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.
> 

I agree. However, here's a problem we had. If it takes 1 second of
processing time (or total internal latency), and you queue 10 simultaneous
requests in a sequential system -- the last guy in, is 10 seconds out (not
counting other latencies -- which magnify the problem). (We had worst case
pages over 3 seconds -- 10 or 20 simultaneous request is some serious
latency). 

Once we got beyond about 10-15 seconds, you can start to get request storms.
Users don't see immediate gratification/response, and will hit refresh or
the send button again (as they start getting frustrated) and they will do it
again and again, then leave. It can quickly behave like a DDoS attack on
your servers. Your user count goes artificially up in these cases
(radically). And the more they do it, the worse it gets -- and the more
impatient people become, the more they do it.  (The human factor).

So we calculated based on human patience threshold in worst case scenarios
(peak) -- and tried to factor in a large fudge factor for network/refresh
latencies. Because anything past the patient threshold (at peak) can trigger
these storms (and bring down your servers). Especially in high volume
applications. (IMHO).

Dave