incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: beam CPU hog
Date Wed, 28 Jul 2010 21:15:11 GMT
On Wed, Jul 28, 2010 at 02:55, Sivan Greenberg <> wrote:
> Another odd thing is that I don't seem to realize why after a 100-300
> runs of the script time after another, from a point onward, it would
> fail on the setUp method when trying to save the doc- without any
> apparent failure in the runTest that could cause the tearDown not to
> run, and leave a doc residual in the db causing the version
> conflict....

Not sure about this one.

> On Wed, Jul 28, 2010 at 12:26 PM, Sivan Greenberg <> wrote:
>> On Wed, Jul 28, 2010 at 12:02 PM, Randall Leeds <> wrote:
>>> 2) Give us more info about your problem with 'load'. You really
>>> shouldn't care about the cpu load. How long your test takes is much
>>> more important. If you're getting a decent number of operations/second
>>> and your cpu is pinned you should be thrilled.
>> The problem is that the servers designated to host CouchDB are very
>> strong servers (8Gigs of RAM, losts of CPU and cores) , but still do a
>> couple of others things like http server and possibly a couple more
>> services. So when CPU is hogged , performance of web apps is effected.
>> However- I would not care too much about this to start with if
>> CouchDB's performance would actually provide the result- the idea
>> about this is to have the conflict resolved in real or near real time
>> manner, to be as coherent as possible with the winning doc or latest
>> version of a shopping cart. So right now, when the db is a bit big
>> (less then 1G still) operations take long such that the expected
>> outcome of conflicts cleared (e.g. _conflicts goes away form the doc
>> obj when asked for with conflict=true) does not happen, when
>> simulating a user action triggering fetching his session details, he
>> gets the wrong version...

It seems like with your deployment you would rather be using
continuous replication since your data is server-side and your servers
are generally connected. It might be harder to generate conflicts in a
test scenario this way because you have to "beat" the replication to
the other copy.

The result of using continuous replication would mean that you will
get update conflicts more often than conflicting revisions. Your
client can handle this by fetching the document and deciding (based on
the timestamp) whether it should clobber the current value.


View raw message