One idea I've heard batted around is to override
IndexSearcher.createWeight in a profiling IndexSearcher and then wrap
Weights and finally Scorers in order to emit metrics on every advance
or other low-level operation.  This could help with search profiling I
guess although of course it will slow everything down, it might be
helpful for counting operations.  But maybe your problem is during
indexing?

On Wed, Mar 19, 2025 at 5:59 AM Robert Muir <rcm...@gmail.com> wrote:
>
> opentelemetry is anything but lightweight, not recommended. Don't
> waste your time with it. if you want to expose 'metrics', it is really
> up to the application to do that, lucene is just a library. I'd
> recommend just exposing via HTTP and using prometheus & co.
>
> Debugging performance issues in the library is totally different and
> telemetry as a word doesn't make sense for that You can setup 'perf'
> to debug performance issues. You can also run with lightweight JFR
> profiling built into the JVM. The nightly benchmarks already do that.
>
> On Wed, Mar 19, 2025 at 2:16 AM Vigya Sharma <vigya.w...@gmail.com> wrote:
> >
> > Hi All,
> >
> > I am debugging an unexpected throughput regression in my feature branch 
> > which has changes across multiple files and functions, and was wondering if 
> > there's a better way to identify the slowdown than adding elapsed time logs 
> > to infostream.
> >
> > Do we have support in Lucene for telemetry on internal operations? It would 
> > be nice to be able to add timers, counters, and metrics, to identify 
> > performance changes. This would hide disabled behind a gradle flag. We 
> > could enable it for benchmark runs and possibly chart these metrics in 
> > nightly runs.
> >
> > Has this been discussed before? I'm happy to explore this more if it sounds 
> > like a good idea. Any suggestions for lightweight, open-source telemetry 
> > libraries that I should look into? I'm considering OpenTelemetry but open 
> > to alternate suggestions and ideas.
> >
> > Vigya
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to