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
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
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 th
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 laten
