Landings on a large canvas no longer hold up the server
The size test lands 30 cards in a row on a canvas with 900 cards (800 archived), 80 ideas and 320 prototypes, and measures the CPU the server spends, worst of three rounds. It must stay under 500 ms. On main it failed in CI at 835–1036 ms.
Before, this laptop
~200 ms
worst run of 30 landings
After, this laptop
~65 ms
about a third
Before, CI runner
835–1036 ms
builds #89–#91, limit 500 ms
CPU per run of 30 landings
Worst of the test's three rounds, in three separate runs of each version on the same machine; the dashed line is the test's limit.
What made it slow, and what changed
- After every write to a card, the server rebuilt every card on the canvas: parsed each card's demo and page data and checked its demo files on disk. A landing writes to its card several times and reads it back in between. Now what a card's row makes is kept and reused while the row is unchanged; a write to one card rebuilds only that card, any other change rebuilds all (so a demo deleted by hand still shows as gone).
- The cards table had no index, so each of the half-dozen reads per rebuild went through the whole archive. Partial indexes now serve them.
- The canvas's cards were read twice per rebuild, and every card that came from another card looked that one up on its own; now one read and one batched lookup.
- The test's setup, which had grown to 4–6 s and hit the 5 s hook limit locally, now takes about 1 s.
Measurements