----- Original Message -----
From: "Sam Horrocks" <[EMAIL PROTECTED]>
To: "Perrin Harkins" <[EMAIL PROTECTED]>
Cc: "Gunther Birznieks" <[EMAIL PROTECTED]>; "mod_perl list"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, January 04, 2001 6:56 AM
Subject: Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts
that contain un-shared memory
> >
> > Are the speedycgi+Apache processes smaller than the mod_perl
> > processes? If not, the maximum number of concurrent requests you can
> > handle on a given box is going to be the same.
>
> The size of the httpds running mod_speedycgi, plus the size of speedycgi
> perl processes is significantly smaller than the total size of the httpd's
> running mod_perl.
That would be true if you only ran one mod_perl'd httpd, but can you
give a better comparison to the usual setup for a busy site where
you run a non-mod_perl lightweight front end and let mod_rewrite
decide what is proxied through to the larger mod_perl'd backend,
letting apache decide how many backends you need to have
running?
> The reason for this is that only a handful of perl processes are required by
> speedycgi to handle the same load, whereas mod_perl uses a perl interpreter
> in all of the httpds.
I always see at least a 10-1 ratio of front-to-back end httpd's when serving
over the internet. One effect that is difficult to benchmark is that clients
connecting over the internet are often slow and will hold up the process
that is delivering the data even though the processing has been completed.
The proxy approach provides some buffering and allows the backend
to move on more quickly. Does speedycgi do the same?
Les Mikesell
[EMAIL PROTECTED]
