Interesting results. With PlayOrm, we did a 6 node test of reading 100 rows from 1,000,000 using PlayOrm Scalable SQL. It only took 60ms. Maybe we have better hardware though??? We are using 7200 RPM drives so nothing fancy on the disk side of things. More nodes puts at a higher throughput though as reading from more disks will be faster. Anyways, you may want to play with more nodes and re-run. If you run a test with PlayOrm, I would love to know the results there as well.
Later, Dean From: Arindam Barua <aba...@247-inc.com<mailto:aba...@247-inc.com>> Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Date: Monday, October 1, 2012 4:57 PM To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Subject: Read latency issue unning a query to like “select * from <table_name> where atag=<foo>”, where ‘atag’ is the first column of the composite key, from either JDBC or Hector (equivalent code), results in read times of 200-300ms from a remote host on the same network. The query returned around 800 results. Running the same query on a Cassandra host results in a read time of ~110-130 ms. Using read consistency of ONE reduces the read latency by ~20ms, compared to using QUORUM. Enabling row cache did not seem to change the performance much. Moreover, the row cache ‘size’ according to nodetool was very tiny. Here is a snapshot of the nodetool info after running few read tests: Key Cache : size 2448 (bytes), capacity 104857584 (bytes), 231 hits, 266 requests, 1.000 recent hit rate, 14400 save period in seconds Row Cache : size 96 (bytes), capacity 4194304000 (bytes), 9 hits, 13 requests, NaN recent hit rate, 0 save period in seconds
