Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Analytics Cloud performance: diagnose the layer before touching anything

As of 2026-08-14

A slow SAC story is almost never an SAC problem. It is a story-design, model-design or source-query problem that surfaces in the client, and the common mistake is tuning the layer with the least leverage — browser and display settings — while an unbounded query or a stacked calculated measure goes untouched. Work down the stack in order and the fix is usually one decision, not a campaign.

The three layers that carry the leverage

Story design is the first: widget count per page, filter depth, table row and column volumes, and input controls that re-render on every change. It is the cheapest to change and where the twelve-widget and five-filter budgets earn their keep.

Model design is the second: connection mode, the number of dimensions and measures, calculated and restricted measures, and dimension cardinality. Most of the real leverage sits here, because a model decision multiplies across every story built on it.

Source query execution is the third: the Analytic Model and the views beneath it, the execution plan, result size and network round trip. On a live connection this layer sets the ceiling for everything above it.

Reading the symptom before changing anything

The diagnostic question is whether time is spent waiting for data or drawing it, and the answer routes you to a layer.

Slow to respond but quick to draw points at the source — the model, the view beneath it, or the query plan. Fast to respond but slow to draw points at the client: too much on the page, too many rows in a table, too many widgets competing. That is a story-design fix, not a platform one.

Everything slow at once points at something every widget shares — a heavy calculated measure each one re-executes, or the connection itself. One widget slow alone points at what that widget specifically asks for; compare its dimensions and measures against a fast neighbour on the same page.

Decision table — symptom to first move

Page takes seconds to load, many widgets → cut to twelve widgets or split by audience → on a live connection every widget is a query fired at once.

Each filter click hangs → shorten the cascade to five levels, or use a page-level filter when three or more widgets share the same scope → it is pushed once instead of chaining sequential re-queries.

The whole story is slow regardless of interaction → look for stacked calculated measures → push restricted and calculated measures down to the Analytic Model so aggregation happens at the source.

Fast in the pilot, slow after rollout → revisit the connection mode → live scales to roughly two hundred concurrent ad-hoc users per Analytic Model, and nothing warns you on the way.

Slow only at month end on a large history → add a mandatory date-range filter → an unbounded query over a partitioned fact table is a different query, not a slower one.

Where the model decisions bite

Calculated measures execute at query time, so a measure referencing several others causes all of them to be fetched. Ten widgets each referencing three calculated measures generate a page load pulling far more measure columns than the design implies, and the growth is invisible until the story gets wide.

The fix is to push the calculation down. Defining a restricted measure in the Analytic Model means the restriction is applied during aggregation at the source, so one aggregated number arrives per row instead of SAC fetching rows and filtering afterwards. This is the highest-leverage single change in most tuning engagements.

What we cannot assert

The widget, filter and concurrency budgets here are delivery heuristics recorded in our corpus, not product-enforced limits, and the right numbers for a tenant depend on model complexity and query shape. We publish no benchmark timings, because a timing without its model and data volume is not reproducible.

Frequently asked

Why is my SAP Analytics Cloud story slow?

In order of likelihood: too many widgets on the page, a filter chain deeper than five levels, calculated measures left in the story or stacked in the SAC model instead of pushed to the Analytic Model, or a live connection serving a wider audience than live mode scales to. Diagnose which layer the time is spent in before changing any setting.

Does switching from live to import fix performance?

It fixes a concurrency problem and can fix a wide-audience dashboard, at the price of a staleness window and the loss of inherited row-level access — every user with story access sees every imported row. That rules it out for governed reporting in a regulated domain, whatever it does for the timings.

Where should calculated measures live?

In the Datasphere Analytic Model, so the calculation and any restriction are applied during aggregation at the source and one aggregated number reaches the front end. Stacking them in the SAC model means every widget referencing them pulls all the underlying measure columns.

What this page is built on

Read next