On Dec 20, 2010, at 17:19, Jan Lehnardt <[email protected]> wrote:
> Hi Brian, > > On 20 Dec 2010, at 23:08, Jan Lehnardt wrote: > >> On 20 Dec 2010, at 23:05, Brian Mitchell wrote: >> >>> I have verified that CouchDB users love URLs but don't tend to read them >>> because their database is too slow. >>> >>> (Joking aside, I find it annoying that people can't ever manage to answer >>> things without storming off and writing long blog posts on methods of >>> measurement or simply never actually answering things with any more >>> substance than the things they seem to attack as poor evidence. I do >>> realize there is a large gap here and apples vs. oranges isn't productive, >>> but neither is this.) >> >> +1 > > Paul on IRC reminds me that this might have been target at me, funny :) I saw your reply after I hit send. :-) Paul's response was funny but I've seen this go down too many times not to let a short little rant out. > The blog posts are for background which is generally lacking as these > benchmarks keep coming up. I did point out why this is a bad scenario for > CouchDB and offered an explanation of better scenarios, but I can't go and > define your scenario because, well, it's yours. That is the whole point of my > stupid benchmarks are stupid argument. > > I also did offer more information if requested and I am happy to go into the > details of why CouchDB performs better under concurrent load if requested. If > you are requesting that, can you formulate a question? :) 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). Brian.
