/
Time-Out Parameters and Impact

Time-Out Parameters and Impact

Time-Out Parameters and Impact

This page explains the different time-out settings that affect ARC connections to Planning Analytics (TM1), how they interact, typical symptoms when limits are hit, and how to tune them for reliable performance in various environments (on‑prem, IBM Cloud, VPN/remote).

Who is this for? TM1 administrators, Arc/Slice owners, and power users who experience unexpected disconnects, forced re-logins, or interrupted refreshes in Slice.

1) Where Time-Outs Come From

Multiple layers can terminate an idle or long-running ARC/Slice session. A shorter limit at any layer will dominate:

  • Excel Add-in (Slice client) behavior and request strategies

  • Arc server session time-out (when connecting remotely via Arc)

  • TM1 REST API time-outs and instance connection settings

Principle: The lowest effective idle or request time limit along the end-to-end path determines when a user experiences a disconnect.

2) Key Parameters to Review

2.1 Arc Server Settings (when Slice connects remotely via Arc)

  • sessiontimeout (Arc): Maximum idle time before Arc ends the user session.

  • timeoutseconds (per connection): Maximum request duration allowed by Arc for a TM1 instance call.

Reference: ⚙️ Arc Configuration & Settings

2.2 TM1/REST and Infrastructure

  • TM1 REST API: Long-running view queries, large picklists, and complex MDX can exceed request time limits.

3) Symptoms and How to Diagnose

  • Idle disconnect around 5–15 minutes: Session ends despite long time-out values in Slice/Arc. Often a proxy/VPN idle timer or Arc sessiontimeout shorter than expected.

  • “Refresh instances” required after break: The Arc session or TM1 bearer token expired. Re-authentication is needed.

  • Refresh fails during heavy queries: Request-level time-out (Arc timeoutseconds, proxy request time-out, or REST gateway limit).

4) Tuning Guide by Scenario

4.1 Users connect via Arc over VPN/Proxy

  • Increase Arc sessiontimeout to align with business needs (e.g., 60–120 minutes), but

  • Ensure the proxy/VPN idle timer is equal or higher; otherwise, the network will still drop sessions early (commonly at 300–900 seconds).

  • Keep Batch Requests enabled to reduce chattiness over high‑latency links.

  • Consider enabling Use Async Requests if you still see request time-outs, especially on IBM Cloud.

4.2 On‑prem LAN users with sporadic time-outs

  • Leave Use Async Requests off unless there are proven REST time-outs.

  • Validate Arc timeoutseconds covers the slowest realistic query (e.g., 120–300 seconds).

5) Practical Settings Checklist

Confirm whether Slice connects directly to TM1 REST or via Arc; document the path.
In Arc settings, set sessiontimeout to the desired idle window and timeoutseconds to exceed your longest query by a safe margin.

6) Impact of Time-Out Choices

If Time-Outs Are Too Short

  • Frequent “refresh instances” or re-login interruptions

  • Failed long-running refreshes; partial data shown

  • User frustration and higher support volume

If Time-Outs Are Too Long

  • Stale sessions consume resources

  • Harder to detect dead connections

  • Potentially longer wait before a failed request returns to the user

Balanced approach: Idle session 60–120 minutes for business users; request time-out comfortably above the 95th percentile of query durations (e.g., P95 + 50%). Keep observability on via logs.

References:

FAQ

A downstream device (VPN, reverse proxy, load balancer) likely enforces a shorter idle or request limit. The smallest limit in the chain wins. Coordinate with network admins to raise those thresholds.

Enable on IBM Cloud or when you see request time-outs. For on‑prem with stable networks, keep it off unless needed to avoid overhead and complexity.

Idle session: 60–120 minutes depending on user patterns. Request: P95 query duration + 50% headroom (often 120–300 seconds). Validate with logs and adjust.