I have been putting together some stuff that seems pertinent to this discussion.
I'm working on a performance suite that tests a variety of concurrent performance scenarios. I have the client code written but I'm still working on the automated build/test code. Once that is finished I plan to do some GitHub integration and some charting. The idea here is to chart the performance differences between a GitHub branch at a certain commit compared to the performance of the latest release and the latest trunk. If someone has an idea of how they might increase performance they could point this tool at their GitHub branch and reference the differences in performance between their code and the latest release and trunk. I'll send another email once i have some pretty graphs to show off :) -Mikeal On Wed, Jan 13, 2010 at 5:19 PM, Damien Katz <dam...@apache.org> wrote: > > On Jan 13, 2010, at 3:37 PM, Roger Binns wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Chris Anderson wrote: > >>> The ticketing system should be for smaller scope issues, I think. > > > > I see it more as a "don't forget about this" plus somewhere for others to > > say "this also affects me" or "here is additional information/angles". > > Obviously there is a fine line between that kind of thing and a > discussion. > > My big concern is that the issue was hashed out here over a few days then > > the thread goes dead, and the issue is forgotten. A JIRA report of open > > issues should be a todo list of bugs to fix and improvements to make. > > That's fine, the issue is that bugs saying "It's too slow" is always true > for someone. Many people find the view indexing performance just fine, many > do not. > > Since CouchDB makes no performance or size guarantees, you can't call the > general performance a bug. Unless you have specific bug to fix, or > enhancement to make, don't use JIRA. Use the dev mailing list to make your > case, see if someone will produce a patch or find a measurable bottleneck > that can be addressed. JIRA is not the place for discussions about the > design of CouchDB components. Neither is IRC. > > Also, if you want something without view performance problems but similar > to CouchDB, you should look at MongoDB. > > -Damien > > > > > >>> Optimizing the view server is an agreed goal of the community. > > > > Maybe in people's heads, but it wasn't written down anywhere such as the > > tracker or the roadmap. In fact the front page of couchdb.org claims > that > > Erlang allows for the CouchDB design to be scalable and the overview page > > makes an "efficient" claim in the last sentence. The current > implementation > > is neither of these. > > > >>> Probably the best way to help is to take a look at all the work > >>> Damien's done in trunk (the pipelining) and perhaps the parallel > >>> writers optimization he has. > > > > BTW I have been using trunk for over a week. It is better than 0.10 that > I > > was using before but not that much of an improvement. And changes in the > > way I generate some of my data have hurt me again (I can either order for > > _id or for view keys but not both at the same time) so my initial DB has > now > > gone from 4GB to 15GB (I optimized for views). > > > >>> We could really use a way to take the > >>> benchmarks you ran, and put them into the buildbot. > > > > Sadly I can't do it with my real data because it belongs to someone else. > > However I hereby commit to produce a representative benchmark that is > > substantially similar in performance and data within the next two weeks. > > (Also note that there is nothing special about what I am doing - anyone > with > > similar numbers of documents has similar issues.) > > > > I'm hoping that more can be done about the size issues soon too. (I > think > > that addressing the size issues will help a lot since it will require way > > less CPU and I/O to produce and use smaller files.) > > > > Roger > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iEYEARECAAYFAktOWSgACgkQmOOfHg372QQ9rQCfTiSs1etiafvG1z4q1yQC0ZRy > > +3AAn0j2TEPuW/AXTvNZl9KPfTT6hGNn > > =rSWg > > -----END PGP SIGNATURE----- > > > >
