----- Original Message -----
From: "Sam Horrocks" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "mod_perl list" <[EMAIL PROTECTED]>
Sent: Saturday, January 06, 2001 4:37 PM
Subject: Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts
that contain un-shared memory
> > > Right, but this also points out how difficult it is to get mod_perl
> > > tuning just right. My opinion is that the MRU design adapts more
> > > dynamically to the load.
> >
> > How would this compare to apache's process management when
> > using the front/back end approach?
>
> Same thing applies. The front/back end approach does not change the
> fundamentals.
It changes them drastically in the world of slow internet connections,
but perhaps not much in artificial benchmarks or LAN use. I think
you can reduce the problem to:
How much time do you spend in non-perl apache code vs. how
much time you spend in perl code.
and the solution to:
Only use the memory footprint of perl for the miminal time it is needed.
If your I/O is slow and your program complexity minimal, the bulk of
the wall-clock time is spent in i/o wait by non-perl apache code. Using
a front-end proxy greatly reduces this time (and correspondingly the
ratio of time spent in non-perl code) for the backend where it matters
because you are tying up a copy of perl in memory. Likewise, increasing
the complexity of the perl code will reduce this ratio, reducing the
potential for saving memory regardless of what you do, so benchmarking
a trivial perl program will likely be misleading.
> > > I'd agree that the size of one Speedy backend + one httpd would be the
> > > same or even greater than the size of one mod_perl/httpd when no memory
> > > is shared. But because the speedycgi httpds are small (no perl in
them)
> > > and the number of SpeedyCGI perl interpreters is small, the total
memory
> > > required is significantly smaller for the same load.
> >
> > Likewise, it would be helpful if you would always make the comparison
> > to the dual httpd setup that is often used for busy sites. I think it
must
> > really boil down to the efficiency of your IPC vs. access to the full
> > apache environment.
>
> The reason I don't include that comparison is that it's not fundamental
> to the differences between mod_perl and speedycgi or LRU and MRU that
> I have been trying to point out. Regardless of whether you add a
> frontend or not, the mod_perl process selection remains LRU and the
> speedycgi process selection remains MRU.
I don't think I understand what you mean by LRU. When I view the
Apache server-status with ExtendedStatus On, it appears that
the backend server processes recycle themselves as soon as they
are free instead of cycling sequentially through all the available
processes. Did you mean to imply otherwise or are you talking
about something else?
Les Mikesell
[EMAIL PROTECTED]
