On Wed, Jul 28, 2010 at 02:55, Sivan Greenberg <[email protected]> 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 <[email protected]> wrote: >> On Wed, Jul 28, 2010 at 12:02 PM, Randall Leeds <[email protected]> >> 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. Randall
