Overview

This guide explains how Arc connects to IBM Planning Analytics (TM1), what network and security considerations apply, how to size and minimize impact on servers, and how to plan and monitor for peak concurrency.

1. Arc Connectivity to TM1 / Planning Analytics

1.1 Components and prerequisites

• Arc application: Self-contained service (single executable) running on Windows, Linux, or macOS. No agent or plugin is installed on TM1.

• TM1 REST API enabled: Ensure HTTPPortNumber is set in tm1s.cfg and the service is reachable over HTTPS/HTTP as per your security policy.

• Client requirements: Modern web browser for Arc UI. If using Slice (Excel add-in), it connects via Arc Server.

• Recommended placement: Install Arc on the same host as TM1 or a low-latency server in the same LAN/VPC to reduce request latency and avoid cross-firewall hops.

1.2 Network, firewall, and proxy rules

• All communication is TCP over HTTP/HTTPS. Prefer TLS with trusted certificates for Arc and TM1 REST.

• When Arc and TM1 run on the same host, Arc→TM1 traffic stays local; lock down external exposure of the TM1 REST port.

• If a proxy is used, allow pass-through to TM1 REST and Admin Host endpoints; preserve headers and cookies.

1.3 Connection model and session management

• Session-based: Arc authenticates to TM1 via REST and receives a session token/ID that is reused until timeout or logout.

• No persistent sockets: Requests are stateless HTTP(S); no WebSockets or long-lived TCP tunnels.

• Independent timeouts

  • TM1 REST session: controlled by HTTPSessionTimeoutMinutes in tm1s.cfg.

  • Arc browser/server session: configurable in Arc settings (e.g., settings.yml), which governs UI inactivity and request timeouts.

• Re-authentication: On session expiry, Arc prompts or seamlessly re-authenticates depending on configuration and SSO settings.

2. Server and Network Burden (Sizing and Impact)

2.1 Network utilization patterns

• On-demand REST: Traffic occurs when users perform actions (open cube views, run processes, edit rules/dimensions). No constant background polling from the UI.

• Typical payload sizes

  • Metadata listings (cubes, dimensions, processes): small (KBs).

  • Cube views/MDX: variable; can reach MBs depending on sparsity, filters, view size, and compression.

  • Process execution and logs: modest request size; response can grow with log verbosity and output volume.

• Caching: Arc UI may cache lightweight UI state; authoritative data always retrieved from TM1 REST to ensure consistency.

2.2 Performance considerations for large models

• REST session pressure: Many concurrent or idle sessions can slow REST responses. Tune HTTPSessionTimeoutMinutes to retire idle sessions promptly.

• Large dimensions and subsets: Operations that enumerate or filter very large hierarchies can increase response times; prefer narrow subsets and security-filtered views.

• Large cube views/MDX: Govern with MaximumViewSize and encourage filtered slices to reduce thread usage and payload size.

• Server logs and I/O: Oversized tm1server.log and excessive backups can affect REST responsiveness; rotate and cap sizes.

• TI processes and rules: Long-running TI and complex feeders/rules consume threads and can block REST requests; schedule intensive jobs during off-peak windows.

2.3 Arc server resource profile

• Lightweight footprint: Primarily serves static UI and proxies REST requests; CPU/RAM use is low relative to TM1.

• Indicative baseline

  • CPU: 2 cores minimum (4+ recommended for teams or Slice usage).

  • RAM: 8 GB for small teams; increase if hosting Slice for many users.

  • Disk: 100 GB to accommodate logs, updates, and temporary artifacts.

2.4 Best practices to minimize impact

• Co-locate Arc with TM1 or on the same low-latency network segment.

• Centralize Arc for teams to simplify governance and reduce redundant sessions.

• Tune HTTPSessionTimeoutMinutes to clear idle REST sessions faster without disrupting active users.

• Cap tm1server.log size and backup indices; enable log rotation.

• Constrain view sizes (MaximumViewSize), encourage MDX filters, and avoid "show all" in large cubes.

• Schedule heavy TI/rule recalcs outside peak development windows; separate dev/UAT/prod Arc environments to reduce cross-impact.

• Leverage TM1 performance settings: MTQ, ParallelInteraction, PersistentFeeders, and well-designed hierarchies.

3. Peak Concurrency Usage

3.1 Recommended concurrent users per TM1 instance

• Arc itself has no strict concurrency cap; practical limits are determined by TM1's ability to service REST sessions and threads.

• As a planning guideline, size for the number of active developers/analysts likely to run simultaneous REST-heavy actions (opening large views, running TI, saving rules) rather than total named users.

3.2 Behavior under high concurrency

• Session-per-user: Each logged-in Arc user holds a TM1 REST session; Arc does not pool user identities.

• No aggressive client throttling: Arc relays requests; TM1 back-pressure (thread waits/locks) is what users experience as slowness or timeouts.

• Timeouts and retries: Request timeouts are configurable in Arc settings; failed requests surface to users for manual retry.

3.3 Practical limits and bottlenecks

• TM1 REST sessions: Excess idle or concurrent sessions degrade performance; tune session timeouts and close unused browsers.

• Thread utilization: Each REST action consumes TM1 threads; contention increases wait times. Monitor running vs waiting threads.

• View size constraints: Use MaximumViewSize to prevent excessive view expansions that monopolize resources.

• Locking: Write-heavy actions and feeder recalcs can block readers; enable ParallelInteraction and optimize rule/feeders design.

3.4 Monitoring metrics to validate peak usage

• Sessions: Active vs idle REST sessions; session churn at peak times.

• Threads: Running, waiting, commit/rollback; average wait time per request.

• CPU and memory: Sustained CPU saturation or memory pressure correlates with REST latency.

• Network throughput: REST bandwidth spikes during large view fetches and TI uploads/downloads.

• Response times: Median and P95/P99 for key REST endpoints (login, metadata, view retrieval, TI execution).

• Lock contention: Waiting percentage and "others waiting" indicators to identify blocking users or objects.

Implementation Checklist

FAQ