A comprehensive performance testing and auto-optimization tool for comparing ForkJoinPool.commonPool() vs dedicated ThreadPoolExecutor when using the Checkout SDK with rate limiting.
This tool performs real API calls against Checkout's sandbox environment to compare the performance characteristics of different executor types under rate-limited conditions. It includes automated configuration optimization to find the best performance settings for your specific environment.
- Dedicated ThreadPoolExecutor consistently outperforms ForkJoinPool.commonPool() in rate-limited I/O scenarios
- Optimal configuration automatically discovered through systematic testing
- Performance improvements of 50-80% in latency and throughput achieved through auto-tuning
- Java 11+ installed
- Checkout account with sandbox access
- Environment variables configured:
cp .env.example .env
# Edit .env with your Checkout credentials:
# CHECKOUT_DEFAULT_PUBLIC_KEY=pk_sbox_...
# CHECKOUT_DEFAULT_SECRET_KEY=sk_sbox_...
# CHECKOUT_PROCESSING_CHANNEL_ID=pc_...Note:
.envand.auto_tune_configfiles are automatically ignored by git for security.
# Full automated sequence: test β auto-tune β verify
./run_full_test.shThis will:
- Test current configuration
- Run auto-optimization (45-60 minutes)
- Apply best settings automatically
- Verify optimized performance
# Test current configuration without optimization
./simple_test.sh| Script | Purpose | Duration |
|---|---|---|
simple_test.sh |
Test current configuration | 2-3 minutes |
auto_tune.sh |
Find optimal configuration | 45-60 minutes |
run_full_test.sh |
Complete automated sequence | 50-65 minutes |
run_simulation.sh |
Enhanced simulation testing | 1-2 minutes |
load_config.sh |
Display current configuration | Instant |
-
SdkQueueSimulation.java: Enhanced simulation with rate limiting and auto-tuned config- Uses Thread.sleep() to simulate HTTP delays
- Perfect for controlled testing and demonstrations
- Shows ~67% improvement with dedicated executors
- Loads configuration from
.auto_tune_config
-
SdkQueueSimulationRealSdk.java: Real API testing with Checkout SDK- Makes actual HTTP calls to Checkout API
- Real-world performance measurement
- Rate limiting and retry logic
- Production-ready implementation
The tool automatically tests different combinations of:
- CLIENT_THREADS: Number of concurrent client threads
- SDK_DEDICATED_THREADS: Dedicated executor pool size
- RATE_LIMITER: Maximum concurrent API requests
- CONNECTION_POOL_SIZE: HTTP connection pool size
// Auto-discovered optimal settings
CLIENT_THREADS = 35
SDK_DEDICATED_THREADS = 35
RATE_LIMITER = 42
CONNECTION_POOL_SIZE = 50
// Performance achieved:
// Average Latency: 394.5ms
// Throughput: 17.75 req/s
// Performance Score: 0.0449The system automatically loads configuration from .auto_tune_config if available:
// Java code automatically loads optimized values
private static void loadAutoTuneConfig() {
// Loads from .auto_tune_config or uses defaults
}- Semaphore-based concurrent request control
- Exponential backoff for 429 responses
- Retry logic with configurable attempts
- Average, P95, P99 latencies
- Throughput (requests per second)
- Composite score (throughput/latency ratio)
- Success rate tracking
logs/
βββ auto_tune_results_YYYYMMDD_HHMMSS/
β βββ results.csv # Complete test results
β βββ test_*.log # Individual test logs
βββ simple_test_YYYYMMDD_HHMMSS.log # Simple test results
| Executor Type | Avg Latency | Throughput | Score |
|---|---|---|---|
| Dedicated | 394.5ms | 17.75 req/s | 0.0449 |
| CommonPool | 1200-1400ms | 11-13 req/s | 0.009-0.011 |
Results from auto-tuned optimal configuration
CHECKOUT_DEFAULT_PUBLIC_KEY=pk_sbox_... # Sandbox public key
CHECKOUT_DEFAULT_SECRET_KEY=sk_sbox_... # Sandbox secret key
CHECKOUT_PROCESSING_CHANNEL_ID=pc_... # Processing channel.auto_tune_config contains the discovered optimal settings:
# Auto-tuned optimal configuration
# Generated: [timestamp]
# Best Score: 0.0449
CLIENT_THREADS=35
SDK_DEDICATED_THREADS=35
CONNECTION_POOL_SIZE=50
RATE_LIMITER=42
BEST_LATENCY=Avg=394.5ms, Throughput=17.75- Work-stealing overhead: CommonPool's work-stealing adds latency in I/O-bound scenarios
- Thread contention: Dedicated threads avoid interference from other application tasks
- Rate limiting efficiency: Dedicated executor handles semaphore blocking more efficiently
- Resource isolation: Separate thread pool prevents cross-contamination
// Semaphore-based rate limiting
private static final Semaphore RATE_LIMITER = new Semaphore(42);
// With exponential backoff retry
private static <T> T executeWithRateLimit(Callable<T> operation) {
// Implementation with retry logic and backoff
}// Optimized connection pooling
PoolingHttpClientConnectionManager connManager =
new PoolingHttpClientConnectionManager();
connManager.setMaxTotal(CONNECTION_POOL_SIZE);
connManager.setDefaultMaxPerRoute(CONNECTION_POOL_SIZE);- Use the auto-tuned configuration as starting point
- Monitor performance in production environment
- Re-run auto-tuning if load patterns change significantly
- Consider dedicated executor for I/O-heavy Checkout SDK usage
./gradlew build./gradlew testsrc/main/java/org/example/
βββ SdkQueueSimulationRealSdk.java # Main comparison tool
- Fork the repository
- Create your feature branch
- Add tests for new functionality
- Ensure all tests pass
- Submit a pull request
This project is licensed under the MIT License - see the LICENSE file for details.
Auto-generated documentation based on performance testing results