|
Re^3: Perl needs Zend (mod_perl vs. fastcgi)
by shmem (Chancellor) on Oct 22, 2006 at 09:02 UTC
|
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:
- mod_perl has access to the apache api and hooks for each phase of a request
- 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}
| [reply] |
|
|
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.
| [reply] |
|
|
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}
| [reply] |
|
|
|
|
|
|
|
- mod_perl has access to the apache api and hooks for each phase of a request
- 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.
| [reply] |
|
|
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.)
| [reply] |
|
|
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}
| [reply] |
|
|
|
|
|
|
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.
| [reply] |
|
|
|
|
|
|
"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.
| [reply] |
Re^3: Perl needs Zend
by perrin (Chancellor) on Oct 23, 2006 at 14:20 UTC
|
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.
| [reply] |
|
|
Thanks. The problem I am looking at will
- Run under Apache on unix. (Not sure which flavour.)
- Has a fairly substantial loadtime component (data) that would best persist.
- Has a requirement to persist a fairly substantial amount of relatively expensively generated results between successive requests.
- Takes a fairly substantial amount of time (circa 1 second) to generate those results.
- 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.
| [reply] |
|
|
None of the requirements you listed would influence a decision toward one or the other, in my opinion. You might just want to do a quick try at setting up each one and see which one you find easier to deal with.
One thing you should consider with mod_perl is that the recommended setup for sites that need scalability is to run a reverse proxy in front to handle static and cached content, with an apache in back that just does mod_perl. The reasons for this are described pretty well in the docs. FastCGI essentially does this for you.
| [reply] |
|
|
|
|
| [reply] |
