Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Web Development with OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alexander V. Voinov <avv@q...>
Subject: Re: [Caml-list] Web Development with OCaml
Hi

Jimmie Houchin wrote:
> The speed and memory results in the shootout are amazing. But what compounds
> it is the LOC result. To me that indicates that a language does not have to be
> verbose to be fast.
...
> Currently fast web servers like Tux 10-15,000+ rps (requests per second),
> Apache 2-4,000 rps aren't dynamic (at those speeds). Dynamic website tools
> like Zope, etc are either like 20-80 rps or some I've seen up to 100-200 rps.
> This is a great disparity.
> 
> I want a dynamic website which gets as close to static speeds as possible.

> 3. Tux module. Create an OCaml user space module for Tux.
>       This would be interesting and would probably be very fast.
>       This is also beyond my skill.

I'd like to seriously wonder about the impact of garbage collection in
such a persistent module, which has to reclaim stuff time to time. And
given that there will be many linked (recursive) data structures, the
process of reclaiming would take time. Unless it may be run as a
separate thread on a separate CPU, and the process of getting space for
new stuff doesn't heavily depend on the collection of the old one (say,
when it's not a problem to malloc one more gig). My suspicion is that
the currently widely discussed shootout doesn't catch the effect of GC.

With all this I mean that you are to maintain a kind of _conceptual_
cache in your dynamic server, like filesystem cache serves for static
pages you mentioned, otherwise it would be little point to apply the
strength of FP. Say, if you store your stuff just in a database, and use
some WebDB, or so, you do not have to bother about FP. (But it all is
complete IMHO)

Alexander
-------------------
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