tag:blogger.com,1999:blog-6265706250887913030.post8613328031398632316..comments2023-10-16T09:26:40.289-07:00Comments on Read . Write . Sleep: TokyoTyrant vs MongoDB vs CouchDB, simple benchmarksJanhttp://www.blogger.com/profile/06665323561458161788noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-6265706250887913030.post-72258782975003919632010-03-02T01:16:28.368-08:002010-03-02T01:16:28.368-08:00Hi Mikeal, thank you for the info.
btw. the origi...Hi Mikeal, thank you for the info.<br /><br />btw. the original article is in Chinese :->Janhttps://www.blogger.com/profile/06665323561458161788noreply@blogger.comtag:blogger.com,1999:blog-6265706250887913030.post-87185843975893156592010-03-01T22:44:40.821-08:002010-03-01T22:44:40.821-08:00CouchDB is optimized for concurrent performance. I...CouchDB is optimized for concurrent performance. If you do the writes concurrently (like a webapp normally would under load) performance actually increases because the fsync's are batched.<br /><br />I can't actually tell what these numbers mean or what this test does because the original article is in japanese but I would warn against testing MongoDB write performance without including a read for each insert. By default MongoDB doesn't return a response for insert calls so all you're really testing is the socket.write() time. You don't know if what you've inserted is even available yet ( it mostly likely is available quickly if you only have one writer but under concurrent load you could have problems) and it won't be written to disc for possibly another minute.mikealhttps://www.blogger.com/profile/04195135977430324921noreply@blogger.comtag:blogger.com,1999:blog-6265706250887913030.post-19967790386623205202010-02-28T23:58:01.420-08:002010-02-28T23:58:01.420-08:00make sense. I'll check how these guys perform ...make sense. I'll check how these guys perform under concurrent context in future.<br /><br />Thanks :)Janhttps://www.blogger.com/profile/06665323561458161788noreply@blogger.comtag:blogger.com,1999:blog-6265706250887913030.post-86807521074343341412010-02-28T22:44:02.379-08:002010-02-28T22:44:02.379-08:00Hi Jan :)
Yeah, the ruby HTTP stack is sub-par, ...Hi Jan :) <br /><br />Yeah, the ruby HTTP stack is sub-par, that is one reason :) Sequential ids is another thing that gives you better performance (CouchDB 0.11 will use them by default).<br /><br />Another is that CouchDB is optimized for multi-reader/writer concurrency. The baseline might be a lot slower, but it won’t degrade as you crank up concurrency. It'll still be "fast enough" to not be a bottleneck in your application. I hope you only optimise these :)<br /><br />CouchDB doesn't have "native" bindings* and only the HTTP API because that works everywhere and gets you a ton of benefits: You can add proxies and caches and all the other nifty things you already know from your web server stack.<br /><br />So it's about trade-offs. You'll find that single query execution speed is rarely where your app needs optimising. But that is not generally true, of course.<br /><br />Cheers<br />Jan<br />--<br /><br />(* there's a pure-erlang API that you can use from an Erlang program that is semi-supported)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6265706250887913030.post-4575041371633517412010-02-28T22:21:55.310-08:002010-02-28T22:21:55.310-08:00The distance between CouchDB and other candidates ...The distance between CouchDB and other candidates is so big I suspect it's my fault. Did I do anything wrong on couchdb? Should I use pre-genereated sequential ids instead of random UUID? (but I think default should be good enough for all software ..)<br /><br />I can find official ruby drivers from MongoDB/TT site, but CouchDB only provide a simple ruby module to interact with couch using restful api. Is this the reason? I failed to find a ruby driver for couch, though there's many ORMs.Janhttps://www.blogger.com/profile/06665323561458161788noreply@blogger.comtag:blogger.com,1999:blog-6265706250887913030.post-40304190962846119942010-02-28T22:03:08.056-08:002010-02-28T22:03:08.056-08:00Hi Jan,
(sounds like I'm talking to myself :-...Hi Jan,<br /><br />(sounds like I'm talking to myself :-)<br /><br />Great articles. And yes, as you pointed out, this is not a real test of what CouchDB is capable. In the benchmarks I test CRU (without Delete) operations in an extremly simple env/context, e.g. no concurrency, no optimizations, etc.<br /><br />However that's my intention. I'm not experienced enough to get comprehensive benchmarks, I just want to check some basic things for now. The test is certainly not completed yet, I'll add more benchmarks when I have time.<br /><br />And it's surprising to see the big discrepancy between machines even the tests are so simple.<br /><br />Cheers~Janhttps://www.blogger.com/profile/06665323561458161788noreply@blogger.comtag:blogger.com,1999:blog-6265706250887913030.post-36298430862978262902010-02-28T21:11:47.177-08:002010-02-28T21:11:47.177-08:00These benchmarks don't really test what CouchD...These benchmarks don't really test what CouchDB is capable of.<br /><br />Please see http://jan.io/Gy8t and http://jan.io/SEq7<br /><br />Cheers<br />Jan<br />--Anonymousnoreply@blogger.com