On Wed, Nov 19, 2014 at 4:51 PM, Jimmy Lin <[email protected]> wrote:
> > # > When you said send "read digest request" to the rest of the replica, do > you mean all replica(s) in current and other DC? or just the one last > replica in my current DC and one of the co-ordinate node in other DC? > > (our read and write is all "local_quorum" of replication factor of 3, > local_dc_repair_chance=0)) > For read_repair_chance, all replicas get one of two messages: a data request, or a digest request. Two of the nodes will get a data request, the others will get digest requests. The behavior is different for local_dc_repair_chance. > > # > Sending "read digest request" to other DC, happen sequently correct? If > network latency between DC is bad during time, will that affect overall > read latency? > No, the coordinator will not wait for those responses before replying to the client. It will only wait for enough responses to satisfy the consistency level. The rest are handled asynchronously in the background. > > # > We observe that one of our cql query perform okay during normal load, but > degrade greatly when we have batch of same cql(looking for the exact > columns and key) sending to server in short period of time(say 100 of them > within a sec). > Our other table or keyspace don't see any latency drop during the time, so > i am not sure we are hitting the capacity yet. So we suspect read_repair > chance may have something to do wit it. > Anything we can look into and see what may cause the latency spike when we > have large number of same cql hitting the server? > I doubt read repair is related. I would try tracing a few of your queries. -- Tyler Hobbs DataStax <http://datastax.com/>
