cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <>
Subject Re: question about performance of Cassandra 0.7.4 under a read-heavy workload.
Date Sun, 17 Apr 2011 00:02:57 GMT
Am assuming you are not getting a hot spot in the ring using the OPP. 

When running 0.7.4 with reduced concurrent reads if you see the read stage backing up using
nodetool tpstats and the output from iostats shows that the IO system is not stressed then
you should return the concurrent reads to the recommended value. 

Not sure why the recommendation changed, but how does 0.7.4 perform with the recommended number
of concurrent readers?

Out of interest can anyone talk about IO changes in 0.7.X that resulted in the new recommendation?


On 16 Apr 2011, at 13:33, 魏金仙 wrote:

> 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" <> 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, 魏金仙 <> 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倍!

View raw message