Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Minor
    • Resolution: Won't Fix
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      If a query takes a long time, it's nice to know why

        Issue Links

          Activity

          Hide
          jbellis Jonathan Ellis added a comment -

          closing since there does not seem to be any more interest in this

          Show
          jbellis Jonathan Ellis added a comment - closing since there does not seem to be any more interest in this
          Hide
          jbellis Jonathan Ellis added a comment -

          I also need to be convinced that CLHM + LBQ aren't going to cause too much GC overhead.

          Using the key as an id means you can get different requests polluting each others' data. Maybe a threadlocal would work better.

          I'm inclined to prefer the CASSANDRA-1123 approach, you get 80% of the benefit for much less overhead.

          Show
          jbellis Jonathan Ellis added a comment - I also need to be convinced that CLHM + LBQ aren't going to cause too much GC overhead. Using the key as an id means you can get different requests polluting each others' data. Maybe a threadlocal would work better. I'm inclined to prefer the CASSANDRA-1123 approach, you get 80% of the benefit for much less overhead.
          Hide
          jbellis Jonathan Ellis added a comment -

          Daniel, can you update this patch to conform to the style followed by the rest of the code? (see http://wiki.apache.org/cassandra/CodeStyle)

          Show
          jbellis Jonathan Ellis added a comment - Daniel, can you update this patch to conform to the style followed by the rest of the code? (see http://wiki.apache.org/cassandra/CodeStyle )
          Hide
          jbellis Jonathan Ellis added a comment -

          related: CASSANDRA-1123

          Show
          jbellis Jonathan Ellis added a comment - related: CASSANDRA-1123
          Hide
          danielkluesing_bk Daniel Kluesing added a comment - - edited

          There are lots of knobs to tune (row cache, key cache, index sample size, bloom filter buckets, network, disk, heap) Figuring out what to tune under load isn't always obvious. Turning on debug logging under load has heisenberg effect of shifting bottlenecks around. The attached patch is a simple slow query logger to log information about what queries that take longer than some threshold did that took so long. I've found it useful for pinpointing bottlenecks under load and figuring out which knobs need tweaking. This patch only instruments the get_slice command and the read path. Incrementing the other commands/paths is straightforward, and I can update the patch with the write path.

          Show
          danielkluesing_bk Daniel Kluesing added a comment - - edited There are lots of knobs to tune (row cache, key cache, index sample size, bloom filter buckets, network, disk, heap) Figuring out what to tune under load isn't always obvious. Turning on debug logging under load has heisenberg effect of shifting bottlenecks around. The attached patch is a simple slow query logger to log information about what queries that take longer than some threshold did that took so long. I've found it useful for pinpointing bottlenecks under load and figuring out which knobs need tweaking. This patch only instruments the get_slice command and the read path. Incrementing the other commands/paths is straightforward, and I can update the patch with the write path.

            People

            • Assignee:
              Unassigned
              Reporter:
              danielkluesing_bk Daniel Kluesing
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development