4 ms·
A more life-like benchmark for a concurrent web app would include reads, with a few round trips to the db server per request. For most web apps this benchmark
by troyk 16y ago
A more life-like benchmark for a concurrent web app would include reads, with a few round trips to the db server per request. For most web apps this benchmark is useless.
- jchrisa 16y agoI'm pretty sure the more realistic the benchmark gets, the better CouchDB would fare. Some of the abuse I've seen it take (under NDA) you wouldn't believe. I mean seriously sick shit like many many thousands of concurrent users on a server with less oomph than my laptop (don't try this at home, as soon as we saw that we started the user on an agressive upgrade path). Anyway I'm just ranting now so take it with a grain of salt. But Erlang was designed to be un-killable, we're just standing on the shoulders of giants.
- Maro 16y agoWeird, I've talked to clients who weren't able to load their test dataset into CouchDB, it was so slow. Sorry, but the specifics are under NDA. They actually are for real, but what kind of argument is that? Standing on the shoulder of giants? So if another database was written in C which was invented by K&R, more famous than Joe Armstrong, should ppl use that? Can I have some of the stuff you're smoking?
- jchrisa 16y agoIt is possible to configure CouchDB so that with a single client serial importing data, you can get less than ten inserts per second (3 fsyncs per insert). For a brief window we shipped that as the default configuration. I'm not saying CouchDB is a speed-demon. It's not designed to be. It is designed to absorb real-world load spikes without falling over. And eventually when it falls over (as all databases will) it is designed to pop right back up again with only a few ms downtime.