[SimonHeybrock]

Workspace runs requests on one thread by default (was 4), and local() and open_folder() take workers and pass it on.

Why. Step 2 of #184 measured real LoKI reductions. The workflow is already parallel inside (dask, TBB), so more workspace threads slow it down and multiply its peak memory:

4 × I(Q), LoKI tutorial files, 24 cores	1 thread	4 threads
plain requests	14.8 s, 8 GB	20.1 s, 27 GB
through one stage	7.9 s, 4.7 GB	7.3 s, 15 GB

The best number depends on the instrument (file sizes, file counts, processing patterns), so an application sets it:

client = open_folder(directory, bind=[...], workers=2)

What it costs. Requests, the steps of accumulators, and store writes share the threads. On one thread a long reduction holds up a short request, such as masks, until it finishes. Through one stage, eight rows took 12.7–13.2 s on one thread against 11.4–12.0 s on four.

The batch page stays responsive on one thread. /api/state while 8 reductions run in the server's process:

	Median	p95	Max
1 page, 4 threads	15 ms	39 ms	353 ms
1 page, 1 thread (2 runs)	12–13 ms	45–68 ms	162–215 ms
5 pages, 4 threads	14 ms	220 ms	538 ms
5 pages, 1 thread (2 runs)	11–16 ms	63–204 ms	126–332 ms

Tests. Two persistence tests need a second request to run while the first waits, and now ask for two threads. One of them had passed on one thread only because the blocked request timed out after 5 s. A new test checks that a workspace runs as many requests at once as it has workers.

Not done. The command essapps-batch has no option for the number of threads. The demos of the Panel view and the web page use the default, so their fake reductions now run one after another.

🤖 Generated with Claude Code