Cache sql sanitized extraction

[breedx-splk]

This builds on top of #2087 and will be rebased when that is in...so maybe wait to review?

The discussion in #2065 talks about sql parsing being expensive. If we cache the sql statement string to SqlStatementInfo we can prevent having to do this heavy lifting more than once for each statement. A guava LRU cache was selected to prevent caching excessive numbers of statements on the heap in the even the user does dynamic/inconsistent sql string creation.

This seems like a pretty reasonable compromise -- it keeps the utility of sanitization and db/operation extraction while preventing duplicate efforts in common situations.

A benchmark based on spring-petclinic-rest (which uses hibernate) shows the following with 5VUs, 500 iterations:

• No agent : avg = 98.83 p95 = 119.73
• With agent no cache: avg = 319.32 p95 = 525.50
• With agent with cache: avg = 129.67 p95 = 174.81
  (all times in ms)

[jkwatson]

This seems like a pretty nice performance win. 5000 might even be too many to cache. If we're willing to put metrics into our code, it would be rad to register an observer that would report how many items were in the cache.

[mateuszrzeszutek]

Muzzle failed locally:

FAILED MUZZLE VALIDATION: io.opentelemetry.javaagent.instrumentation.jdbc.JdbcInstrumentationModule mismatches:
-- io.opentelemetry.javaagent.instrumentation.jdbc.JdbcUtils:31 Missing class com.google.common.cache.CacheBuilder
-- io.opentelemetry.javaagent.instrumentation.jdbc.JdbcUtils:79 Missing class com.google.common.cache.Cache

This is the second time I've noticed that it passes in GHA but fails (correctly) when run locally. Do we use some sort of cache for muzzle tasks?

[iNikem]

Muzzle failed locally:

FAILED MUZZLE VALIDATION: io.opentelemetry.javaagent.instrumentation.jdbc.JdbcInstrumentationModule mismatches:
-- io.opentelemetry.javaagent.instrumentation.jdbc.JdbcUtils:31 Missing class com.google.common.cache.CacheBuilder
-- io.opentelemetry.javaagent.instrumentation.jdbc.JdbcUtils:79 Missing class com.google.common.cache.Cache

This is the second time I've noticed that it passes in GHA but fails (correctly) when run locally. Do we use some sort of cache for muzzle tasks?

All GHA runs use gradle cache. Both remote and "local". Seems like muzzle tasks don't play nicely with caches?

[mateuszrzeszutek]

All GHA runs use gradle cache. Both remote and "local". Seems like muzzle tasks don't play nicely with caches?

I've created an issue for that: #2110

[breedx-splk]

Closing to prevent premature merging (until I can get a muzzle fix in).

[breedx-splk]

Going to try this as a draft instead of closing.