Can someone help to determine the anatomy of a quorum read? We are trying to
understand why CFSTATS reports one time and the client actual gets data back
almost 4x slower. Below are the debug logs from a read that all 3 nodes
reported < 2.5secs response time in cfstats but the client did not get data
for almost 10 seconds seconds. Where is the other 7+ seconds going? We are
using 0.6.5 with rf=3.

We have verified that the difference between get_slice and "logout complete"
is the actual client wait time.

The slowest node to respond returned data at 19:26:19,303. That is 2.618
seconds. CFSTATS reports a faster time by a few hundred nanoseconds, and I
assume the difference is network latency?

Why does ReadResponseResolver take almost 3 seconds? That is longer that
actually doing the read. This is a wide row, does this prove Cassandra is
not very efficient reading wide rows at least in 0.6.5? Does this prove a
quorum read is more expensive in terms of making sure the copies match than
it is to actually read the data (not good news for those of us that often
need the *C* in CAP)?

Why is the time stamp for the ReadResponseResolver more than 3.5 seconds
after the last read came in when it says it took less than three seconds for
the resolver? Where did the other 500ms go?

I assume the quorumResponseHandler time is the total read time in terms of
Cassandra. Why does it take another 3+ seconds to get it to the client? Is
this the thrift server? Some of the time is probably for network latency,
but not anything close to 3 seconds. The "logout complete" time is the
actual time the client got the data.

Any help trying to map out exactly what is going on would be much
appreciated.

Thanks.


DEBUG [pool-1-thread-11] 2010-10-14 19:26:16,684 CassandraServer.java (line
216) get_slice
DEBUG [pool-1-thread-11] 2010-10-14 19:26:16,684 StorageProxy.java (line
474) strongread reading data for SliceFromReadCommand(table='xx',
key='row_key', column_parent='QueryPath(columnFamilyName='fact',
superColumnName='null', columnName='null')', start='503a', finish='503a7c',
reversed=false, count=10000000) from 7952@/x.x.x.6
DEBUG [pool-1-thread-11] 2010-10-14 19:26:16,685 StorageProxy.java (line
474) strongread reading digest for SliceFromReadCommand(table='xx',
key='row_key', column_parent='QueryPath(columnFamilyName='fact',
superColumnName='null', columnName='null')', start='503a', finish='503a7c',
reversed=false, count=10000000) from 7953@/x.x.x.7
DEBUG [pool-1-thread-11] 2010-10-14 19:26:16,685 StorageProxy.java (line
474) strongread reading digest for SliceFromReadCommand(table='xx',
key='row_key', column_parent='QueryPath(columnFamilyName='fact',
superColumnName='null', columnName='null')', start='503a', finish='503a7c',
reversed=false, count=10000000) from 7953@/x.x.x.8
DEBUG [RESPONSE-STAGE:15] 2010-10-14 19:26:19,090 ResponseVerbHandler.java
(line 42) Processing response on a callback from
7EBDA5E1-AB56-EA3C-82C4-25F0F7260468@/x.x.x.8
DEBUG [RESPONSE-STAGE:16] 2010-10-14 19:26:19,224 ResponseVerbHandler.java
(line 42) Processing response on a callback from
7EBDA5E1-AB56-EA3C-82C4-25F0F7260468@/x.x.x.6
DEBUG [RESPONSE-STAGE:1] 2010-10-14 19:26:19,303 ResponseVerbHandler.java
(line 42) Processing response on a callback from
7EBDA5E1-AB56-EA3C-82C4-25F0F7260468@/x.x.x.7
DEBUG [GC inspection] 2010-10-14 19:26:19,776 GCInspector.java (line 131) GC
for ParNew: 96 ms, 168972776 reclaimed leaving 1165922488 used; max is
12995002368
 INFO [GC inspection] 2010-10-14 19:26:20,780 GCInspector.java (line 129) GC
for ParNew: 373 ms, 56806184 reclaimed leaving 1336001936 used; max is
12995002368
DEBUG [pool-1-thread-11] 2010-10-14 19:26:22,748 ReadResponseResolver.java
(line 120) resolve: 2966 ms.
DEBUG [pool-1-thread-11] 2010-10-14 19:26:22,748 StorageProxy.java (line
497) quorumResponseHandler: 6063 ms.
DEBUG [pool-1-thread-11] 2010-10-14 19:26:25,983 CassandraServer.java (line
664) logout complete

Reply via email to