Campaigns at large scale#

Three forms is a demo. A real compensation or budget cycle is one form per person, opened by many of them at once.

What "large" actually means#

Scale in contribution has two axes, and they cost differently.

Form size: how much is in one form. Every cell a form holds costs memory for as long as somebody has it open. For a sense of what heavy looks like: two sheets of roughly 60 rows with monthly columns runs to about 840 cube reads plus the level formulas that drive the outline.

Concurrency: how many forms are open at the same time. This is the number that decides what the server needs. A thousand forms that are never open at once cost nothing; fifty open simultaneously do.

The rough shape: cost ≈ bytes per cell × cells per form, and the number that matters for sizing is the marginal cost of one more form open at the same time.

Size it before you invite anyone#

There is a loop for this, and skipping it is how a campaign falls over on day one:

1. Design the form. Fewer cells beats more; a form nobody can fill in twenty minutes is too big anyway.
2. Measure one form's real server-side footprint with the campaign's memory profiling view. It is read-only and isolated, so you can run it against the real template.
3. Tune: trim rows, columns and sheets that are not load-bearing. Suppression helps: a sheet that drops out for the contributors it does not apply to costs those contributors nothing.
4. Stress test with the campaign's stress-testing tools: build a plan, run it against a disposable copy of the campaign with a dedicated test user, and reset between runs.
5. Size from the results. Plan to about 80% of capacity, and remember the worker baseline when sessions map one-to-one to workers.
6. Watch it in production.

The analysis view turns node results into plain language, what a typical user experienced, what the slowest user experienced, and where the slow tail is. That last one is what people complain about; averages hide it.

Do this on a copy. Stress testing generates forms and sessions. Never point it at a campaign people are using, and never at the demo store you are about to present from.

The two ceilings#

Two limits bite before anything else:

• A memory admission valve kicks in around 90% utilization and starts refusing new sessions rather than letting the server thrash. Hitting it looks like "some people cannot open their form", not like a crash.
• Max sessions per worker defaults to 1 in the demo configuration, meaning one contribution session per worker process. That is the safest setting and the most expensive one; raising it trades isolation for density.

The demo store also runs contribution sessions out of process, recycling a worker after 25 sessions. Those settings are the ones to look at when someone asks how it behaves under load.

What to change when you scale up#

Answering "will this cope with our headcount?"#

The honest answer has three parts, and none of them is a single number:

1. Here is how we measure it: the memory profiling view, run against a template shaped like theirs.
2. Here is how we prove it: the stress-testing and analysis views, showing what a population of users experienced rather than a single-user timing.
3. Here is the arithmetic: the two ceilings above, and the sizing loop.

The number depends on your form, which is why measuring yours beats quoting anyone else's.

Related#

• The campaign catalog · Update an input form
• Customer guide: Scale and size a contribution campaign, Profile and stress-test a campaign