Where the time actually goes
Six steps, of which one is slow and one is unknown. It is worth being precise about which is which, because the fix for a slow step and the fix for a badly-coupled step are completely different pieces of work.
Ten seconds of real work. Nobody has ever complained about this part.
A 200-page duplex job at rated speed is a few minutes of paper handling. This is honest work and it is not the problem.
Seconds to a minute or so on a healthy LAN. Also not the problem.
This is the part everything else waits behind. It is CPU-bound and it does not care that somebody is standing in front of the machine.
Rules, barcodes, zonal reads — whatever has been configured.
Folder, DMS, matter, mailbox. When it arrives, it is correct. The complaint has never been about the output.
We do not actually know whether the OCR holds the device
It might hold it completely, it might release the moment the last page is transmitted, or it might sit somewhere in between depending on how the workflow is configured. This single fact changes the size of the prize by a large factor, and it is the sort of thing that takes one person ten minutes with a stopwatch to settle. It is question two on the Questions page, and it is the one we would answer first.
One 200-page job, on an idle system
Assuming 80 sheets per minute at the device and 25 pages per minute from one OCR engine. Adjust those on the next page if they are wrong — they almost certainly are, slightly.
Notice what has not changed. The document still arrives at roughly 11.3 minutes in both cases. On an idle system, with one job, decoupling buys the machine back and nothing else. That is honest, and it is also exactly the complaint that was made — nobody said the PDF arrived too late, they said the scanner was unavailable.
The same job, twenty of them, all at once
This is where the second claim lives. Each square is one job; the number is how many minutes until that job's document is finished. Darker is a longer wait.
One engine
todayJob twenty waits for the nineteen in front of it.
Four workers
elasticSame total compute. Spread across four engines instead of one.
This is arithmetic, not a benchmark. Four engines finish a fixed pile of work in roughly a quarter of the time, which is not a surprising result and not a clever one. The interesting question is not whether the maths works — it is whether anything in a real system (storage, licensing, a single-threaded step somewhere) stops it from working. That is test two.
The shape of the difference
Reduced to the only part that matters. Everything else is implementation detail and does not belong in this conversation yet.
One path, one throughput ceiling, set at purchase time. To go faster you buy a bigger box, and you buy it for the peak you have once a month.
worker
worker
worker
The acknowledgement happens at the gateway, not after the OCR. That single move is what releases the device. The workers are what stop job twenty paying for jobs one to nineteen.
Two separate benefits, often confused. Releasing the device is about where the acknowledgement happens. Clearing a backlog faster is about how many engines exist. You could have either without the other, and it is worth knowing which one the complaint is really about before choosing what to build.
Put numbers against both →