From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 24132BBC1 for ; Wed, 13 Feb 2008 16:29:36 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAE+bskfAXQInh2dsb2JhbACBWY5kAQEBCAopnGY X-IronPort-AV: E=Sophos;i="4.25,346,1199660400"; d="scan'208";a="8029787" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 13 Feb 2008 16:29:35 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m1DFTWk4020441 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 13 Feb 2008 16:29:35 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAKcskfU436xnmdsb2JhbACBWY5kAQEBAQEGBAYHChicbA X-IronPort-AV: E=Sophos;i="4.25,346,1199660400"; d="scan'208";a="9145494" Received: from moutng.kundenserver.de ([212.227.126.177]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 Feb 2008 16:29:35 +0100 Received: from gate.lan.gerd-stolpmann.de (dslb-088-068-195-228.pools.arcor-ip.net [88.68.195.228]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1JPJXu1LQg-0006cn; Wed, 13 Feb 2008 16:29:15 +0100 Received: from gps.dynxs.de (localhost [127.0.0.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 10136C12A; Wed, 13 Feb 2008 16:29:14 +0100 (CET) Received: from 192.168.1.2 (proxying for 66.134.141.179) (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Wed, 13 Feb 2008 16:29:14 +0100 (CET) Message-ID: <4105.192.168.1.2.1202916554.squirrel@gps.dynxs.de> In-Reply-To: <1202732562.25701.11.camel@andre.mz.digirati.com.br> References: <1202732562.25701.11.camel@andre.mz.digirati.com.br> Date: Wed, 13 Feb 2008 16:29:14 +0100 (CET) Subject: Re: [Ocamlnet-devel] Nethttpd_plex performance question From: "Gerd Stolpmann" To: "Andre Nathan" Cc: ocamlnet-devel@lists.sourceforge.net, caml-list@inria.fr User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V01U2FsdGVkX1/iWOOJFE0nNd5fu2a0h/qvDOW7/mDBXvjiQE1 zdwhcJsidGWEn0U91ADxodGf0Th/UBT5yMp7qz0okj/Knq3bYx /RAJHSFFA/iLnzpJ87AjtblygHhLbwN X-Miltered: at concorde with ID 47B30CDC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 computations:01 model:01 model:01 gerd:01 ocamlnet:01 workload:01 workload:01 stolpmann:01 viktoriastr:01 64293:01 darmstadt:01 plex:98 nathan:98 Hi Andre, the results are more or less what I would expect. For cached static pages there is no advantage of using multiple processes. Nethttpd has the built= -in capability of handling serveral connecrtions in parallel, so easy_daemon already profits from that. As the static pages need not to be loaded from anywhere, and there are no other complex computations either, easy_daemon runs under optimal conditions. Using multiple processes implies a lot of additional overhead. I don=B4t mean the time for creating processes (which is hidden from the user in the prefork model), but there is some extra communication for coordinating the processes. Generally, the multi-process model has advantages only if either - there is some wait time until the web page is available, such as loading it from disk or requesting it from some background service - you need some CPU time to compute the pages, and you have several CPU=B4s - you need some CPU time, and you want to minimize latencies (even on a 1-CPU box) - your program is a bit instable - crashing a sinegle process does not stop the whole service As you have figured out, measuring performance is more difficult for a multi-process server. This has mostly to do with the varying startup time until all processes are created. The longer the benchmark the better, and you will see stabler numbers. 600 qps roughly matches what I measured a few months ago. I hope this helps, Gerd Andre Nathan said: > Hello > > I'm trying to write a simple webserver using Nethttpd_plex from the > ocamlnet package. I did a simple benchmark using the examples provided > in the distribution (easy_daemon.ml and netplex.ml). Both examples > create static pages, but the netplex version shows worse performance, > which I think is odd because it uses a multi-process model, while > easy_damon is a single process handling all requests. > > I'm running "ab" (apache's benchmark tool), doing 1,000 connections, 10= 0 > concurrently. Here are the results: > > - easy_daemon: > Requests per second: 1699.87 [#/sec] (mean) > > - netplex: > Requests per second: 591.22 [#/sec] (mean) > > [netplex's results actually vary a lot, sometimes reaching about 1,000 > req/s but sometimes also being as low as 300 req/s. On average it seems > to be around 600 req/s] > > I'm using the following configuration for netplex's workload_manager: > > workload_manager { > type =3D "dynamic"; > max_jobs_per_thread =3D 1; > min_free_jobs_capacity =3D 30; > max_free_jobs_capacity =3D 50; > max_threads =3D 256; > }; > > Does anyone have any tips for improving netplex's performance? I believ= e > that with the right settings it should be able to outperform the simple= r > daemon easily, since it's using multiple processes. > > I hope this question is appropriate for the list. > > Thanks in advance, > Andre > > > -----------------------------------------------------------------------= -- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ocamlnet-devel mailing list > Ocamlnet-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ocamlnet-devel > > ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------