Re: [Caml-list] Web Development with OCaml

[Gerd Stolpmann <info@gerd-stolpmann.de>]

On Sun, 15 Jul 2001, Ari Heitner wrote:
>[apologies to all, i should let sleepng dogs lie. but hey, i go to cmu,
>where John Harper gives 15-312 exam questions about java braindamage]
>
>> 
>> Second, you (and others) seem to take for granted that a "servlet
>> container" must load servlets dynamically into its own memory image.
>> That's the Java way, but again that's not the only way.  Using
>> separate processes for the HTTP server/servlet container and for the
>> servlets (but not starting a new servlet process on each request like
>> CGI does) might very well work better: I'll bet the performance hit
>> would be insignificant, and you get a clean, well-specified
>> communication protocol between server and servlets.
>
>Aha! the real point.
>
>CGIs roll over when people keep hitting the system, and apache (not fast in
>the first place) croaks as it spawns a new process for every request -- the
>system rapidly has too many processes, and swaps itself to death.

Don't be so unfair. Native-code CGIs are relatively fast. Unix has been
optimized for starting new processes very quickly. Of course, this is only true
if most of the process image is read-only, so the image can be shared by
several processes (my argument doesn't apply to all interpreter languages
which load the code into read-write sections). I have seen expensive SMP
systems that most of their time compile Perl programs. I have also done some
experiments with native-code O'Caml programs called as CGIs, and this is _much_
faster. (I've just done some simple benchmarks: a 500k executable that queries
the state of a daemon and prints it as HTML page, it runs with 40 requests per
second, and the CPU is still 50% idle (I think it's slowed down by the query,
and my benchmark is too stupid). Not bad for a simple technique like CGI.)

Okay, if there are too many processes, the hardware will become too ineffective
(too many cache misses). But this is also true for threads.

>The sane thing to do seems to be to have only a few more processes than
>CPUs, and drive those processes has hard as possible with async io. There's
>no strong reason to make either your httpd or your database process even
>multithreaded...

Most multithreading programs aren't so stupid that they create a new thread for
every request. There is usually a pool of waiting threads that are
activated when new requests arrive. If there are more requests than threads,
the requests must wait.

Because of this, I see no fundamental difference between multi-process and
multi-threaded programs. You can implement the "workers" that wait for requests
both as threads or as processes. However, the communication between threads
is simpler than between processes. (On the other hand, it is possible to
restart hanging processes which is not possible with threads.)

>that aside, using java just to get around switching to a new version of the
>servlet without downing the server is even worse -- just bloody use
>dlopen...

But dlopen is not available for caml (it is not possible to create PIC). I
would suggest to implement the pool of workers as pool of processes (to get
most out of SMP boxes) that can be dynamically changed without breaking the
service. There could be one "master process" knowing which workers are
available and for which tasks they are programmed. The master process assigns
the requests to the workers. (The master process should be as lightweight as
possible, perhaps not even a process.)

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr