Performance and capacity planning#
Three questions arrive again and again, and they are the same question at three different moments:
- Before you buy the servers. How much hardware does this workload need?
- While the work runs. Is it going to finish inside the window, and is it spread across what we have?
- After something got slow. Why is it slow, and what do we change?
This section answers all three. Read this page first: it explains how Reportworq's capacity works, points at every measurement the product already keeps about itself, and sends you to the page that answers your question.
The one principle behind everything here. Reportworq measures its own work. Every run records where its time went and what it cost in memory and CPU, every contribution form can be profiled before anyone opens it, and a campaign can be load-tested before it goes live. So a capacity answer should almost always be a measurement of your own workload, not a rule of thumb about someone else's. The rules of thumb on these pages are starting points for the first estimate; the measurements are what you commit to.
Two capacity stories, not one#
The single most useful thing to understand before sizing anything: distribution and contribution consume the same server in different ways, hit different ceilings, and are measured with different tools. Sizing one tells you almost nothing about the other, and a deployment that runs both needs both answers.
| Distribution (reports and jobs) | Contribution (input forms) | |
|---|---|---|
| What consumes the server | Jobs running: generating, rendering, and distributing output | Forms being held open by contributors |
| What drives the cost | The number of jobs in flight, roughly 2 GB of RAM per concurrent job | Cells multiplied by concurrent sessions |
| The ceiling you hit | Memory exhaustion under parallel execution, or the window closing before the batch finishes | A hard 90% memory admission valve that refuses new sessions, and the per-worker session cap |
| How it fails | Jobs run slowly, or the server runs out of memory under load | A contributor is told every server is at capacity and their form does not open |
| How you scale it | Concurrency limits per node, then more nodes | More memory or more servers, or a cheaper form |
| What you measure with | Run telemetry: Run History columns, the Performance, Compare, and Timeline tabs, and Settings ▸ Performance ▸ Distribution | Campaign profiling: memory profiling, stress testing, and analysis, plus the live Settings ▸ Performance ▸ Contribution console |
| Where it is sized | Distribute the load | Scale and size a contribution campaign |
They also compete. Report execution and contribution sessions take memory from the same machine at the same time, so an instance doing both needs headroom for the busiest moment of each, not for their averages.
Start here#
| Your question | Go to |
|---|---|
| How many servers, and how big, for this workload? | Distribute the load |
| The batch does not finish inside our close window | Distribute the load, then Manage and improve performance |
| We added nodes and throughput barely moved | Distribute the load, the job-granularity rule |
| One report used to take three minutes and now takes twenty | Manage and improve performance |
| Everything feels slower since the upgrade | Manage and improve performance, the release pivot |
| One node in the cluster looks slower than the others | Manage and improve performance, the node pivot |
| Contributors are told all servers are at capacity | Scale and size a contribution campaign |
| How big can a contribution form be? | Profile and stress-test a campaign |
| A job failed rather than ran slowly | Diagnose job failures |
| Run history and stored output are consuming disk | Output retention |
What Reportworq already measures about itself#
Nothing in this list has to be switched on, and none of it is an add-on. Knowing what exists is most of the work, because the common mistake is to answer a capacity question by argument when a measurement was already sitting there.
For reports and jobs#
| Measurement | Where it lives | The question it answers |
|---|---|---|
| Elapsed vs baseline, Trend, Peak mem columns | A report's Run History | Was this run normal for this report? |
| Performance tab | A run's diagnostics | Where did this run's time go, down to the output, workbook, processing phase, and calculation engine? |
| Compare tab | A run's diagnostics | At what point in this report's history did its typical run time step, and did volume, release, or node change with it? |
| Timeline tab | A run's diagnostics | What did each part of the run coincide with, on one clock, including memory and CPU? |
| Settings ▸ Performance ▸ Distribution | Settings | Across every report at once: which are regressing, did a release regress us, is a node slower? |
| Run estimate chip | Activity, and the activity pulse popover | Is the run in progress going to finish roughly when it usually does? |
Every run also records peak and average working set and maximum CPU, which is the raw material for sizing an execution host. All of it is written per run and ages out when retention removes the run, so pin a run you intend to compare against later.
For contribution#
| Measurement | Where it lives | The question it answers |
|---|---|---|
| Memory profiling | Campaign profiling, on the Campaign Dashboard | What does one form cost, in memory and per cell, and what does each additional concurrent form cost? |
| Stress testing | Campaign profiling | At the concurrency we sized for, what do contributors actually experience? |
| Analysis | Campaign profiling | Merged across load generators: typical, most-users, and slowest timings, plus slow-tail and slowdown findings |
| Settings ▸ Performance ▸ Contribution | Settings | Right now: per-server memory, per-worker sessions, and how close the fleet is to the admission valve |
Memory profiling is read-only and safe against a real campaign. Stress testing writes data and submits forms, so it runs only against a disposable copy.
The baseline the estimates start from#
These are the published requirements, and they are where a first estimate begins before you measure anything.
| Figure | Value |
|---|---|
| CPU | 4-core, 2 GHz or faster, x64 |
| RAM | 32 GB minimum, plus roughly 2 GB per concurrent job on top of the base |
| Disk | 10 GB free, growing with the Repository, run history, and logs |
| Default concurrency | 4 top-level jobs at once, 3 outputs within a job |
The RAM figure is a stated requirement, not something the software enforces at startup, and an under-sized server runs out of memory under load rather than simply running slowly. Full detail, including the Linux fonts requirement and the two ports every server needs, is in System requirements.
Notes and limits#
- This is not alerting, and Reportworq has no performance thresholds to configure. There are no notifications when a report regresses and no service-level targets to set. Every surface described here is something an administrator opens and reads. Build any alerting you need around the measurements rather than expecting the product to page you.
- Comparison needs history. A report needs at least 3 comparable earlier runs before any baseline comparison is offered, and 6 before the Compare tab will look for a step change. A freshly upgraded instance has a thin picture until new runs accumulate.
- Measurements age out with the run. Performance data is stored with the run and is removed when retention removes it. Pin the runs you expect to compare against, such as each period-close run. See Output retention.
- Runs that predate performance telemetry never gain it. Their columns report that they carry no measurement rather than reporting zero, which is a different fact and is displayed as one.
- A view-only User sees none of the diagnostic detail. The performance columns and the diagnostics tabs sit behind View diagnostics, which that role does not have. Authors and administrators reach them.
Going deeper. For sizing and spreading a workload, see Distribute the load. For diagnosing and improving content that is already slow, see Manage and improve performance. For the deployment shapes and the load-balanced cluster itself, see Deployment topology. For the settings that these pages tune, see Server configuration.
Feedback on this page
Comments, questions, requests, or something missing or unclear? Email us - the page you are on is filled in for you.
Email feedback on this pageOr write to support@reportworq.com directly.