Manage and improve performance#

Distribute the load is about the hardware and where the work runs. This page is about the work itself: why an existing report, job, or form performs the way it does, and what to change.

When to use it. When a pack that used to finish in three minutes now takes twenty, when several people report slowness in the same week, when everything feels slower after an upgrade, or when you have been asked to make something faster and want to know where the time is actually going before you start changing things.

Before you start#

• Open a report's Run History from the workspace browser: the report row's ... menu, then Run history.
• The diagnostics tabs sit behind View diagnostics, which a view-only User account does not have. Authors and administrators reach them.
• Settings ▸ Performance is administrator-only and is not offered on a load-balancer node.
• Comparison needs history. A baseline needs at least 3 comparable earlier runs; a step-change search needs 6. A recently upgraded instance is thin until new runs accumulate.

Ask the questions in this order#

Four surfaces answer four different questions, and working from the outside in stops you optimizing the wrong thing. A report that regressed at the same moment as every other report on its node is not a report problem.

If contributors rather than reports are the problem, the equivalent funnel is per-server memory on Settings ▸ Performance ▸ Contribution, then a form's footprint in Campaign profiling. See Scale and size a contribution campaign.

1. Rule the instance in or out#

Settings ▸ Performance ▸ Distribution ranks every report against its own baseline and pivots the whole estate by product release and by execution node. It is the only surface that can see across reports, and it is where "did the upgrade do this" is answered.

Choose a window of 30 days, 90 days, or 1 year. Everything on the page, including the baselines, is recomputed inside that window, so a delta on screen is always explained by runs you can see.

Read the five figures first. Runs with telemetry tells you how much of the window is actually measurable, and a low percentage means the page below is thinner than it looks. Releases seen and Nodes seen tell you whether the pivots have anything to compare at all: one release or one node is nothing to compare.

Then read the two pivots at the foot of the page. Three rules govern them, and they are the reason a cell sometimes refuses to give you a verdict:

• A group is compared against the other groups, never against the overall median. A node that runs most of the work would drag an overall median toward itself and look normal however slow it was.
• A group needs at least 3 runs, and there has to be something to compare it with.
• Volume has to match. If a group processed more than 15 percent more or less data than the others, the cell reads "different volume" and gives no verdict. A release that looks 40 percent slower because its runs carried three times the data is not a regression.

A refusal to compare is information. It is the page declining to tell you something it cannot honestly know, and it is far more useful than a confident number built on three unlike runs.

The page distinguishes its two empty outcomes, which matters when you are diagnosing rather than browsing. "No runs in this window." means it read the history and found nothing, so widen the window or check that job-history logging is on. "Performance data is unavailable." means the read itself failed, and it shows what went wrong. Those are different problems and the page will not pass one off as the other.

Full field-by-field detail is in Compare performance across reports.

2. Find the moment a report changed#

The Elapsed vs baseline column answers "was the last run normal". That is the wrong question for a report that has been drifting for a fortnight, because every individual run looked fine against a baseline that was itself creeping upward.

The Compare tab asks the other question: across this report's whole history, is there a point where its typical run time changed? It searches for a single step and either finds one or says plainly that there is not one.

The verdict sentence is the whole answer, and it names a cause only when the data shows one. It will tell you whether volume moved across the same split, whether the release differs on either side, and whether the runs moved to a different node. "It got slower" and "it got bigger" are different findings, and this is the surface that separates them.

On a bursting job, use the scope picker to narrow to one variation. A whole-run total moves for reasons that have nothing to do with any one output: a burst list grew, a region was retired, a run was restricted to one recipient to test a fix. Each surviving output stays perfectly comparable with its own past even when the total does not.

See Find when a report got slower.

3. Break one run down#

The Performance tab leads with one sentence naming the dominant cost, then six figures, then a walk you can drill.

Read Elapsed with its volume denominator. Underneath the elapsed time sits the volume the run covered: data points where the run recorded them, otherwise the formula count. This is the first thing to check, because a report doing twice the work in twice the time has not regressed.

Walk from the run down to a phase. One ranked list, largest first, at three levels:

1. Whole run, listing the outputs it generated. This is where a burst tells you which output is expensive.
2. One output, listing the workbooks inside it.
3. One workbook, listing its processing phases. Phases are the last level, and this is where "the PDF took nine minutes" or "the refresh took nine minutes" gets settled.

At workbook level, two tails are listed apart from the ranked phases: phases that ran but cost nothing measurable, and phases that never ran at all. Keeping them separate matters, because "this workbook has no charts" and "charts were free" are different facts about the same run.

What each phase is#

The phase names are the vocabulary the whole surface is written in, so knowing what each one covers is what turns the ranked list into an action. These are the phases Reportworq expects a workbook to have, in roughly the order they run.

Data Refresh is almost always the largest, and it is the one that contains the recalculation loop, which is why the engine table below it matters more than the phase list. When something other than Data Refresh tops the list, that is the interesting result: a workbook dominated by Charts, Images, or Formatting is paying for its presentation rather than its data, and that is a different conversation with the author.

A few other phases can appear when the work applies to that report, such as parameter application, closing the workbook, or loading a non-Excel source document. They are ranked like any other; only the phases in the table above take part in the "never ran" tail.

