Re: More than mod_cgi less than mod

An embedded perl interpreter cannot replace mod_cgi, as mod_cgi is not limited to running perl-scripts; you can run any executable using mod_cgi. Could be compiled C binaries, or a shell script, as long as it 'talks' CGI.

The two main ways to make scripts faster, are to keep the perl interpreter in memory, and to keep the compiled scripts in memory. In fact, I don't see how these two could ever be separated; the perl interpreter also maintains the variable space, and as far as I know, there is no way to 'reset' it. There are many ways to alter the symbol table, and no guaranteed way to track these alterations. Because of this, there is no way to provide each request with 'clean memory' without reloading the perl interpreter.

Mod_perl already tries to solve these issues by creating a separate package for each cgi-script, thereby at least separating the variable space for the scripts. But it's trivial to manually access variables outside of this package. And it's not trivial to 'reset' the used variables after each request...

The nature of perl and it's interpreter make it very hard to establish what you propose. It's possible for the most part, but would require all cgi-scripts to 'play nice', and any script that doesn't can cause big problems. And harnassing memory usage is always tricky with perl; you have to know quite a bit about the perl internals to understand where it's all going...

PHP usage of variable-space was designed for this purpose, which is why it is capable of so much.

A possible way to do what you want may be to have a 'cgi-server' wrapped around all cgi-scripts, and have Apache pass all request to this other process. This would only require ProxyPass'ing from Apache, and a simple server-wrapper around the cgi scripts. In fact, I can't imagine such a wrapper doesn't exist yet. This would require the server to run this extra process though, and would possibly create extra maintenance problems.

A solution sometimes used is to use a separate mod_perl enabled Apache instance with a limited number of threads to handle the script request, and have a 'big' non-mod_perl Apache as the front-end. This makes use of existing tools, but limits the amount of problems that can arise from using mod_perl.

Comment on Re: More than mod_cgi less than mod_perl.

Replies are listed 'Best First'.
Re^2: More than mod_cgi less than mod_perl. by Joost (Canon) on Jun 07, 2005 at 12:46 UTC
A possible way to do what you want may be to have a 'cgi-server' wrapped around all cgi-scripts, and have Apache pass all request to this other process. This sounds very similar to fast-cgi. (Caveat: I've never used it, but I've heared good things about it.) update: url. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^2: More than mod_cgi less than mod_perl. by cees (Curate) on Jun 07, 2005 at 13:06 UTC
A possible way to do what you want may be to have a 'cgi-server' wrapped around all cgi-scripts, and have Apache pass all request to this other process. This would only require ProxyPass'ing from Apache, and a simple server-wrapper around the cgi scripts. In fact, I can't imagine such a wrapper doesn't exist yet. It does exist. Look at my response below about PersistentPerl. Fast CGI is another option (like Joost mentions), but I believe that you have to change your code for it to work. Although it is probably trivial to do so.	[reply]
Re^3: More than mod_cgi less than mod_perl. by Anonymous Monk on Jun 07, 2005 at 13:57 UTC
A little OT, but PersistentPerl does not support Win32 I believe. I also couldn't use Fast CGI on IIS. And all two seems to be dead: FastCGI last release: 2003 PersistentPerl last release: 2003	[reply]
Re^4: More than mod_cgi less than mod_perl. by Hero Zzyzzx (Curate) on Jun 07, 2005 at 15:19 UTC
I wouldn't say that FastCGI is dead. Stable, yes. Dead, no. It's been working beautifully on my Debian boxes for years, and is still supported in the new Sarge that was just released. I believe the burgeoning Ruby on Rails community is picking it up, too, as one of the persistent mechanisms of choice. It just works, and darn well I might add. One particularly thorny problem it helped me solve recently- I provide "boutique" hosting services for a rather large perl-based CMS that's under heavy development. I have clients that are on the stable branch and are happy where they are at, and clients that want to run the development "bleeding edge" branch. mod_perl makes this difficult because of namespace clashes, while with FastCGI I can run multiple long-running "instance scripts" and everything just works. And nicely, too. You do lose the direct integration with the Apache API (I love mod_perl), but FastCGI is a very nice alternative persistent environment that's language independent. -Any sufficiently advanced technology is indistinguishable from doubletalk. My Biz	[reply]
Re^5: More than mod_cgi less than mod_perl. by smullis (Pilgrim) on Jun 08, 2005 at 08:54 UTC
Re^4: More than mod_cgi less than mod_perl. by cees (Curate) on Jun 07, 2005 at 15:36 UTC
Perhaps that just means that they have both already reached perfection ;) Seriously though, FastCGI is a very mature technology, so I can understand why development may have stopped. After all, when was the last time Apache made any changes to the way CGI works? As for PersistentPerl, there is only one registered bug with the project on RT, and it is platform dependant (OSX), and includes a proposed fix. Really, there are lots of perl modules that haven't had an upgrade in ages that are still relevant. How long did Apache::Session go without an update? HTML::Template has only had one release in the last 3 years and it is still very heavily used. I'm sure there are many others...	[reply]
Re^2: More than mod_cgi less than mod_perl. by techcode (Hermit) on Jun 07, 2005 at 20:09 UTC
OK. My bad. I tougth that it's clear that I'm trying to improve only Perl's performance. Of course if other languages benefit - it's even better. And how about adding functionality to perl, so that it cleans up memory before next run, on itself. Correct me if I'm wrong, but such function must be in perl allready and is curently called before it exits. Altho would probably need minor modifications. Not counting	[reply]
Re^3: More than mod_cgi less than mod_perl. by Gilimanjaro (Hermit) on Jun 07, 2005 at 22:00 UTC
The memory cleanup on perl's exit, is a whole other type of cleanup I'm afraid. Perl allocates a bunch of memory from the OS, but the problem is in how it uses this memory itself. The memory is returned to the OS at perl exit offcourse. Doing the same kind of cleanup without exiting perl would probably not be a trivial change to perl. Just an example of a problem you'd encounter would be how to handle the special global variables that are linked to the perl parameters from the shebang (#!) line... A bigger problem though, would be that cleaning up all of the memory would mean all modules would have to be reloaded too, and the module loading and initialisation is often even slower then the perl interpreter loading... As a perl module can change variables in any namespace, so we can't just clear the part of the namespace it's using, and keep it loaded. There is just no proper way to 'reset' a running perl to initial state. The 'flow' of compilation can change, because of the existence of stuff like BEGIN blocks, so the line between compilation time and runtime can get blurry. This makes resetting perls internal state even harder... It's for these reasons that mod_perl has the complexity is has, and that the programmer needs to be aware of the persistent behaviour some variables may exhibit. There's just no way around it I'm afraid... Not without removing a ton of functionality from perl itself, which in turn would break half the modules out there that people are using. It's a hard subject to explain without getting into deep technical detail, but I hope I've hinted in the right direction...	[reply]
Re^4: More than mod_cgi less than mod_perl. by techcode (Hermit) on Jun 07, 2005 at 22:28 UTC
I know that perl's exit cleanup is another type of clean up. And of course built in/special variables would need to been take care of. I still belive that it wouldn't be that difficult to do this. Altho BEGIN/END blocks do raise some questions ... Still, I believe that doing everything that is usually done on each CGI request, except reloading perl itself will give a boost. Question is will that be enough faster to bother with it? Anyway, if FastCGI is the solution then why aren't all hosting's using it (instead of using mod_cgi and whatever other web servers have for CGI)?	[reply]


Problems? Is your data what you think it is?
	PerlMonks

Re: More than mod_cgi less than mod_perl.