[
https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419884#comment-13419884
]
Jonathan Ellis commented on CASSANDRA-1123:
-------------------------------------------
bq. this would mean that we're storing data belonging to a keyspace (that might
have access control) in another keyspace
True, but it's still opt-in. Don't trace if that's a bad fit for your use
case. For the 99.9% of deployments where a single organization both operates
and uses the cluster, it's very useful to know exactly what statement was slow,
not just what rpc method it was. Say get_slice is slow: was it 1K row being
accessed, or a 100MB row? Were we reading 10 columns or 10000? Huge
difference in how to address those scenarios.
bq. maybe we could instead store the number and length of the arguments
Since every get_slice call will have the same arg count I don't see this being
very useful.
> Allow tracing query details
> ---------------------------
>
> Key: CASSANDRA-1123
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1123
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: David Alves
> Fix For: 1.2
>
> Attachments: 1123-3.patch.gz, 1123.patch
>
>
> 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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
