Talking of mod_perl and FastCGI. Can you point me at any discussion regarding the technical merits of each?

There's something in the mod_perl mailing list, which lists pretty much all there is to it.

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}

Security isn't significantly different between them. In both cases, you may choose to run as a trusted user or not. In both cases, a crashed script only affects its own child process, not the server as a whole. In both cases, screwing up the perl environment can affect later perl scripts run in the same process. That's hard to avoid in any persistent environment.

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.

The requests to Apache will probably end up with different processes every time.

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.)

"Giving perl programs full access to the guts of apache is arguably a bad idea."

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.

There are discussions on this all over, including PM. I wrote a bit here on the Catalyst list. For a long time, FastCGI had too small a userbase for me to consider it a good choice. That changed somewhat with Ruby on Rails, which often uses FastCGI, but now there's a vocal movement among them to ditch FastCGI, claiming it has insurmountable problems. (I think they're exaggerating, but since I don't run Rails...)

One thing that might be relevant to you is Win32 support. With Apache 2 and mod_perl 2, Windows support is pretty good and up-to-date binaries are available. Last time I looked for the FastCGI support on Windows, it was not in good shape, but that was a few years back so it may have changed.

Thanks. The problem I am looking at will

1. Run under Apache on unix. (Not sure which flavour.)
2. Has a fairly substantial loadtime component (data) that would best persist.
3. Has a requirement to persist a fairly substantial amount of relatively expensively generated results between successive requests.
4. Takes a fairly substantial amount of time (circa 1 second) to generate those results.
5. Little or no need for most phases of the Apache API. (No authentication or authorisation needs for example).

On the basis of the feedback to my question (shmem and others), I'm leaning towards a FastCGI Server solution. But I've still done nothing but read about it, so all feedback, especially from those with your in depth knowledge of a subject about which I know precious little, is much appreciated.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.