On Fri, Jun 24, 2011 at 8:10 AM, Perrin Harkins <per...@elem.com> wrote:
> On Fri, Jun 24, 2011 at 12:45 AM, Phil Van <pv2...@gmail.com> wrote: > > One should really try mod_fcgid + perl application. that is lighter, > faster, > > and more stable. > > FastCGI works fine, but these claims are not true. I benchmarked > several FastCGI environments and none of them were significantly > faster than mod_perl. They are also not lighter. The only thing > "heavy" in mod_perl is Perl, and that will be there in FastCGI, PSGI, > etc. > Interesting.... those are mod_fcgid + CGI, compared to plain Apache + mod_perl + libapeq ? I think all those application servers end up at roughly the same speed. 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. > > > mod_fcgid provides also authenticate/authorize/access controls, besides > > dynamical content. > > True, but my experience is that the documentation for these is pretty > weak compared to the mod_perl equivalent. They don't seem to be used > by many people. The ones for mod_perl are widely used and have many > modules on CPAN for common needs. > > 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. I am also trying to promote the new mod_fcgid here :-) Here is a typical scenario to run AAA in Fast::CGI 1) enable FCGI aaa program on the directory via httpd.conf or .htaccess 2) run aaa_program($r) if ($ENV->{FCGI_ROLE} && ($ENV->{FCGI_ROLE} eq 'AUTHORIZER')); 3) return 200 OK if it passes, or 401 if fails However, the trend is to move these functions away from server APIs > and put them in the application framework, so it may be a moot point. > > 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. > - Perrin >