Elevated Latency observed in CA Advanced Authentication Risk REST API

Products

• CA Risk Authentication

Issue/Introduction

You may observe elevated latency in Risk Evaluation calls (Risk Authentication), with transaction times ranging from several minutes to over 20 minutes (e.g., 1,400,019 ms).

• The latency typically follows a "queue drain" pattern: the first request in a burst shows the highest latency, which then steadily decreases for subsequent sequential transactions.
• Risk Authentication server-side logs show normal processing times (60–200ms), but REST API logs (RFPerfLogger) show massive delays between Txn-Begin and Txn-End

Environment

Risk Authentication

Release: 9.1.5.x

Cause

The root cause is typically located in the REST API application tier rather than the Risk Authentication evaluation engine. Specifically:

1. Disabled Connection Pooling: When USE_CONNECTION_POOLING=0, every transaction must perform a full TCP 3-way handshake, leading to overhead and ephemeral port exhaustion under load.
2. Thread Pool Saturation: Without pooling, the HTTP thread pool becomes blocked or saturated during burst traffic, causing incoming requests to queue before being dispatched to the Risk Authentication server.
3. Database Lock Contention: Concurrent parallel requests for the same user can cause a lock contention on the ARRFUSERCONTEXT table, triggering a default 1-second sleep retry cycle that adds significant latency.

Resolution

REST API Configuration Tuning

Update the rest-api.properties file with the following performance-optimized settings:

Property	Recommended Value	Description
USE_CONNECTION_POOLING	1	Mandatory. Enables connection reuse to eliminate TCP handshake overhead.
MAX_WAIT_TIME_MILLIS	5000	Sets a 5-second limit for a request to wait for a pooled connection.
MAX_IDLE	32	Limits idle connections to prevent firewall timeouts and stale connections.
READ_TIMEOUT	5000	Reduces the block time to 5 seconds if the Risk server is unresponsive.

2. Risk Authentication Database Configuration (ARRFCONFIGURATION table)

To mitigate latency caused by parallel user request lock contention, update the following keys in the ARRFCONFIGURATION table:

• GLOBAL_DBQUERYRETRYCOUNT: Set to 3 (from default 1). Increases attempts to acquire a lock after the first failure.
• GLOBAL_DBQUERYRETRYINTERVAL: Set to 0 (from default 1). Eliminates the 1-second sleep penalty between retries.
• GLOBAL_USERLOCKEDTIMEDIFF: Set to 5 (from default 120). Reduces the duration after which a stale user lock is forcibly released.

3. Verification

• Restart the Application Server for changes to take effect.
• Monitor Logs to ensure Time= values return to expected sub-second levels during peak traffic.