Skip to main content.
home | support | download

Back to List Archive

Re: Running swish with mod_perl

From: Bill Moseley <moseley(at)not-real.hank.org>
Date: Thu May 02 2002 - 16:51:15 GMT
At 01:22 AM 05/02/02 -0700, Alex Lyonswrote:
>Interesting.
>
>You appear to be comparing:
>
>1. Perl CGI forking swish-e
>
>2. Perl CGI using SWISHE perl library
>
>3. mod_perl handler ???
>
>Does the mod_perl handler fork swish-e or is it using the SWISHE perl 
>library?

Yes, sorry, the mod_perl handler uses the library.  I was initially testing
the library yesterday to see if I could reproduce the segfaults that David
Vermooten is seeing.  The benchmarking was a fun diversion.  I wouldn't
trust benchmarks much, though.

>For completeness you probably ought to compare both, as in the 
>mod_perl case the difference between forking or using the library would 
>show up more as they wouldn't be swamped by the overheads of forking the 
>CGI process and starting up perl.

Right.  Here's a mod_perl handler that forks swish:

  Requests per second:    17.94

Again, running the mod_perl handler with the library I see:

  Requests per second:    160.26

Now, here's another configuration.  The mod_perl handler using the swish
library, but *not* caching the swish "handle" between requests:

  Requests per second:    19.82

That's the overhead of opening the index file for each request.  

>I tend to run my perl CGI stuff as FastCGI rather than mod_perl, so the 
>extra memory required for the SWISHE perl library is less of an issue as 
>it doesn't get loaded into all the httpd processes.

Doesn't the memory just get shifted to the backend processes?  Kind of like
using the standard config of a proxy in front of mod_perl?  Or am I mixing
that up with SpeedyCGI?

I get lost keeping track of the differences between FastCGI, PPerl,
SpeedyCGI, VelociGen, mod_perl and all the rest.  What mod_perl brings
along with fast content is easy access to all the other request phases.  I
kind of feel like the memory issues are not issues unless you run out...

Another plus for not having swish in Apache is that an error in swish won't
bring down the web server.   I'm not sure how big of an issue that is,
since an error in swish means a failed request regardless -- is it better
(from the users standpoint) for the connection to just die or do you want
an error page returned?


>The main advantage 
>of the SWISHE library as I see it isn't whether it's faster or slower 
>than forking, but rather the potential for cross-platform independence: 
>there have been a number of mailings to this list on problems with 
>security of forking on Windows (where I believe it uses a shell) and 
>difficulties in identifying pathname component delimeters as they get 
>passed through the aforesaid shell on various dialects of Windows.  I 
>presume these problems would be avoided by not forking.

Swish was originally designed run as a separate program.  The library was
added not too long ago.  An issue with the library is that an error can
happen and swish will call exit().  If it's embedded in Apache there goes
that process.  For example, I think with the library if you pass in an
invalid index file name it will do this.  Just more todo items.  Patches
welcome.


-- 
Bill Moseley
mailto:moseley@hank.org
Received on Thu May 2 16:51:18 2002