DataSunrise’s Performance Under High Traffic Conditions
DataSunrise is frequently queried about its performance when handling traffic volumes that exceed typical limits. Clients are particularly concerned about whether DataSunrise will drop traffic, experience delays, or manage the situation differently. This guide explains how DataSunrise handles high-traffic conditions and which system components may become bottlenecks.
Operational Capacity and Performance Metrics
DataSunrise performance depends on the server hardware, number of proxies, enabled rules, audit configuration, database latency, and network conditions. The current recommended hardware configuration is based on the estimated database traffic volume:
| Estimated database traffic volume | CPU cores* | RAM, GB |
|---|---|---|
| Up to 6,000 operations/sec | 2 | 8 |
| Up to 11,000 operations/sec | 4 | 16 |
| Up to 19,000 operations/sec | 8 | 32 |
| Up to 30,000 operations/sec | 16 | 64 |
| Up to 40,000 operations/sec | 32 | 128 |
*Based on Xeon Platinum 8488C 3.2 GHz.
These values should be treated as general sizing guidance. Actual throughput may vary depending on the workload, SQL complexity, rule configuration, audit storage performance, and network latency. The more proxies you open, the higher the RAM consumption you should expect.
Identifying and Managing Bottlenecks
Audit System Bottlenecks
If the Audit Storage cannot keep up with a spike in traffic, DataSunrise uses an internal queue within its Audit Journal system. The queue can handle several thousand events depending on system settings. For details, refer to the AuditHighWaterMark parameter.
If traffic spikes exceed the queue capacity, events may be rejected. This default behavior can be changed so that DataSunrise waits until there is space in the queue to log new events. For details, see the AuditPutThreadQueueWait parameter. During this wait, application traffic may be temporarily halted, usually for milliseconds to seconds, depending on audit storage performance.
To optimize the audit system, consider the following:
- Increase audit database performance by selecting servers with more CPU and memory.
- Check network latency. Ideally, the DataSunrise host and Audit Storage should be in the same subnet.
- Review rules and audit events so that only events required by your security and compliance policies are logged.
DataSunrise Parsing System Bottlenecks
If the audit system is working correctly, CPU usage becomes the next potential bottleneck. The handling mode, passive or active, affects how traffic spikes influence the application.
- Passive Mode. Traffic is handled asynchronously in a separate pool of threads before being resent to the server. Traffic is temporarily stored in an internal queue, which can buffer spikes and may improve application performance. For details, refer to the MessageHandlersGlobalQueueHighWaterMark and MessageHandlersLocalQueueHighWaterMark parameters. If this buffer fills, DataSunrise stops parsing new traffic on that connection and displays an alert in the Event Monitor. Application performance is not degraded in this case, but some events may be missed in the audit.
- Active Mode. Traffic cannot be handled asynchronously because DataSunrise must make real-time decisions about operations. No queues are used, and performance directly depends on CPU capacity. During traffic spikes, DataSunrise processes as much traffic as possible, which may increase application query latency.
Understanding these mechanisms and settings can help you optimize DataSunrise for high-traffic workloads and reduce the risk of performance bottlenecks.
For further reading on choosing the right database for audit storage and improving its performance, see How to Choose the Database for Audit Storage: A Performance Analysis.