That'll be https://issues.apache.org/jira/browse/SOLR-4735, which I made a start on, but then got diverted into a bunch of other CoreContainer cleanup bits and pieces. Too many JIRAs, too little time...
It's not quite as simple as just plugging the metrics library in, unfortunately, as it has a fairly fixed idea of how to report things via JMX which doesn't fit in with how Solr does things now. I do hope to get back to that soon, though. Alan Woodward www.flax.co.uk On 11 Jul 2013, at 03:47, Walter Underwood wrote: > 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] > > >
