Resource requirements
Performance evaluation
Understanding the resource footprint of Airlock Microgateway is essential for planning, deploying, and scaling production environments. To provide reliable guidance, we conducted performance benchmarks across a variety of configurations and traffic scenarios. These tests were designed to evaluate how CPU and memory usage scale under load and how different configuration profiles influence overall system behavior.
Benchmarking scope
The performance evaluations simulated realistic K8s Gateway API based usage patterns to measure the following parameters:
- Throughput (requests per second)
- Latency at key percentiles (P90, P95, P99)
- Memory consumption under representative workloads
By isolating the performance impact of specific features and configurations, we were able to quantify how each layer of functionality contributes to overall system behavior. This approach provided actionable insights into how to best balance performance and feature usage in productive deployments of Airlock Microgateway.
Performance-aware resource planning
The table below is intended to help estimate the necessary resources for deploying Airlock Microgateway and guide decisions whether horizontal scaling is necessary in a given environment. By understanding these interactions, you can better align your resource allocation with your functional and performance requirements in your specific environment.
Each configuration is applied consistently across test scenarios to isolate the performance impact of specific features and provide practical guidance for resource planning.
Configuration | P90 latency (ms) | P95 latency (ms) | P99 latency (ms) | Throughput (requests/s) | Memory (MB) | CPU 1) (Cores) |
|---|---|---|---|---|---|---|
Reverse Proxy | 6 | 11 | 20 | 1500 | 180 | 2 |
Default Security | 10 | 16 | 24 | 900 | 200 | |
High Security | 14 | 20 | 26 | 600 | 200 | |
High Security + OpenAPI | 15 | 20 | 27 | 550 | 200 | |
Default + OIDC | 15 | 21 | 30 | 650 | 160 |
- Reverse Proxy
No request filtering enabled; serves as the performance baseline.
- Default Security
Request filtering with deny rules in security level STANDARD; OpenAPI and GraphQL disabled.
- High Security
Request filtering with deny rules in security level STRICT; OpenAPI and GraphQL disabled.
- High Security + OpenAPI
Same as High Security, but with OpenAPI validation enabled.
- Default + OIDC
Default profile with OIDC authentication, token introspection, and session handling.
- 1)
Tested with “Intel Xeon 4210R”
Each row in the table reflects the resource profile of a single engine instance. To handle higher throughput, you must deploy multiple instances.
Session storage memory considerations
Session State and Memory Impact
When enabling session handling in Airlock Microgateway, it is important to account for memory consumption per active session. The total memory footprint will vary based on what data is stored in each session and the number of concurrent sessions. Typically OIDC use cases require the most memory due to token storage.
Estimating Session Memory Usage
A session typically consists of these components:
session size ≈ base data + optional OIDC tokens
Depending on the configuration, the following elements may be included:
- OIDC access, ID and refresh tokens (if applicable)
- Session metadata and internal storage base data (such as keys and timestamps)
In OIDC scenarios, session sizes typically range around 3,600 bytes, though actual size may vary based on implementation details and token claim contents.
To estimate total memory usage, you can apply the following formula:
Total memory ≈ average session size × number of concurrent sessions × safety margin
A 10 % buffer is usually sufficient in non-clustered setups.
Redis example
If Redis is used for session storage, its memory usage depends on the deployment mode:
- Standalone mode, consumes memory that scales linearly with the number of sessions. For base data, add ~10 % to the calculated total memory.
- Sentinel mode has a memory usage that is comparable to Standalone mode, with minimal additional memory consumption for Sentinel nodes. Replication increases the total memory usage.
- Cluster mode incurs a higher base data footprint. Testing indicated a ~40 % increase. For planning, apply a 50 % base data margin.