couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <si...@cloudant.com>
Subject Re: All The Numbers -- View Engine Performance Benchmarks
Date Sun, 27 Jan 2013 17:55:41 GMT
Science! 


On Sunday, 27 January 2013 at 18:42, Russell Branca wrote:

> On Sun, Jan 27, 2013 at 4:50 AM, Jan Lehnardt <jan@apache.org> wrote:
> 
> > 
> > On Jan 27, 2013, at 13:22 , Alexander Shorin <kxepal@gmail.com> wrote:
> > 
> > > On Sun, Jan 27, 2013 at 3:55 PM, Jason Smith <jhs@iriscouch.com> wrote:
> > > > 
> > > > * Very little difference in different implementations (because stdio is
> > the
> > > > bottleneck)
> > > 
> > > 
> > > Why stdio is a bottleneck? I'm interesting underlay reasons.
> > 
> > It is actually not the the stdio, but the serialisation form erlang-terms
> > to JSON to JS Objects to JSON to erlang terms.
> > 
> > Cheers
> > Jan
> > --
> > 
> 
> Yeah serialization overhead is the main reason I wanted to do "end to end"
> performance tests, as I truly am curious whether native view engines are
> strictly faster, or faster for docs once they reach a certain size or
> something else entirely.
> 
> My prediction is that bulk processing of views (whenever that gets added)
> will be an order of magnitude faster than the current system and make most
> of these comparison benchmarks irrelevant, but we should at least get that
> data together first.
> 
> 
> -Russell
> 
> 
> > 
> > > 
> > > As for my experience, the protocol design doesn't allows view and
> > > query servers works faster as they can. For example, we have 50 ddocs
> > > with validate functions. For each document save there would be
> > > executed from 100 commands (50 resets + 50 ddoc validate_doc_update
> > > calls) till 150 commands (+ddocs caches), while it's possible to
> > > process them in bulk mode.
> > > 
> > > --
> > > ,,,^..^,,,
> > > 
> > 
> > 
> 
> 
> 



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