Results: a private lab server (22 cores, 128 GB). Measured 2026-10-16

The forecast was written first, before any code: the forecast. This page checks each number against it.

Where it was measured. Most of it ran in a 2-core sandbox with 7.8 GB and Python 3.13. RDKit is not installed there, so /api/model was checked with a stand-in for the conformer builder (the routing, not the chemistry). /api/site and the ligand surveys need no RDKit and ran for real. What needs 20 cores is marked lab and is measured on the machine itself with tools/lab/bench.py (see the lab server guide).

#Summary

#P1, P3 · what a worker costs

Each of the five requests of P4 ran seven times on two servers with the same profile: one with two worker processes, one computing in its request thread (--workers 0). Each request had its own pH (7.400, 7.401, …), so it was computed and not read from a cache. The structure stayed parsed where it was.

The differences scatter by ±60 ms either way. On this box the benchmark client, the front process and two workers share two cores, and that scatter is larger than any cost of the pool. Averaged over the ten pairs the worker was 18 ms faster. What a worker adds is small next to that: the job travels as a pickled dict, and the answer comes back as compressed bytes.

The first 20 MB file. The test file was 1HVR copied 144 times into one mmCIF file: 272 160 atoms, 20.0 MB, 28 MB as base64. Its first request took 3.9 s in a worker against 4.1 s in-process, and in a second run 4.07 s against 3.96 s (+113 ms). Reading the file takes 2.6 s of that in both. The second request, by structure_ref, sent 139 bytes and took 0.37 s.

#P2 · two requests at once

Each request had its own copy of 1HVR (a REMARK line makes the files differ), so the two land on different workers. Two requests took 1.02× and 1.07× the time of one. On 20 workers this is the number that matters most, and it is measured there.

A change made before measuring. The first design kept every structure on its first two workers (Mitzenmacher's "power of two choices"). On 20 workers, 20 different structures hashed that way would put two or three on some worker while others idle: the balls-into-bins result of Azar, Broder, Karlin and Upfal (1994). The forecast of 20 requests in 1.25× the time of one would then fail for a reason that has nothing to do with Python. So an idle worker now takes any request. It parses the structure again, which costs a fraction of a second next to the seconds a site takes. The first two choices still win whenever they are free.

#P4 · the same answer

All five answers were equal in every field except timing_ms, in both runs. The forecast said "byte-identical". That could never hold, because the answer reports its own timing. The forecast should have said "identical apart from the timing".

#P5 · memory

PSS divides each shared page among the processes that share it. The fork server imports the app once; each worker is forked from it and shares those pages. RDKit is not in this sandbox, so the idle figure on the lab machine will be higher, by RDKit's share.

The cache budgets of the lab profile on a machine with 22 cores and 125.7 GB (runtime_profile.py):

That adds up to 50.3 GB when every cache is full. 20 idle workers with RDKit and the front process stay well under 70 GB, as forecast. The budgets count bytes as measured in 16.5.1 (700 B per structure atom, 9 kB per fragment atom), so whether the processes really stop there is checked on the lab machine.

#P6 · the largest site

tools/lab/scale_site.py cut segments of growing length from ACE2 (7DDO, chain A, 597 residues without a break) and ran the site pipeline on one core:

The time per atom rises by about a quarter between 1 600 and 6 000 atoms, then stays flat. So the pipeline is close to linear but not quite. No protein in the test set has a longer unbroken chain, so 12 000 atoms is extrapolated: 1.34 s per 1 000 atoms gives 16 s and 24 MB of JSON. That is under the 20 s and 40 MB of the forecast, so the lab limit stays at 12 000.

#P7 · no re-uploads (browser)

On /sites with 19HC (a 1.1 MB file), the first request sent the file. Every later request named it by its SHA-256: 142 bytes for another ligand and 149 bytes for the survey of every ligand in the file. When the server answered structure_unknown (simulated), the page sent the file once more and then went back to the reference. All 18 checks of the browser test passed, on a desktop and on a 390 px phone.

#P8 · batch

The command line (tools/lab/batch_ligands.py). It surveyed the 156 ligands of the 23 biotite test files (31 components, no errors) in 2.95 s on one process and in 1.72 s on two: 1.72×. The output was identical apart from the timing.

The server (POST /api/batch, two workers against --workers 0), in two modes:

The first row is the forecast's case, and it holds. The second row misses 1.6×, and the reason is worth knowing. The in-process server had already parsed every file at upload, so its batch was pure survey: about 1.0 s. In the pool each file was parsed on whichever worker its hash picked, unevenly by size. Parsing a file costs 1.3 times as much as surveying its ligands (1.35 s against 1.05 s for the 23 files). So a worker that runs out of work can take another's file only by parsing it again.

The first version was slower than one process. It split every file into chunks of ligands and spread them over the workers: 1.26 s against 1.00 s in-process. Each chunk parsed its file again. Now:

• each file is one task, queued at the worker that parsed it;
• each worker takes its largest task first (Graham's rule for jobs of unequal length, 1969);
• an idle worker steals from the longest queue (work stealing, Blumofe & Leiserson 1999), but only while the victim would stay busy longer than the thief would take to parse and survey the stolen file;
• only a file over 2 MB with more than 24 ligands is split.

Molecules, not strings. The summary per component counts distinct molecules. The first identity key counted each atom's hydrogens. With it, the 18 haems of 19HC came out as five "molecules": which two of the four pyrrole nitrogens carry the charge is a choice of the matching, not chemistry. The key now uses the heavy-atom graph and the total hydrogen count, the idea of InChI's mobile-H layer (Heller et al. 2015), refined by Weisfeiler–Lehman hashing (1968). All 18 haems are one molecule, read in six tautomeric forms.

#P9 · a local copy of the PDB's dictionary

The real components.cif (about 400 MB) cannot be downloaded in this sandbox. Instead, tools/lab/make_ccd_excerpt.py --repeat 1600 wrote the 50 test components 1 600 times: 80 000 blocks, 103 MB.

At 10.6 ms per MB, the real file takes about 4 s to index once, well under the 60 s forecast. Real blocks are larger than these (more atoms per component), so a lookup there may take a few milliseconds. That is still under the 5 ms of the forecast, and it is measured on the lab machine. The file is memory-mapped, so 20 workers share one copy in the page cache.

#What is still to be measured on the lab machine

python3 server.py --profile lab --port 8000 &
python3 server.py --profile lab --workers 0 --port 8001 &
python3 tools/lab/bench.py --url http://127.0.0.1:8000 --compare http://127.0.0.1:8001 \
        --k 1,2,4,8,16,20 --files DIR_OF_STRUCTURES --out bench_lab.json
python3 tools/lab/scale_site.py --json scale_lab.json
python3 tools/lab/batch_ligands.py DIR_OF_STRUCTURES --workers 20 --out survey_lab

• P2 at k = 4…20. If 20 requests take more than twice one (the rule in the forecast), the pool goes and the server runs as several plain processes behind nginx.
• P5 with RDKit: the idle worker, and the memory after a long batch.
• P8 on 20 workers: a folder of files, command line and server.
• P9 on the real components.cif.gz.