Re: How do you use mod_perl for your web application?

On Fri, Jun 24, 2011 at 8:10 AM, Perrin Harkins <[email protected]> wrote:

> On Fri, Jun 24, 2011 at 12:45 AM, Phil Van <[email protected]> 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
>