On Mon, Dec 20, 2010 at 2:41 PM, Brian Mitchell <[email protected]> wrote:
[snip] > > You did all I can ask for in the sense of constructive response... though I > do think the CouchDB community seems shy on providing people with simple > ranges of data to help them decide to invest time into more refined > measurement. > > The truth is that couchdb does have it's strengths that don't tend to show > well in many cases. On the other hand, some applications do need performance > numbers that don't easily come from a standard couched setup. Knowing this > before diving into dangerous comparisons will help avoid the awkwardness as > people try to measure things that don't really represent the priorities of a > project well. Right now you have to dig deeper than most people will ever > look to find these numbers. They are hidden whether that is done > intentionally or not. > > I'd think that it'd be in the community's favor to be as clear as possible > with what kind of ballpark the DB is in. People who miss out on the great > parts of CouchDB because they only focus on speed (so they chose something > else) are probably not the prime targets of this project anyway. If people > here disagree, then some serious work needs to be done on improving these > numbers (IMO, there is a lot of speed to gain). > I think the performance question is a good one. It's hard to answer because we've seen so many different performance #s depending on workload. As far as rough #s, this bash script inserts about 2500 documents a second into CouchDB on my MacBook Air. https://github.com/apache/couchdb/blob/trunk/test/bench/benchbulk.sh Generally the question that tends to matter is: Can view generation keep up with inserts, on average? Once the index is built, responses to it are fast, so the index build time matters. On desktop-class hardware, I tend to expect between 500-1000 documents per second can be processed (for documents about as complex and large as a tweet). Of course this # will vary widely depending on hardware and the # of keys you emit. BigCouch also makes partitioning this view generation load easier, so that more of the mapping can be done in parallel. Chris > Brian. > > -- Chris Anderson http://jchrisa.net http://couch.io
