CouchDB is smart enough to collect writes from multiple concurrent clients into a "group commit" and issue only one fsync to durably store all of them in one go. It's a bit like generating a _bulk_docs request under the hood. That's the main reason you see the jump from 10/sec to 300/sec.
Adam On Oct 26, 2011, at 7:52 PM, Riyad Kalla wrote: > Hmm, I see what you mean. If a single connection isnt pegging any of the > hardware and multiple connections are a magnitude times faster, I am not sure > what would be keeping the single connection from performning faster. > > Maybe someone else can hop in with ideas? > > R > > On Oct 26, 2011, at 4:32 PM, Konstantin Cherkasoff <[email protected]> > wrote: > >> Hi! >> >>> What happens when you set delayed_commits to true? >> With delayed_commits I got about 150 rps so delayed_commits mode is 15 >> times faster. >> >>> With that off you are requiring an fsync (iirc) after every value written >>> and then are at the >>> mercy at your disks write performance (but not in the sense of burst-write >>> as these are individual, disparate write requests coming in). >> >> Yes, I understand that many small writes and fsyncs can be a >> bottleneck in this case. >> But I found that the increase of number of concurrent requests lead to >> an increase in the request rate. >> For example (100 concurent requests) >>> ab -k -t 10 -c 100 -n 1000000 -p ab.json -T "application/json" >>> http://localhost:5984/bench >> shows about 300 RPS (writes and fsyncs) on the same hardware. >> >> So, I suppose that 10 requests per second actually is not the limit >> for this hard disk. >> And there may be some other problem. >> >>> Also, is this build Couch Single Server from Couchbase or some other >>> Windows build of Couch? >> I tried Couchbase 1.2.0 and >> this build >> https://github.com/downloads/dch/couchdb/setup-couchdb-1.1.0+COUCHDB-1152_otp_R14B03.exe >> >> >> -- >> Konstantin
