Details
-
New Feature
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
-
None
Description
In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc.
The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection).
We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading:
http://research.google.com/pubs/pub36356.html
http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/
http://www.usenix.org/event/nsdi07/tech/fonseca.html
Attachments
Attachments
Issue Links
- relates to
-
CASSANDRA-511 log abnormally long queries
- Resolved
-
CASSANDRA-1305 Slow query log
- Resolved
-
CASSANDRA-1355 Log RPC exceptions and timing data
- Resolved
1.
|
Add tracing support for CQL3 bind variables | Resolved | David Alves | ||
2.
|
Add cqlsh syntax to enable request tracing | Resolved | Aleksey Yeschenko | ||
3.
|
Add cqlsh support for tracing results | Resolved | David Alves | ||
4.
|
Add TRACE support to binary protocol | Resolved | Sylvain Lebresne |