How Scalable Is SecureVisio? SIEM/XDR Performance and Scaling Explained

SecureVisio is a SIEM/SOAR/XDR-class platform designed to receive, parse, store, and analyze data from a large number of sources. Its modular architecture lets you start with a single service stack and then either grow its resources or add further collectors as log volume, the number of sources, and the number of security rules increase.

Key principle: The performance of the SecureVisio LogCollector should never be judged on the EPS figure alone. The real capacity of an environment also depends on the complexity of parsers and rules, disk speed, the number of searches, retention length, and short-term load spikes.

SIEM performance is more than an EPS number

The real-world capacity of an environment is shaped simultaneously by:

• the size and complexity of incoming logs,
• how those logs are parsed,
• the number and complexity of security rules,
• the performance of the disk subsystem,
• the number of searches running concurrently,
• retention length, the number of sources and collectors,
• short-term spikes in traffic volume.

This is why two environments receiving the same number of EPS can require a different number of servers and different resources. Simple syslog messages can be processed far faster than large, multi-field events that require complex parsing and evaluation against numerous correlation rules.

Inside the modular LogCollector architecture

The core data-processing element in SecureVisio is the LogCollector. It is not a single service but a set of components, each responsible for a successive stage of log handling:

• CollectorController – manages the LogCollector components and distributes configuration to the other services.
• LogForwarder – receives logs passively (e.g., via SYSLOG) or actively through API connectors. It then identifies the source, parses the received data, and passes it on for further processing.
• FrameStore – stores parsed logs and the data needed to search them later, and makes them available to other services.
• PolicyEngine – retrieves logs and evaluates them against the security rules assigned to the relevant policies and sources. This is where correlation takes place, producing security events.
• EventStore – stores the events created by the PolicyEngine and makes them available to the rest of the system.
• LogAnomalyDetector – analyzes events for anomalies related to, among other things, users and assets.

Splitting the pipeline into separate services means resources can be added exactly where the load appears. If receiving and parsing data is the bottleneck, the LogForwarder layer can be expanded. If rule execution is the constraint, the PolicyEngine can be separated out or given more resources. If writes are the problem, FrameStore, EventStore, and disk performance become the critical factors.

How many EPS can SecureVisio handle?

The performance of the standard LogCollector architecture — with a typical service split and the recommended resources — is rated at approximately 20,000 EPS.

The full process covered by this figure includes:

• receiving, parsing, and writing frames,
• executing security rules,
• creating and writing events,
• building and updating information in the CMDB,
• anomaly analysis,
• building indexes, searching, and reporting.

It is assumed that after logs have been parsed and stored, and after rules have separated out traffic that is irrelevant from a security perspective, roughly 35% of all logs reach the correlation engine.

Final sizing should always be performed using data that reflects the specific organization.

Reference architecture for ~20,000 EPS

For an environment with a capacity of up to around 20,000 EPS, the recommended approach is to split the collector services across three machines:

Server	Services	CPU	RAM
SV-COL 01	CollectorController, FrameStore	10 vCPU	16 GB
SV-COL 02	PolicyEngine, EventStore, LogAnomalyDetector	24 vCPU	24 GB
SV-COL 03	LogForwarder	12 vCPU	10 GB

The recommended processors for the LogCollector in this scenario are Intel Xeon 24C/32C or AMD EPYC 24C/32C, with a minimum clock speed of 2 GHz per core.

Each machine should be provisioned with a 100 GB SSD system disk. For the FrameStore, space for active logs is estimated at roughly 80–100 GB per day of retention. For active events, a value of around 10 GB per day is assumed. Exact requirements depend on log size, compression ratio, the number of events created, and the retention policy.

This is a reference configuration, not a hard limit. Individual services can run on shared servers or be split across separate machines when the load profile requires it.

Keep in mind that depending on the types of log sources and the formats transmitted (SYSLOG, JSON, XML, and others), the volume of logs this architecture can ingest may vary.

Vertical scaling: more resources for existing services

The simplest way to increase the capacity of an existing collector is vertical scaling — adding vCPUs, RAM, and disk performance.

For a LogForwarder handling around 5,000 EPS, an example configuration is 8 vCPU and 8 GB RAM. When growing to around 10,000 EPS, an increase to roughly 10 vCPU and 10 GB RAM can be considered. This relationship is not linear, however, because parsing time depends on the log format and the parser in use.

CPU performance is determined not only by the number of cores but also by their speed. Adding more vCPUs increases the number of operations executed in parallel, while a higher clock speed shortens the time needed to process a single log or execute a specific rule.

This matters particularly for:

• complex parsers,
• rules containing many conditions,
• operations executed sequentially on a single frame,
• virtualized environments with heavy sharing of physical CPUs.

A high vCPU count will not always deliver the expected performance if the hypervisor is overloaded, the processors run at low clock speeds, or the virtual machine spends a long time waiting for CPU time to be allocated.

Horizontal scaling: adding LogForwarders and full collector stacks

At higher loads, the recommended way to expand is horizontal scaling — adding entire stacks of LogCollector services.

SecureVisio allows you to:

