You are right in what concerns environment; but a crash in mod_perl takes down the apache child, whereas with fastcgi only perl is blown away. The apache child talking to it serves a 500 error page (or whatever it got until that) and stays alive.

With a compromise, the situation is worse with mod_perl. If you've 0wn3d a mod_perl script, you've got apache, not just the script as in fastcgi.

--shmem

_($_=" "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}

With FastCGI, perl and the FastCGI child process dies. There is no meaningful difference between that and an apache/mod_perl process dying. In both cases, the current request is ruined, another process is spawned, and things continue.

With a security problem, you do not "get" apache if you compromise a mod_perl script. You have no access to anything else in the server but your current process, and certainly no access to the parent process. What matters is what you can do to the system itself, which is determined by what user you run as, and this is the same for FastCGI.

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

OTOH AIUI mod_perl is an apache thing, while as you say, FastCGI has to do with "communicate with the web server via sockets", where "the web server" is not necessarily bound to be apache, and indeed I've heard very very good comments from web-dev-knowledgeable people about LightTPD in these respects.

So fastcgi should be better for keeping a very large data model in-memory for a user?

(Yes, I have such an odd case where lots of data has to be read in before doing anything. It is an editor for game data.)

Oh, yes, that's one thing in that post which I didn't set right - the "primitive process management facility" is quite complete, actually.

As you say, fastcgi can be used to run a perl program as standalone server (e.g. apache directive FastCgiServer filename options) or pretty much like mod_perl, as multiple instances controlled by the process manager (dynamic mode, new processes are spawned as necesary up to a confiurable maximum).

--shmem

_($_=" "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}

As you say

I didn't say, I was asking if my guesses were correct. :-)

Thanks for the informative answer! If even BrowserUK didn't know, maybe the differences fastcgi/mod_perl should go into a FAQ/tutorial?

I think the answer is no. It looks like someone has requested a "sticky" load-balancing option for the FastCGI implementation in lighttpd, but it hasn't been implemented. It's a pretty dangerous route to go down, making your app depend on getting the same process every time, since it hurts your scalability. If you have few users and can't partition your data, you could consider a single-threaded server approach (like POE), but most of the time it is safer to partition the data into more manageable chunks.

most of the time it is safer to partition the data into more manageable chunks.

Agreed. But there is no good way to solve my problem.

I'd be happy to give my example; if you can point out a simple way to reorganize my 70 page of model, I'd be very happy. :-)

(No, I'm not a complete idiot that has done something simple in a complex manner; it was a very hard problem.)

It's a pretty dangerous route to go down, making your app depend on getting the same process every time, since it hurts your scalability.

Very good point. If this could get heavy use, I'd write it so the different backend servers had different DNS addresses for active sessions, then it should scale. Of course, another server could take over the job (heartbeat) -- but would have to reinit the data.

But when that design start to trash (not enough memory for all models of all users), I'd start to cry. :-)

You must be joking. Full access to Apache's API is exactly what makes mod_perl such a great idea. If you require less than full access then those hooks for each request phase that you mention can be enabled or not, one by one. You don't hear many experienced Perl programmers on dedicated servers complaining about having too much power, because we love it. Despite the hype and FUD nothing else even comes close.