Contribution processes#

The Contribution tab of Settings ▸ Performance is the operations console for the contribution runtime. Its heading reads Contribution worker processes and sessions. Contribution input forms run in isolated, out-of-process worker processes; this console makes that fleet visible per server, governs the memory safety valve that admits or denies new contributor sessions, and packages contribution session logs for support.

Contribution memory scales with cells multiplied by concurrent sessions, so a busy fleet can saturate. This console is where that saturation is seen and relieved. Settings ▸ Performance is administrator-only, and so are its control verbs.

The console is live only. It stores nothing: every figure is the present moment, refreshed on a poll, and no history, time series, or earlier peak is retained. Capture anything worth keeping at the time it is seen. To measure a form, or to keep a record, use campaign profiling instead.

Looking for this under Auditing? It used to be a Contribution Processes tab on Settings ▸ Auditing. It sits on Settings ▸ Performance now, beside the Distribution tab, because it is a live monitor rather than a record of what happened. Nothing about the console itself changed.

The console layout#

The screen is master-detail: a left rail lists every online worker grouped by server, and a right pane inspects the worker you select.

The worker states are Active, Draining, At capacity, Warm, Legacy 1:1, Idle, and Stopped.

The inspector's stat grid carries four fields: Workspace, Sessions (active over maximum), Served (lifetime), and Uptime. Its session table has six columns: User, Opened (a time, with no date), Input form, Calc (Auto or Manual), Workbook (Loaded or Unloaded), and Actions.

Headroom is measured against the busiest worker on the same server, not against the machine. It is the distance between this worker and that peer, so a large headroom figure does not mean the server has free memory. For the same reason the memory bars are scaled per server and are not comparable across servers.

Control verbs#

The console can act on the live fleet. These are administrator-only, disruptive, and available only when a worker is controllable. Each one is recorded in the System audit log.

Killing a session reclaims a stuck session without losing the contributor's work in progress and without leaving the form locked.

The 90% memory admission valve#

The same per-server memory reading drives a hard safety valve on the session-launch path. When a contributor opens a form, Reportworq checks the memory of every online server (local and load-balanced) and steers the new session to the online server with the most available memory that can still accept one.

A server can accept a new session only while its memory used is below 90%. If no server qualifies, meaning every online server is at or above 90% memory used, the launch is denied and the contributor is told:

Unable to launch new Contribution session because all servers are at capacity. Please try again later.

Below the threshold, the load balancer steers the session to the least-loaded server. Watching per-server memory climb toward this valve during a live round is the signal to drain or shut down a hot worker, or kill a runaway session, to free headroom before contributors are turned away.

Session logs, for support#

A toolbar handles contribution session logs across the whole fleet. Logs from remote servers are pulled on demand before packaging.

When to use it#

• Diagnose contribution memory pressure. During a large collection round, watch per-server memory, spot the hot worker, and drain or shut it down (or kill a runaway session) before contributors hit the admission valve.
• Escalate to support. Reproduce a contributor-reported problem, then Send session logs to support (or download the zip) so staff can investigate the exact worker and session.
• Plan capacity. Before opening a campaign, read per-server memory and worker counts to judge whether the fleet has headroom.

Notes and limits#

• The console operates on live worker processes and sessions; the control verbs (drain, shutdown, kill) are disruptive, administrator-only, and gated to controllable workers.
• It does not profile or change a form's content. Measuring a single form's footprint offline is the job of the form memory profiler, and form content is edited in the campaign editor.
• A contributor never sees this surface, but is directly affected by the 90% valve.

Going deeper. For the sibling Distribution tab on the same screen, which ranks report runs across releases and nodes, see Compare performance across reports. For the write-back processing this fleet's collected input feeds into, see Data collection processing. For the wider multi-server picture, see Deployment topology.