On Fri, Jun 24, 2011 at 3:00 PM, Phil Van <pv2...@gmail.com> wrote: > Interesting.... those are mod_fcgid + CGI, compared to plain Apache + > mod_perl + libapeq ?
There are a number of modules like CGI and libapreq that run in multiple environments. My benchmark was a Catalyst app that just returned about 30K of HTML. > I think all those application servers end up at roughly the same speed. Yes, that's what I've seen. > In > my cases, mod_fcgid has fewer memory footprint, which is typically around > 15-20M per application loaded with common modules like DBI, SHA1 and JSON. > Eventually, one may serve more fcgid applications on the same machine. Are you comparing that to mod_perl with a proxy server in front of it? That is the equivalent architecture. If you remove the proxy, mod_perl becomes faster but the scalability suffers. I wouldn't recommend anyone run mod_perl without a frontend proxy of some kind. > This is true. The earlier mod_fastcgi is commercial licensed; and the > support to AAA is almost broken. But the new fcgid, originally designed by > xiaolan's friend (as in the previous post) is very active in development. As > far as I know, it would be one of the standard modules in the coming httpd > 2.4. Better FastCGI support for Apache would be great. > I am also trying to promote the new mod_fcgid here :-) I think the main competition among FastCGI users is pure-perl daemons as FastCGI backends. I had good success in my tests with one of those. > This is a bad idea --- how about to serve a static mp3 in member area? We > lose the advantages to serve the file as NOT MODIFIED, or system's efficient > sendfile call. You actually can access efficient file serving through the mod_perl API, but I agree, auth in the app framework is often a bad solution. My favorite solution so far has been to use things like mod_auth_tkt which let you write a complex auth system in your favorite language and then check credentials from an efficient C module that can guard a static file directory. - Perrin
