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]
