From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA08827; Sun, 15 Jul 2001 22:19:34 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA08678 for ; Sun, 15 Jul 2001 22:19:33 +0200 (MET DST) Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6FKJXf06630 for ; Sun, 15 Jul 2001 22:19:33 +0200 (MET DST) Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15LsMX-0002Wh-00; Sun, 15 Jul 2001 22:19:33 +0200 Received: from drms-3e357838.pool.mediaways.net ([62.53.120.56] helo=ice.gerd-stolpmann.de) by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2) id 15LsMV-00001S-00; Sun, 15 Jul 2001 22:19:31 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.gerd-stolpmann.de (8.9.3/8.9.3) id WAA16878; Sun, 15 Jul 2001 22:19:25 +0200 From: Gerd Stolpmann Reply-To: info@gerd-stolpmann.de Organization: privat To: Caml list , web-caml@quatramaran.ens.fr Subject: Re: [Caml-list] Web Development with OCaml Date: Sun, 15 Jul 2001 22:19:15 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <20010713160428.A9419@pauillac.inria.fr> <20010715140351.B20044@andrew.cmu.edu> In-Reply-To: <20010715140351.B20044@andrew.cmu.edu> MIME-Version: 1.0 Message-Id: <0107152218191B.00523@ice> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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