OK, this is about the 6th or 7th time I've said this and STILL people are
ignoring it.
Your whole argument is based on a flawed premise: that with CGI, a new
process must be started for each request. This is plain and simply NOT
correct. I have pointed this out time and time again.
Any benchmarks comparing Java to this sort of thing are misleading at best,
and more likely downright incorrect.
If people want to discuss the performance of mod_perl or FastCGI vs.
servelts, please do so. But please cease this misleading practice of
comparing current Java to outdated Perl.
In <[EMAIL PROTECTED]>, I wrote:
I keep saying this and apparently nobody is listening.
Let me give you URLs then:
http://www.apache.org/related_projects.html#modperl
"With mod_perl it is possible to write Apache modules entirely in Perl.
In addition, the PERSISTENT interpreter embedded in the server avoids
the overhead of starting an external interpreter and the penalty of
Perl start-up time." (emphasis mine)
http://fastcgi.idle.com/fcgi-devkit-2.1/doc/fastcgi-whitepaper/fastcgi.htm
"FastCGI processes are persistent: after finishing a request, they wait
for a new request instead of exiting."
"FastCGI . . . multiplexes the environment information . . . [allowing]
FastCGI programs to run on remote machines"
On Wed, Feb 17, 1999 at 11:10:12AM -0700, Jeff Galyan wrote:
> When a webserver (let's say Apache) gets a request from a client to run
> a traditional CGI, the server spawns a new process *independent* of
> itself. If the process is a Perl process, then it has the overhead of
> initialization, reading in the file, parsing, etc. *before* it can do
> anything useful to the end user.
Not if using mod_perl or FastCGI, as I have kept saying. As the rest of
your post relies on this flawed assumption, there isn't much else to say.
