Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

[Sam Horrocks]

 > >  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.

 > >  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.