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" <aaron@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_wjx@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倍!



体验网易邮箱2G超大附件,轻松发优质大电影、大照片,提速3倍!