Performance benchmark 3.29

This topic provides empirical performance benchmark data, hardware sizing baselines, and deployment topology recommendations for OneSpan Authentication Server 3.29. The figures herein reflect measurements conducted across supported database management systems (MariaDB and Oracle Database) deployed in containerized Kubernetes environments running on modern Linux operating systems.

Test environment and system specifications

Hardware and cluster infrastructure

• Kubernetes nodes: Dedicated multi-core performance worker nodes, with different pod/vCPU configurations

• Database host sizing: Tested across 2, 4, 6, and 8 vCPUs (4 vCPUs identified as the baseline production recommendation)

Software environment and versions

• Operating system: Ubuntu 24.04 LTS (64-bit)

• Application versions: OneSpan Authentication Server 3.29.1

• Database systems:

  • MariaDB: MariaDB 11.8 LTS

  • Oracle Database: Oracle 19c Enterprise Edition

• Directory services: OpenLDAP

Test automation

The performance results were gathered by running JMeter test suites and automatically collecting container CPU and memory telemetry .

Test scenarios and workload profiles

Performance measurements were gathered against a benchmark population of 30,000 users across different workload profiles, running test cases for 120s average with 10, 50, and 100 concurrent threads.

The scope included to collect overall latency and throughput for different configurations, analyze bottlenecks, and identify optimal pod/CPU ratio and saturation limits.

Performance benchmark results

The following tables summarize average response times and 90th percentile (P90) response times under maximum throughput conditions. All response times are measured in milliseconds (ms).

Authentication operations response times (ms)

SOAP administrative operations response times (ms)

Throughput and maximum capacity (transactions/second)

Deployment sizing & recommendations

Database sizing

• Baseline allocation. 4 vCPUs provides the optimal price-to-performance ratio for standard deployments.

• Scaling ceiling. Increasing database allocation from 4 vCPUs to 8 vCPUs on a standard 2-pod OAS setup yields marginal throughput gains (<5%), as application connection limits become the constraining factor before CPU exhaustion.

Kubernetes pod vs. CPU allocation

When planning container resources for OAS/IAS instances:

• Proxy overhead. A single pod with 2 CPUs achieves higher efficiency and lower latency than 2 pods with 1 CPU each, mainly due to multi-pod network proxy overhead.

• Optimal production ratio. The recommended baseline configuration for both DBMS is 2 pods with 5 CPUs each. It maximizes balance of throughput, response time, and stability.

  • MariaDB outperforms Oracle in throughput (~2x), response time (~40% faster), and error rate.

  • 10 Pods with 1 CPU each is worst for both. Network overhead between pods dominates.

  • 1 Pod with 10 CPU offers diminishing returns. This is only marginally slower than 2 pods for both DBMS.

  • 5 Pods with 2 CPUs underperforms. Network overhead is already significant at this ratio.

• Cluster saturation limits (4 vCPU DBMS)

  • Oracle 19c: Database CPU reaches 100% saturation at 5 OAS pods under heavy concurrent load (50+ threads).

  • MariaDB: Database saturation occurs at 5 to 6 OAS pods under heavy concurrent load.

Version comparison: 3.28.1 vs. 3.29.1

Performance regression testing was conducted across both MariaDB and Oracle 19c environments to evaluate latency, throughput, and stability differences between OneSpan Authentication Server 3.28.1 (baseline) and OneSpan Authentication Server 3.29.1 under identical 30,000-user load workloads.

Note that MariaDB was upgraded from version 10.11 LTS in OAS 3.28 to 11.8 LTS in OAS 3.29.

Benchmark comparison by operation (Average response time, in ms)

Key results

• Optimized OTP processing (MariaDB). Version 3.29.1 introduces measurable latency improvements in Digipass OTP validation workflows when using MariaDB, dropping average response times from 44 ms down to 38 ms.

• Engine stability across minor releases. Read/view operations and static password authentications show consistent execution timings across both releases, indicating no regressions in query performance or indexing overhead.

• Oracle 19c parity. Oracle 19c exhibits near-identical response time profiles between 3.28.1 and 3.29.1 across all standard authentication paths, maintaining predictable throughput characteristics.