couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wertheim <dan...@wertheim.se>
Subject Re: Bench marking a simple 10k write
Date Fri, 04 Apr 2014 12:56:18 GMT
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
<Ken.Knudsen@imaginecommunications.com>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" <north.n@gmail.com> 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 <north.n@gmail.com> 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 <siriele2x3@gmail.com> wrote:
> > >
> > >> On Fri, Apr 4, 2014 at 1:28 AM, Benoit Chesneau <bchesneau@gmail.com>
> > >> wrote:
> > >>
> > >> > On Fri, Apr 4, 2014 at 10:25 AM, Will Holley <willholley@gmail.com>
> > >> 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
> ______________________________________________________________________
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message