[ot] Re: mod_perl survey results

[Douglas Hunter <du...@allafrica.com>]

Perrin Harkins wrote:
> On Tue, Nov 11, 2008 at 3:42 PM, Adam Prime <ad...@utoronto.ca> wrote:
>> I'd really love to see a best practices kind of document, or at least a more
>> detailed document that described getting the light front / heavy backend
>> stuff working.  The mp1 guide has a pretty extensive section on the various
>> options, but it hasn't been updated to reflect apache2/mp2.
> 
> There's not much to update about it, except maybe that worker MPM is
> good for the frontend.
> 


I've been playing with the experimental event MPM for a front end 
caching reverse proxy, and have been very happy with the results so far.

-- Douglas Hunter

Re: [ot] Re: mod_perl survey results

["Philip M. Gollucci" <pg...@p6m7g8.com>]

Douglas Hunter wrote:
> I've been playing with the experimental event MPM for a front end 
> caching reverse proxy, and have been very happy with the results so far.
ditto.  Witness it in use here:

http://ridecharge.com

PXY: httpd 2.2.9 w/ event mpm
Cache: X
APP: mongrel

mongrel's replacement passenger took the mod_perl type approach.
which I haven't played with yet, but will be soon.

For people that think mod_perl is heavy, mongrels are just as heavy.

mongrel processors = 5
mongrels = 12

size / mongrel process = 225 MB

Thats ~4GB / app box already and less < 2 years dev.

I'd mention that Ticketmaster's httpd/mod_perl backend app severs had 
sizes of ~160MB and have over 400,000 lines of perl code, and 1700 packages.

We have not even close to that much in the mongrels.





-- 
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc.  http://p6m7g8.net
Senior System Admin - RideCharge, Inc.  http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70  3F8C 75B8 8FFB DB9B 8C1C

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.