This document captures current performance-oriented design choices and measurement options.
- Dispatcher interceptor fast-path (
hasInterceptors) avoids loop overhead when none are registered. - Batch dispatch pre-sizes response list with batch size.
- WebMVC endpoint validates payload size before JSON parse.
- Metrics interceptor avoids per-call timer builder allocation.
Notifications can run async using jsonrpc.notification-executor-enabled=true.
Recommended production setup:
- Provide dedicated
Executorbean for JSON-RPC notifications. - Set
jsonrpc.notification-executor-bean-nameexplicitly. - Tune pool size/queue based on notification traffic profile.
JMH benchmark exists in jsonrpc-core:
./gradlew :jsonrpc-core:jmhIt includes dispatcher scenarios for single success/error/invalid cases and large batch profiles (all-success, all-error, mixed, notification-only).
Quick profile (short warmup/measurement):
./gradlew :jsonrpc-core:jmhQuickRun quick profile for a specific benchmark include pattern:
./gradlew :jsonrpc-core:jmhQuick -PjmhQuickInclude=JsonRpcDispatcherBenchmark.dispatchSingle- Adjust
jsonrpc.max-request-bytesto realistic payload limits. - Adjust
jsonrpc.max-batch-sizeto protect CPU spikes. - Keep
include-error-data=falsein production unless required. - Disable metrics if not needed (
jsonrpc.metrics-enabled=false). - Use allowlist/denylist to reduce exposed method surface area.
- Set
jsonrpc.metrics-max-method-tag-valuesto bound method tag cardinality. - Enable histogram/percentiles only when needed:
jsonrpc.metrics-latency-histogram-enabledjsonrpc.metrics-latency-percentiles
For representative results, test with:
- mixed success/error/notification traffic
- realistic payload sizes (not only small DTOs)
- transport-level concurrency similar to deployment
- executor saturation and queue pressure for notifications