CPU and Memory Usage
Core Engine Components
Engine CPU Utilization
The Nekuti Matching Engine is designed for high-performance, low-latency trading operations. Here are the key points regarding CPU usage:
Production Mode Characteristics
- Utilizes 4 CPU cores at 100% capacity
- Employs spin-waiting on I/O operations to minimize latency
- Optimized for core trading operations:
- Network reads/writes to gateways
- Command persistence
- Command execution
Performance Considerations
- CPU cache can become a bottleneck under high load
- Recommended hardware: Modern x86 processor with large CPU cache
- Performance can be further optimized for specific use cases and traffic patterns
- Contact our team for assistance with custom optimization
Engine Memory Usage
Memory consumption varies significantly based on several factors:
Baseline Requirements
- Minimal configuration (no instruments, no order flow): ~200 MB RAM
- Production environment: Variable, potentially several gigabytes
Scaling Factors
Memory usage scales with:
- Number of active instruments
- Market structure complexity
- Trading volume
- Order repository purge frequency
Real-world Example
A typical production deployment processing:
- 10 million orders per day
- 10 instruments
- Consumes approximately 4 GB RAM
Snapshotter Resource Usage
The snapshotter component is responsible for state persistence and operates with the following characteristics:
Processing Model
- Single-threaded execution
- Periodic command file processing
- Dormant between snapshot generations
Resource Consumption
- Memory footprint: Equivalent to the engine (~200 MB minimum)
- CPU: Single thread utilization during active snapshots
- Idle resource consumption is minimal during dormant periods
Edge Components
Gateway Resource Requirements
The Control Gateway and User Gateway serve as edge nodes providing REST and WebSocket APIs through Swagger and Glassfish Grizzly.
Memory Usage
- Minimal deployment: 1 GB RAM per gateway
- High-traffic deployment: 4-8 GB RAM per gateway
- User Gateway may require additional memory for handling hostile internet traffic
Internet-facing User Gateways should be provisioned with additional memory headroom to handle potential denial of service attempts and traffic spikes.
Scaling Considerations
Gateway resource consumption scales with:
- Number of concurrent connections
- Request frequency
- Payload sizes
- Authentication and validation overhead
Performance Optimization Tips
For optimal performance, consider these factors:
- Monitor CPU, I/O and Memory pressure
- Adjusting order repository purge frequency based on memory constraints
- Hardware selection focusing on CPU cache size
- Performance profiling under expected load conditions
- Gateway memory allocation based on expected traffic patterns