From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id E52D8BBAF for ; Mon, 26 Jul 2010 14:59:05 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUGADcjTUxQW+UMgWdsb2JhbACSazCMRxUBARYiIsBihTYEh1OBEQ X-IronPort-AV: E=Sophos;i="4.55,261,1278280800"; d="scan'208";a="56132875" Received: from lo.gmane.org ([80.91.229.12]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Jul 2010 14:59:05 +0200 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OdNGp-0007iA-63 for caml-list@inria.fr; Mon, 26 Jul 2010 14:59:03 +0200 Received: from ks368928.kimsufi.com ([94.23.39.26]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Jul 2010 14:59:03 +0200 Received: from sylvain by ks368928.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Jul 2010 14:59:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: scalable web apps Date: Mon, 26 Jul 2010 12:58:53 +0000 (UTC) Message-ID: References: <442805.67917.qm@web111502.mail.gq1.yahoo.com> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ks368928.kimsufi.com User-Agent: slrn/pre1.0.0-11 (Linux) X-Spam: no; 0.00; le-gall:01 scalable:01 non-blocking:01 ocaml:01 buffered:01 wrote:01 unix:01 tar:01 tar:01 kernel:02 tend:03 static:03 apps:04 guess:04 problem:05 On 26-07-2010, Dario Teixeira wrote: > Hi, > >> I am creating an application with ocsigen that requires to serve a lot >> of .tar.gz as static contents. >> >> Do you think the "no Unix supports non-blocking mode" will cause problem >> in this case? > > I presume that application is related to the Oasis-DB initiative, right? You guess right ;-) > I wouldn't worry too much in that case. First, because the Ocaml community > is not that big (yet) as to cause such heavy traffic. Second, because > the set of tar.gz files is not that great (a few hundred, max?) and those > files will tend to be small. If your server has enough memory, there's a > good chance many of the file blocks requested will eventually be buffered > in memory by the kernel, thus minimising expensive disc I/O. > There is indeed a good chance that the files end up in memory. Thank you for your remarks. Regards, Sylvain Le Gall