Obeya looks through the demo directory a minute after it starts and every six hours after that, to delete the frames of old renders. It used to do that synchronously, so the server answered no page and heard no agent until it was done. It now asks the file system asynchronously, sixteen demos at a time. Which frames go, and when, has not changed.
| Where measured | Longest stretch the server could not answer, before | After |
|---|---|---|
The owner's Obeya, stalls.log, 29–31 October |
0.5–0.7 s, five times | can only be seen once it has landed |
| The real demo directory (1,044 entries, 734 renders), first look, nothing cached | 955 ms | 1 ms (right after, cache warm) |
| The same directory again, file system cache warm | 73 ms | under 1 ms |
| New test: 1,000 demos with frames, none due | 77 ms; the event loop turned once during the whole sweep | about 1 ms; it keeps turning throughout |
The real directory was only read for these measurements, nothing was deleted: both versions looked for the work directories and read when each render was last written to, which is what the sweep does before it deletes anything. The warm row compares like with like. Counting the space for the Demos section in the settings was already asynchronous: over the 145 GB directory it held the server up for 5 ms at most, and the new test checks that too.