The biggest difference between mod_perl and fastcgi are both pro and con for each, depending on one's preference or project needs:

1. mod_perl has access to the apache api and hooks for each phase of a request
2. fastcgi is basically a scheduler for perl server programs that communicate with the web server via sockets, so the only coupling between apache and fastcgi is on the I/O layer

Giving perl programs full access to the guts of apache is arguably a bad idea. If your perl program craps out badly it could take down it's apache process as well, and if it's compromised, you possibly have the whole apache 0wn3d. But then, bad scripts are bad anywhere.

fastcgi's interface to apache is arguably too poor (only I/O and environment) and the socket layer may be an impact on performance; I don't know, but there must be benchmarks somewhere. OTOH, a clean separation of tasks is mostly the right thing to have, and if a fastcgi script barfs out that doesn't bite the webserver as a whole; also, simplicity is often a benefit ;)

I personally prefer fastcgi for the latter reasons, but as said above it's all a question of the requirements of a specific project or setup.

--shmem

update: modified title for search

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}