question about performance of Cassandra 0.7.4 under a read-heavy workload.
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?
Re: question about performance of Cassandra 0.7.4 under a read-heavy workload.
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倍!
Re:Re: question about performance of Cassandra 0.7.4 under a read-heavy workload.
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倍!
Re: question about performance of Cassandra 0.7.4 under a read-heavy workload.
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? Thanks Aaron 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倍!
