Repository navigation
Conversation
…erver into optimizeJwtDecodingPerformanceTesting
…erver into optimizeJwtDecodingPerformanceTesting
Mirrors the existing HTTP smoke benchmarks (DecodedJwtCacheHttpBenchmark*) for real gRPC calls over a TCP loopback channel, and adds cold-start (no warm-up) wall-clock interval benchmarks (1-5, 10, 15s) for both HTTP and gRPC, using a round-robin pool of 20 tokens to simulate a realistic number of concurrent clients. New: - jwt-spring-grpc-native/.../perf/GrpcBenchmarkSupport.java - jwt-spring-grpc-native/.../perf/DecodedJwtCacheGrpcBenchmarkCachedTest.java - jwt-spring-grpc-native/.../perf/DecodedJwtCacheGrpcBenchmarkNoCacheTest.java - jwt-spring-grpc-native/.../perf/DecodedJwtCacheGrpcBenchmarkColdStartCachedTest.java - jwt-spring-grpc-native/.../perf/DecodedJwtCacheGrpcBenchmarkColdStartNoCacheTest.java - jwt-spring-web/.../perf/DecodedJwtCacheHttpBenchmarkColdStartCachedTest.java - jwt-spring-web/.../perf/DecodedJwtCacheHttpBenchmarkColdStartNoCacheTest.java Changed: - jwt-spring-web/.../perf/HttpBenchmarkSupport.java: added measureColdStartIntervals() helper (mirrored into GrpcBenchmarkSupport). All tests are @tag("performance") and @disabled by default, matching the existing manual-benchmark convention. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Redesign the HTTP and gRPC decoded-JWT cache benchmarks to use one dedicated connection (client) per thread running concurrently, instead of a single thread round-robining through a token pool. Each parallel client is synchronized to start simultaneously via a CyclicBarrier, so measured throughput reflects real concurrent load rather than serialized round-trip latency. Client/token count is sized to abt-core's observed peak-hour (08:00/ 16:00) concurrency per Entur Compass: 15 parallel clients, 2 tokens each (30 tokens total). Also replace TestRestTemplate with a minimal JDK HttpClient-based RawHttpClientSupport in the HTTP benchmarks' timed hot path, removing interceptor/Jackson overhead that was dominating measurements. measureColdStartIntervals(Parallel) now reports only segment throughput per checkpoint (not cumulative-since-start).
Reduce benchmark concurrency to 10 parallel clients, 2 tokens each (20 tokens total). Add HttpBenchmarkSupport.assertJacocoAgentDisabled() and GrpcBenchmarkSupport.assertJacocoAgentDisabled(), called from each benchmark's readiness probe. They inspect the JVM's input arguments and fail fast with a clear message if the JaCoCo agent is attached, since coverage instrumentation adds substantial, uneven per-call overhead that invalidates timing measurements. Benchmarks must be run with -Djacoco.skip=true.
Contributor
Author
Local Benchmark results: 10 parallel clients, 2 tokens eachEach benchmark runs 10 independent client threads concurrently (each with its own connection), sharing 20 distinct JWT tokens (2 per client), all synchronized to start at the same instant. Benchmarks now assert the JaCoCo agent is not attached and fail fast otherwise, since coverage instrumentation would skew the timings. Fixed-load (~10s each, 100k requests total)
Cold-start segment throughput, 10 parallel clients (20 tokens)
Both cache-enabled and cache-disabled scenarios reach a stable steady state within a few seconds. The decoded-JWT cache gives a consistent ~33–37% HTTP throughput improvement and ~69–105% gRPC throughput improvement under concurrent load. |
Contributor
Author
…rHolder Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.




Simple AI-generated benchmarks for #361
Measurements are a bit crude - junit runs on local machine (16 + 16 cores). Only measures dummy calls.
Results are promising. Obiously for apps doing real work the relative impact is much smaller.
Results (2026-10-01, #361 at
d16a3ae, CPU boost disabled)HTTP and gRPC benchmarks use the Spring configuration, i.e. the default
lrucache mode. RS256 tokens, dummy endpoints.gRPC
HTTP
With the cache, cold start is at full throughput from the first second.
Decoder only (200 000 decodes,
lrumode)Earlier results (2026-10-01, #361 at
f1589540, CPU boost enabled)Not directly comparable: CPU boost was enabled, and the decoder-only benchmark used
fixedmode.Running the benchmarks
The benchmarks are
@Disabled(and taggedperformance), and fail if JaCoCo is attached. To run them: