On Sun, Oct 24, 2010 at 01:54:50PM -0700, Anil Madhavapeddy wrote:
>    This should work fine for a couple of thousand clients or so, but you'll
>    begin to see degradation as the number of clients increase. This is
>    because LWT internally uses select(2) to wait for file-descriptors, and
>    not the newer kqueue(2) or epoll(2) interfaces. You can read more about
>    the "C10K problem" here: [3]http://www.kegel.com/c10k.html
>    I've got a stripped-down version of LWT that uses these newer event-driven
>    kernel interfaces (and so should be able to cross the 10,000 client
>    barrier fairly easily), but it won't be ready for release for another
>    month or so.  Drop me an email off-list if you want to try it out earlier.

I made an implementation of lwt using libev [1]. I tested it with
ocsigen and ab but the result was always a bit better with select than
with epoll. That is why i did not replace select by libev in the main
branch. In fact i never found the source of any benchmark comparing
select to epoll on the web.

>    Async disk I/O under Linux is annoyingly problematic if you aren't using
>    direct I/O (and hence page/block-aligned structures). Avoid if possible :)

The next version of Lwt will support asynchronous disk I/O by using
mincore + mmap. It is already in the development version.

Jérémie

  [1] http://www.dimino.org/cgi-bin/darcsweb.cgi?r=lwt-libev;a=summary