The engine table is where the fixable problems are#

Below the walk, the Engines table lists one row per formula family and per calculation service, with Calls, Total, Avg, and Recalc passes.

Recalc passes is the column to read. It says once for an engine that ran a single time, or N of M for one that re-ran during recalculation. An engine reading 5 of 5 on a five-pass workbook ran on every pass, and Reportworq highlights that row when the pass count is high enough for it to be expensive.

That pattern is the single most actionable finding on the whole surface. A data retrieval repeated on every recalculation pass is usually a formula that can be restructured, not an unavoidable cost, and it is invisible from the durations alone: an engine can look cheap per call and still dominate a run because it is trapped in the loop.

Above workbook level the pass counts are folded together from the workbooks in scope, so 5 of 5 there reads as "in the recalculation loop the whole way" rather than as a run-wide total.

See Review a run's performance.

4. See what the time coincided with#

The Timeline tab re-projects the same run onto one clock: execution phases with their varieties nested beneath, per-workbook phase spans, event ticks, and the memory and CPU trace, all sharing one x-axis and one cursor.

It answers a different question from the other tabs. They say where the time went; this says what the time coincided with, which is the only way to see that the third data refresh landed on a memory spike.

Two readings are easy to get wrong:

• A hatched break in the CPU line is "not measured", never 0 percent. The opening stretch of every run is hatched, because the first sample has no interval to measure against. That is correct, not missing data.
• The expected-completion band is the expectation that stood when the run started, built from the runs before it, which is what makes an estimate on a finished run honest. It can legitimately extend past the end of the run, since an estimate built from a median is beaten by about half of all runs.

The tab also says when a cap has hidden detail, such as a very long run whose resource samples were thinned or a run with more spans than the chart draws. Read those notes before concluding that something did not happen.

The levers, and the order to try them#

Work top down. Everything above a line is cheaper and more reversible than everything below it.

Content: change what the work does#

What the breakdown will not tell you. It attributes cost to phases and engines, not to individual design choices, so it cannot confirm that a particular chart, image, or block of formatting costs a given amount. If you suspect one, remove it, run again, and let the before-and-after decide.

Placement and clock: change where and when it runs#

Instance: change what the server does#

Contribution: change what a form costs#

All four are on Settings ▸ Configuration ▸ Performance, under Contribution.

Full arithmetic and the live-round playbook are in Scale and size a contribution campaign.

Prove the change worked#

An improvement you cannot demonstrate is an opinion. The measurement rules make a fair before-and-after straightforward, provided you know them.

• The baseline is the median of up to 12 comparable earlier runs, and the median is deliberate: one pathological run would drag an average far enough to hide every later regression.
• A difference within 15 percent counts as noise and is not flagged. If your change is worth less than that, this instrumentation will not show it, and neither will your users notice it.
• A run is never part of its own baseline, and failed, canceled, and unmeasured runs are held out entirely.
• Compare like with like. Check the volume denominator on both sides. A faster run over less data has proved nothing.
• Two different elapsed figures exist. Where telemetry is present, elapsed is measured from execution start; where it is not, the column falls back to the wall-clock duration on the run record, and the tooltip says which you are looking at. They are never mixed inside one trend, and you should not mix them either.
• Pin the runs that matter. Performance data is removed when retention removes the run, so pin the before run if the comparison has to survive the retention window.
• On contribution, deltas travel and absolutes do not. Profiler numbers are working set on the machine that ran the profile. Compare before and after on the same machine.

Once several runs have accumulated after the change, the Compare tab should find the step you created, in the direction you intended. That is the cleanest evidence available.

Red flags and what they usually mean#

When to escalate#

Reportworq's own surfaces attribute cost down to a phase and an engine. Below that, the support desk needs the raw material.

Collect it with Settings ▸ Log Diagnostics, which packages application logs from every node, including load-balancer nodes, into a support packet. Say which report and which run you are asking about, since a run's measurements are what support will read first. If you were asked to reproduce the problem with Debug Logging on, turn it off again after the capture: it produces very large logs and archives and is itself a drag on the instance. See Log diagnostics and support packets.

Notes and limits#

• This is not alerting. There are no thresholds to set and no notifications. The baseline rules described here are fixed.
• A failed run still records its performance, deliberately, since a failure is often exactly the run whose breakdown you want. For diagnosing the failure itself rather than its cost, see Diagnose job failures.
• Releasing a held report writes no new measurement. The release re-opens the original run's record, and overwriting it would destroy the history this instrumentation exists to build.
• Only one step change is reported by the Compare tab, the single most significant one. It does not enumerate every wobble.
• The report ranking on Settings ▸ Performance ▸ Distribution has no paging and no row cap. On a large instance it is a long table, and narrowing the window is the only way to shorten it. A deleted report can still appear, because the page explains runs that already happened.
• There is no comparison level below one variation on the Compare tab. For per-workbook detail, use the Performance tab on a single run.

Going deeper. For sizing and placement, see Distribute the load. For the full field-by-field reference on each screen, see Compare performance across reports, Review a run's performance, and Find when a report got slower. For the live contribution console, see Contribution processes.