The TM1 REST API /Sessions endpoint currently provides information about active user sessions, but it does not expose resource consumption or cumulative workload statistics for individual sessions.
This makes it very difficult for administrators to identify which user, PAW book, application, or API client is responsible for high memory consumption or workload on a Planning Analytics database.
This is particularly problematic with Planning Analytics Workspace (PAW). A PAW book can generate many very short-running queries. These jobs may exist for only milliseconds and therefore frequently disappear before they can be observed through the /Jobs or /Threads endpoints.
At the same time, memory allocated as a result of user queries or session-scoped objects can remain allocated after the originating job has completed.
The /Metrics() endpoint provides valuable database and replica-level memory information, but there is currently no way to attribute this memory consumption to a specific session or user.
Enhancement Request
Extend the TM1 REST API Session entity with resource usage and cumulative performance counters.
For example:
MemoryUsed
PeakMemoryUsed
CellsetMemoryUsed
QueriesExecuted
JobsExecuted
QueryCPUTime
QueryElapsedTime
CellsCalculated
LastActivity
An extended /Sessions request could then provide information such as:
Session User MemoryUsed PeakMemory Queries CPUTime LastActivity
---------------------------------------------------------------------------------
81273... UserA 3.4 GB 4.1 GB 12,482 87.2 s 09:42:15
73918... UserB 842 MB 1.2 GB 3,102 21.4 s 09:42:13
91827... APIUser 126 MB 310 MB 428 4.8 s 09:41:58
Ideally, the counters should be cumulative for the lifetime of the session so that short-running jobs do not have to be captured through high-frequency polling.
The information should be available through the standard TM1 REST API, for example:
GET /api/v1/Sessions
or through an expanded session statistics entity such as:
GET /api/v1/Sessions?$expand=Statistics
Business Value
This enhancement would significantly improve the ability to:
- identify users or sessions responsible for high database memory consumption;
- troubleshoot memory growth caused by PAW books and dashboards;
- analyze workloads consisting of very short-running queries;
- identify expensive reports, applications, API clients, and user activity;
- correlate session activity with database-level /Metrics() information;
- perform capacity planning and performance analysis;
- diagnose performance issues without continuously polling /Jobs or /Threads.
Currently, /Jobs and /Threads only provide a snapshot of active work. For PAW workloads, many requests complete between polling intervals and are therefore never observed.
Adding cumulative resource and performance statistics to /Sessions would close this monitoring gap and provide administrators with a reliable way to attribute resource consumption to individual user sessions.
Use Case
An administrator observes that database memory usage increases by several GB after users open a complex PAW dashboard.
/Metrics() shows the increase in database memory, but /Jobs often shows no corresponding activity because the individual PAW queries have already completed.
The administrator currently cannot determine which session caused the memory allocation.
With session-level memory and cumulative performance counters, the administrator could immediately correlate:
Database → Session → User → Resource Consumption
and identify the workload responsible for the increase.
+1
Another benefit would be being able to correlate session statistics over time with database-level resource metrics.
For example, if /Metrics() shows a gradual memory increase, cumulative session counters could help determine whether this is associated with a specific user session, PAW application, or API client.
This would make the REST API useful not only for troubleshooting an issue after it occurs, but also for identifying workload patterns and supporting capacity planning over longer periods.
+1
The PAW use case is particularly relevant here.
A single PAW book can generate a large number of short-running requests that may complete before an administrator can observe them through /Jobs or /Threads. However, the resulting memory or workload impact can remain visible at the database level.
Having cumulative session counters such as query count, CPU time, elapsed time and peak memory would make this activity observable even after the individual jobs have disappeared.
For me, that would turn /Sessions from a list of active sessions into a much more useful monitoring interface for workload attribution and capacity analysis.
+1
This would be a very useful enhancement from an administration and troubleshooting perspective.
The key point for me is the attribution gap between database-level metrics and individual workloads. /Metrics() can show that memory is growing, while /Jobs and /Threads only show what is active at the moment of observation.
Session-level cumulative counters would provide the missing link:
Database → Session → User → Workload
This would make it much easier to investigate memory growth and performance issues without having to continuously poll short-running requests.