• install additional LogForwarders,
• move selected sources to separate LogForwarders,
• add full collector stacks,
• place collectors in different locations,
• apply separate retention policies to individual collectors.

An additional LogForwarder can run close to the log sources, including in a network-separated location. It then receives data locally, parses it, and sends it on to the central FrameStore. This reduces traffic between locations and distributes the parsing load.

The number of LogForwarder services assigned to a given stack is not architecturally limited. When data growth is larger, entire collectors can be added instead. The architecture, the number of collector services, the EPS volume, and the storage space allocated to logs are not treated as licensing limits in SecureVisio.

Queues that absorb short-term load spikes

The collector services use queues that decouple the successive processing stages. In a typical flow, data is:

1. received,
2. processed,
3. passed on to the next service.

The default queue size can be 1,000,000 elements and is configurable. If more logs arrive momentarily than a service can process, the data can wait in the queue until the load subsides.

Important: Increasing a queue does not increase the sustained throughput of a service. What it does is absorb a short-term surge of incoming logs — a spike — without dropping data. If the log inflow exceeds processing capacity for an extended period, the queue will eventually fill up as well.

Queue sizes can be set during deployment, after first verifying how often spikes occur and how long they last. In that case, RAM must also be increased accordingly. For the LogForwarder service, filling a buffer of 1,000,000 records can consume an additional 3–5 GB of RAM.

Queue elements are held in RAM, so enlarging a queue should always go hand in hand with providing an adequate memory reserve.

Disks, IOPS, and data retention

FrameStore and EventStore write data to files, so the amount of available space directly determines retention length. SecureVisio distinguishes between:

• ONLINE data, available directly in the system’s built-in browsers,
• ARCHIVE data, accessible through the archive browsers.

For active logs and events, SSD/NVMe disks delivering at least around 5,000 IOPS are recommended. Archive data, which is read less frequently, can be kept on slower disks or on a separate storage area.

In practice, disk performance simultaneously affects:

• writing new logs and indexes,
• archiving,
• searching,
• data reads by the PolicyEngine,
• writing events and anomaly-analysis results.

If the FrameStore or EventStore write queue starts to fill up despite available CPU and RAM, the cause may be an insufficient number of disk operations, high storage latency, or an array shared with other workloads that put load on it.

Security rule performance in the PolicyEngine

The PolicyEngine executes security rules for the logs covered by a given policy. Its load depends not only on the EPS count but also on:

• the number of active rules,
• the number of conditions per rule,
• the order of conditions within a rule,
• the functions used, e.g., functions based on CMDB context,
• how frequently conditions are matched,
• the types of fields being analyzed,
• the log volume sent by individual sources.

A single unoptimized rule can consume significantly more time than all the others and cause the execution queue to grow.

The system also provides SPAM rules, which determine the relevance of logs for further correlation. The logs are still parsed and stored. These rules can also redirect parsed frames to another collector for further correlation.

Fast search with indexed fields and cSQL

SIEM platform performance also covers the speed of access to the data already collected. SecureVisio supports index-based searching for selected schema fields, such as:

• SrcIP and DstIP,
• SrcName and DstName,
• SrcUserName and DstUserName,
• SrcProcessName and DstProcessName,
• Message and ReqURL,
• DstFileHash and DstPort,
• ClassCategory and ClassAction.

Queries can be executed using cSQL syntax or full-text search. Using an index dramatically reduces the amount of data that has to be read and analyzed.

For a cSQL query to take advantage of an index, it should, among other things:

• use indexed fields only,
• cover a time range for which indexes exist,
• use supported comparison operators,
• avoid unsupported functions and constructs.

In the SecureVisio operator console, indexed fields are shown in blue in the log browser.

Multi-search across distributed collectors

In distributed environments, the browser operates in multi-search mode by default. A query is then executed simultaneously on multiple selected collectors, and the results are merged, sorted, and presented in a single view.

Multi-search supports:

• cSQL syntax,
• advanced SELECT queries,
• aggregations,
• full-text search,
• merging results from multiple collectors.

As a result, adding further stacks does not mean having to search each one manually. The architecture can be distributed while the results remain available from a single interface.

What determines real-world SecureVisio performance?

The most important factors influencing the system’s capacity are:

• the number and size of logs,
• parser complexity,
• the number of security rules and their execution time,
• the number of sources assigned to a single LogForwarder,
• CPU speed and vCPU availability,
• the amount of RAM,
• disk performance,
• the number of concurrent queries,
• retention length,
• short-term EPS spikes,
• network communication between services.

For this reason, reference values should be treated as a starting point. The most reliable sizing is prepared on the basis of a sample of real logs, the list of parsers and rules to be deployed, and the planned retention.

Summary

SecureVisio can be scaled from a single environment handling a few thousand EPS up to a distributed architecture with multiple LogCollector stacks.

An organization can increase the resources of a specific service, deploy an additional LogForwarder, or attach another full collector stack. Queuing, indexing, multi-search, and the separation of online and archive data help maintain stability both during live processing and later data searches.

There is no single EPS value that describes every deployment. Correct sizing requires accounting for the entire processing chain: from ingestion and parsing, through correlation, to storage, retention, and data search.