One would hope that https://issues.apache.org/jira/browse/SOLR-4735 will be done by then.
On 9/28/15, 11:39 AM, "Walter Underwood" <wun...@wunderwood.org> wrote: >We did the same thing, but reporting performance metrics to Graphite. > >But we won’t be able to add servlet filters in 6.x, because it won’t be a >webapp. > >wunder >Walter Underwood >wun...@wunderwood.org >http://observer.wunderwood.org/ (my blog) > > >> On Sep 28, 2015, at 11:32 AM, Gili Nachum <gilinac...@gmail.com> wrote: >> >> A different solution to the same need: I'm measuring response times of >> different collections measuring online/batch queries apart using New >> Relic. I've added a servlet filter that analyses the request and makes >>this >> info available to new relic over a request argument. >> >> The built in new relic solr plug in doesn't provide much. >> On Sep 28, 2015 17:16, "Shawn Heisey" <apa...@elyograg.org> wrote: >> >>> On 9/28/2015 6:30 AM, Oliver Schrenk wrote: >>>> I want to register multiple but identical search handler to have >>> multiple buckets to measure performance for our different apis and >>> consumers (and to find out who is actually using Solr). >>>> >>>> What are there some costs associated with having multiple search >>> handlers? Are they neglible? >>> >>> Unless you are creating hundreds or thousands of them, I doubt you'll >>> notice any significant increase in resource usage from additional >>> handlers. Each handler definition creates an additional URL endpoint >>> within the servlet container, additional object creation within Solr, >>> and perhaps an additional thread pool and threads to go with it, so >>>it's >>> not free, but I doubt that it's significant. The resources required >>>for >>> actually handling a request is likely to dwarf what's required for more >>> handlers. >>> >>> Disclaimer: I have not delved into the code to figure out exactly what >>> gets created with a search handler config, so I don't know exactly what >>> happens. I'm basing this on general knowledge about how Java programs >>> are constructed by expert developers, not specifics about Solr. >>> >>> There are others on the list who have a much better idea than I do, so >>> if I'm wrong, I'm sure one of them will let me know. >>> >>> Thanks, >>> Shawn >>> >>> >
