Benchmark results
FastrAPI consistently outperforms traditional Python web frameworks. Here are real-world benchmarks using k6 load testing:Test environment
- Kernel: 6.16.8-arch3-1
- CPU: AMD Ryzen 7 7735HS (16 cores, 4.83 GHz)
- Memory: 15 GB
- Load Test: 20 Virtual Users (VUs), 30 seconds
Performance comparison
| Framework | Avg Latency (ms) | Median Latency (ms) | Requests/sec | P95 Latency (ms) | P99 Latency (ms) |
|---|---|---|---|---|---|
| FASTRAPI | 0.59 | 0.00 | 31360 | 2.39 | 11.12 |
| FastAPI + Guvicorn (workers: 1) | 21.08 | 19.67 | 937 | 38.47 | 93.42 |
| FastAPI + Guvicorn (workers: 16) | 4.84 | 4.17 | 3882 | 10.22 | 81.20 |
FastrAPI handles 31,360 requests per second with sub-millisecond latency, making it approximately 33x faster than FastAPI + Guvicorn with 1 worker.
Fast-path optimization
FastrAPI includes an intelligent “fast-path” optimization that detects simple endpoints with no dependencies, validation, or complex parameters. These endpoints skip unnecessary processing entirely.How it works
When you register a route, FastrAPI analyzes the function signature at decorator time:health_check endpoint sets is_fast_path = true and bypasses:
- Dependency resolution
- Parameter validation
- Kwargs construction
- Type coercion
Optimization tips
Minimize dependencies for hot paths
Minimize dependencies for hot paths
Keep frequently-accessed endpoints simple. Avoid unnecessary dependencies for routes that need maximum speed.
Use appropriate response types
Use appropriate response types
Explicitly declare response types to avoid runtime type detection:
Leverage concurrent hashmap routing
Leverage concurrent hashmap routing
FastrAPI uses the
papaya concurrent hashmap for O(1) route lookups, which scales efficiently even with 10,000+ routes. Don’t hesitate to create many endpoints.Runtime configuration
Worker threads
FastrAPI automatically configures the Python handler thread pool based on your CPU:- Minimum: 4 threads
- Maximum: 16 threads
- Default: Number of CPU cores (clamped to range)
Tokio async runtime
All request handling runs on Tokio’s async runtime, maximizing concurrency. Python code is executed in a separate thread pool to maintain the GIL isolation.Middleware performance
Layer ordering
FastrAPI applies middleware in a specific order for optimal performance:- Sessions - Lightweight cookie management
- GZip - Compression (only for responses above threshold)
- Python Middleware - Custom user middleware
- CORS - Cross-origin handling
- Trusted Host - Host validation
GZip compression
Configure compression thresholds to avoid overhead on small responses:Memory optimization
Route storage
Routes are stored in a lock-free concurrent hashmap (papaya) with pre-allocated capacity:
Response type detection
FastrAPI determines response types at decorator time, not at request time:Profiling and monitoring
Built-in tracing
FastrAPI uses the
tracing crate for structured logging. Enable debug logs to identify bottlenecks:Request timing
Monitor P95 and P99 latencies to identify slow endpoints. FastrAPI’s median latency of 0.00ms means most requests complete within the measurement precision.
Release build optimizations
FastrAPI’s Rust components are compiled with aggressive optimizations:Best practices
Declare response types
Explicit type hints enable compile-time optimization and skip runtime detection.
Cache expensive operations
Use dependency caching for database connections and expensive computations:
Comparison with FastAPI
| Optimization | FastAPI | FastrAPI |
|---|---|---|
| Dependency resolution | Runtime inspect + reflection every request | One-time parsing at decorator time |
| Route lookup | Regex router (O(n)) | Concurrent hashmap (O(1)) |
| Fast-path detection | No | Yes - skips unnecessary work |
| Async runtime | asyncio | Native Tokio |
| Concurrency | GIL-limited | Lock-free concurrent data structures |
For more details on architectural differences, see the comparison with FastAPI page.