Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EF57A10FAC for ; Fri, 4 Apr 2014 12:56:49 +0000 (UTC) Received: (qmail 86008 invoked by uid 500); 4 Apr 2014 12:56:47 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 85568 invoked by uid 500); 4 Apr 2014 12:56:46 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 85560 invoked by uid 99); 4 Apr 2014 12:56:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Apr 2014 12:56:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.219.42] (HELO mail-oa0-f42.google.com) (209.85.219.42) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Apr 2014 12:56:39 +0000 Received: by mail-oa0-f42.google.com with SMTP id i4so3520127oah.29 for ; Fri, 04 Apr 2014 05:56:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=NzVhwAQUJgqQHkg6uy9TONqPhfjkzqKhrQ5nUMojqrA=; b=PkrMGova4QiHmWE46vtxk49Ip2TWZn+EAr+//eyy3xAXPyn/8UYt4kU1yp6P5HvMoT EgA4xP1T9u7/OtuFghKhdQBRstbGl4jC3OCPBXDr0xx7QGbsJR9a9fEL0vDxpgmZlH+5 G6CMd/APcSd8bySwAD03vzdXD8wO0au5cjM04XZXu83axlK97TTT8SO5QcUCwFV53Tb2 u+1UmqVD10b+16iVY1Lar90hTQG0eqSLAiID9dLPW9JL4ywWoqqZPoyGbFrTjNcVmK4T rR8R29TK+vMiDgxnYp5/+3i0CY/8ZJI/BwAlcApEfd9Mq3iK+xS5WN2DtqhzTjX3LLk3 0eCQ== X-Gm-Message-State: ALoCoQl1GQtKLaszYfP01sQbRL/odyTLLU8T5OA3WSe+b4z9pA2CtlmVlEgg2ajtAq4IZ3Qmiu4P MIME-Version: 1.0 X-Received: by 10.60.77.35 with SMTP id p3mr4072681oew.46.1396616178804; Fri, 04 Apr 2014 05:56:18 -0700 (PDT) Received: by 10.182.3.169 with HTTP; Fri, 4 Apr 2014 05:56:18 -0700 (PDT) X-Originating-IP: [37.197.123.183] In-Reply-To: References: Date: Fri, 4 Apr 2014 14:56:18 +0200 Message-ID: Subject: Re: Bench marking a simple 10k write From: Daniel Wertheim To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=047d7b33d24439ba4004f6370b99 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b33d24439ba4004f6370b99 Content-Type: text/plain; charset=ISO-8859-1 Just did some measurements in .Net using MyCouch. If I create a new client each time, with no bulk and no batch for 10k I get 25s and not 40s. That's a default, local install of CouchDb 1.5 on Windows 8.1 i7 quad core, 8GB RAM 64bit, running a simple release compiled console app. New Db was created for each lap. Note! I did not use the async behaviors of MyCouch, I awaited each PUT. Hence, if you tweak the ServicePointManager.DefaultConnectionLimit ( http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.defaultconnectionlimit.aspx) and allow async requests...... Did this using PUT so I generate the id (simple running int). One PUT was executed as first to get "Warmup" behavior. Cheers, //Daniel ========================== Using same Client no bulk and no batch ========================== Total timings: 10000 Total (ms): 20886,0011000001 Avg (ms): 2,08860011000001 ========================== Using NEW Client no bulk and no batch Also timing the time it takes to construct the client ========================== Total timings: 10000 Total (ms): 25062,9446000001 Avg (ms): 2,50629446000001 ========================== Using same Client with batch ========================== Total timings: 10000 Total (ms): 9909,26200000002 Avg (ms): 0,990926200000002 ========================== Using NEW Client with batch Also timing the time it takes to construct the client ========================== Total timings: 10000 Total (ms): 13414,0004 Avg (ms): 1,34140004 ========================== Using same Client with bulk of 100 in each ========================== Total timings: 100 Total (ms): 2259,0868 Avg (ms): 22,590868 ========================== Using NEW Client with bulk of 100 in each Also timing the time it takes to construct the client ========================== Total timings: 100 Total (ms): 2430,1235 Avg (ms): 24,301235 On 4 April 2014 12:41, Knudsen, Ken wrote: > Thanks for the comments guys, I appreciate it. I understand to use > Bulk-Import, I've done my reading (just in case you think I'm being lazy :) > ) ... what I'm trying to run tests for (get some numbers, throw them into a > chart), a persons current thinking pattern, is someone high up that's > either had a bad experience with the early days of NoSQL (MongoDB to be > exact)...and because of this, is dead set against the whole word 'NoSQL'... > at that level, charts and numbers is all they pay attention too. So I'm > just trying to put together an enlightening sea of pictures that will show > that's not the case. I know it's not the case. > > The micro tests are just one set of the pictures.. I do have a full TSung > test bed happening as well... A simple rest service with a few methods... > Each testing 1 call to their respective database (SQL, ArangoDB, CouchDB, > MongoDB)...Then in TSung I setup a test client to make 10k iteration of > calls to the REST service (simple initial setup, 1 user)...where each call > inserts 1 document...Now, under this senario, the SQL Server comes in > last....It takes 2.33 mins to execute 10k of calls. CouchDB takes less then > a minute and ArangoDB comes in at about 33 seconds. I find it interesting > as a more real distributed test bed is put into play, that the power of the > NoSQL databases start to come alive. > > thanks again! > > Ken > ________________________________________ > From: Stanley Iriele [siriele2x3@gmail.com] > Sent: Friday, April 04, 2014 6:23 AM > To: user@couchdb.apache.org > Subject: Re: Bench marking a simple 10k write > > I believe most clients use keep alive by default but what I'm saying is > that he's running the test in nunit (to my understanding) of its in the > same loop or whatever then it should be using keep alive...but the nunits > tear down the class and its resources per run. So even if the default > library uses keep a lives its still freshly created each time > On Apr 4, 2014 2:37 AM, "Nick North" wrote: > > > On second thoughts, while my previous claim is true, I'm not sure what > > happens when you use WebRequest.Create for each write, as in the example. > > So maybe keep-alive is not enabled after all. > > > > Nick > > > > > > On 4 April 2014 10:35, Nick North wrote: > > > > > The HttpWebRequest class has a KeepAlive > > > < > > > http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.keepalive.aspx > > >property > > > that defaults to true under HTTP 1.1, so it should be enabled in the > OP's > > > example. > > > > > > Nick > > > > > > > > > On 4 April 2014 10:24, Stanley Iriele wrote: > > > > > >> On Fri, Apr 4, 2014 at 1:28 AM, Benoit Chesneau > > >> wrote: > > >> > > >> > On Fri, Apr 4, 2014 at 10:25 AM, Will Holley > > >> wrote: > > >> > > > >> > > .NET should set keep-alive by default. > > >> > > > > >> > > > >> > > >> I have a hard time believing that because its the library you're using > > not > > >> NET itself that decides that. Also If the test is truly being torn > down > > >> rerun I don't see how it could use keep-alives...that would invalidate > > the > > >> test wouldn't it? being that the 1st test makes a connection and > > >> subsequent > > >> tests reuse the same connection > > >> > > > > > > > > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > --047d7b33d24439ba4004f6370b99--