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] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- > Walter Underwood > [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
