To make a comparation, 10 threads were run against the two workloads seperately. below is the result of Cassandra0.7.4. write heavy workload(i.e., write/read: 50%/50%) median throughput: 5816 operations/second(i.e., 2908 writes and 2908 reads) update latency:1.32ms read latency:1.81ms read heavy workload(i.e., write/read: 5%/95%) median throughput: 40 operations/second(i.e., 2 writes and 38 reads) update latency:1.85ms read latency:90.43ms
and for cassandra0.6.6, the result is: write heavy workload(i.e., write/read: 50%/50%) median throughput: 3284 operations/second(i.e., 1642 writes and 1642 reads) update latency:2.29ms read latency:3.51ms read heavy workload(i.e., write/read: 5%/95%) median throughput: 2759 operations/second(i.e., 2621 writes and 138 reads) update latency:2.33ms read latency:3.53ms all the tests were run in one environment. and most configurations of cassandra are just as default, except that:we choose orderPreservingPartitioner for all the tests and set concurrent_reads as 8( which is the default value of 0.6.6 but the default value of 0.7.4 is 32) . At 2011-04-16 06:53:01，"Aaron Morton" <aa...@thelastpickle.com> wrote: Will need to know more about the number of requests, iostats etc. There is no reason for it to run slower. Aaron On 16/04/2011, at 2:35 AM, 魏金仙 <sei_...@126.com> wrote: I just deployed cassandra 0.7.4 as a 6-server cluster and tested its performance via YCSB. The result seems confusing when compared to that of Cassandra0.6.6. Under a write heavy workload(i.e., write/read: 50%/50%), Cassandra0.7.4 obtains a really satisfactory latency. I mean both the read latency and write latency is much lower than those of Cassandra0.6.6. However, under a read heavy workload(i.e., write/read:5%/95%), Cassandra0.7.4 performs far worse than Cassandra0.6.6 does. Did I miss something? 体验网易邮箱2G超大附件，轻松发优质大电影、大照片，提速3倍!
