Sorry, I misunderstood your short response as "JMX already does it so we don't need something else".
wunder On Jul 10, 2013, at 7:28 PM, Otis Gospodnetic wrote: > Sorry, I don't follow what you mean by "another server" and "get it > *into* CM" and fear we're getting OT. Just meant to say that if > somebody is working on tracking more stats with Coda's metrics > package, those stats should/could be exposed via JMX like all other > Solr stats and that CM has the ability to expose whatever it collects > via JMX, which makes me think that's the easiest and most useful thing > to do. But maybe I'm missing something here... > > Otis > > > > On Wed, Jul 10, 2013 at 10:20 PM, Walter Underwood > <[email protected]> wrote: >> So? >> >> JMX-only requires another server to get it into Codahale Metrics. >> >> wunder >> >> On Jul 10, 2013, at 7:19 PM, Otis Gospodnetic wrote: >> >> Coda's stuff exports to JMX and Solr exports to JMX. >> >> Otis >> -- >> Solr Performance Monitoring -- http://sematext.com/spm >> >> >> >> On Wed, Jul 10, 2013 at 10:09 PM, Walter Underwood >> <[email protected]> wrote: >> >> There is some work on reporting this through the Codahale Graphics system. >> >> For us, that is way way better than a Solr-specific metrics interface. >> >> >> wunder >> >> >> On Jul 10, 2013, at 7:06 PM, Erick Erickson wrote: >> >> >> Yonik: >> >> >> Yes, but correlating these is a bit awkward. My notion is it would be >> >> useful to have this in a debug response and avoid having to >> >> reconcile things from log files.... Perhaps Shawn's idea >> >> would be a good thing to put in a (new?) debug section rather than >> >> re-purpose the QTime which we all know and love. >> >> >> On Wed, Jul 10, 2013 at 10:01 PM, Otis Gospodnetic >> >> <[email protected]> wrote: >> >> >> This sounds attractive to me. What other times are you thinking about, >> >> Shawn? >> >> >> >> I think this type of info should be owned by Solr and one should not >> >> >> rely on Jetty. Plus the plan is to ditch the servlet container >> >> >> anyway. >> >> >> >> Otis >> >> >> -- >> >> >> Solr Performance Monitoring -- http://sematext.com/spm >> >> >> >> >> >> On Wed, Jul 10, 2013 at 6:04 PM, Shawn Heisey <[email protected]> wrote: >> >> >> On 7/10/2013 2:46 PM, Erick Erickson wrote: >> >> >> >> I've been waving my hands for a while with "QTime is just the query >> >> >> time, it doesn't count network latency, assembling the response blah >> >> >> blah blah". >> >> >> >> It seems like we could at least provide the time it takes to write out >> >> >> the docs that would include decompression time, disk latency, all that >> >> >> stuff. Still wouldn't deal with network latency, but it'd be progress. >> >> >> >> >> <snip> >> >> >> >> >> Does this seem do-able? What about valuable? I'm assuming that just >> >> >> _adding_ a section wouldn't break back-compat. What do people think? >> >> >> Should I raise a JIRA? >> >> >> >> >> +1 on raising a JIRA. Here's my radical notion: >> >> >> >> IMHO we should add all available timing information up and display that as >> >> >> QTime. Having that QTime further broken down into additional information >> >> >> would be very good. Any simple calculations (which shouldn't really slow >> >> >> down a request) should be included by default, and any calculations that do >> >> >> slow things down could be part of debugQuery output. >> >> >> >> My preference would be to make these changes in branch_4x, but if we do >> >> >> that, we'll suddenly be dealing with people who think that a minor version >> >> >> upgrade has incredibly worse performance just based on QTime numbers, even >> >> >> though nothing has really changed. >> >> >> >> If we just make the additional information available in 4.x and then update >> >> >> QTime to include everything in 5.0, that seems like a reasonable path. It's >> >> >> easier to manage expectations on a major version bump. >> >> >> >> Thanks, >> >> >> Shawn > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Walter Underwood [email protected]
