Re: more web server perfomance stats

[Nathan Schrenk <ns...@neog.com>]

On Wed, 17 Jan 1996, Dirk.vanGulik wrote:

[cgi-pipe info removed]

> The trouble is I am not sure how to build such constand
> backend pipes to apache in a neat way. I know what I want
> but it has some thinking to go.
> 
> But I am sure other people have been doing the same thing.

We've developed some software here that sounds conceptually similar, but
we're using Java where you're using perl.  We have a server daemon written
in Java that sits on the webserver and accepts connections.  This Java
server gets input (what class to load, encoded CGI input, a blob of
environment-type data) from an Apache module that connects to it, and then
uses a hacked up class loader to load the appropriate class.  The server 
then starts up a new thread with this class, and hands it the input, and 
shuttles whatever output it generates back to Apache.  This is basically 
just a replacement for CGI.  We are very interested in performance, and 
wanted to use Java, but the two don't easily mesh.  

If you have to run a Java interpreter/virtual machine each time you run a
Java program, you're wasting a lot of resources and it doesn't make sense
in a CGI-ish application where you are frequently running a lot of little
programs which start up, do a little work, and then die.  We think we can
eliminate most of the overhead by using this Java server daemon that runs
all the classes with a single Java interpreter which is running all the
time. 

This is all well and good, but we haven't sat down and figured out how to
integrate this into Apache's security model.  Right now our class loader
just searches its CLASSPATH, loads classes, and runs them and theres no
real security built into the Java class server.  Since the classes don't 
refer to any real file system object in our current module (the module
looks at the URI to determine when a Java class is being requested) 
the existing security mechanisms that are based on the filesystem won't 
apply.  

One way to work this out is to have dummy text files under the document 
tree that have some identifying extension (in our case, maybe .ssj for 
'server side Java' or something similar) which the module would 
understand and which might even contain some info about how the class was 
to be executed.

Any thoughts?

Nathan

> Dw.

--
Nathan Schrenk						nschrenk@neog.com
Neoglyphics Media Corp.                              http://www.neog.com/