On Thu, Feb 3, 2011 at 7:02 PM, Sameer Farooqui <cassandral...@gmail.com>wrote:
> Hi guys, > > I was playing around with the stress.py test this week and noticed a few > things. > > 1) Progress-interval does not always work correctly. I set it to 5 in the > example below, but am instead getting varying intervals: > Generally indicates that the client machine is being overloaded in my experience. 2) The key_rate and op_rate doesn't seem to be calculated correctly. Also, > what is the difference between the interval_key_rate and the > interval_op_rate? For example in the example above, the first row shows 6662 > keys inserted in 5 seconds and 6662 / 5 = 1332, which matches the > interval_op_rate. > There should be no difference unless you're doing range slices, but IPC timing makes them vary somewhat. 3) If I write x KB to Cassandra with py_stress, the used disk space doesn't > grow by x after the test. In the example below I tried to write 500,000 keys > * 32 bytes * 5 columns = 78,125 kilobytes of data to the database. When I > checked the amount of disk space used after the test it actually grew by > 2,684,920 - 2,515,864 = 169,056 kilobytes. Is this because perhaps the > commit log got duplicate copies of the data as the SSTables? > Commitlogs could be part of it, you're not factoring in the column names, and then there's index and bloom filter overhead. Use contrib/stress on 0.7 instead. -Brandon