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
There are three ways a searchable-PDF workflow can be wired, and the first finding on this site is only true in two of them. Everything below turns on which one you are actually in — and it takes one person with a stopwatch about ten minutes to settle.
Which of three architectures are you in?
Not a rhetorical question. The fix is different in each case, and in one of them there is no fix worth buying.
OCR runs on the Sharp itself
The searchable-PDF option is a licensed feature on the device, and the capture server sits idle while the machine grinds.
The win is simply getting OCR off the device. Large, straightforward, and for a single machine it does not even need a queue.
OCR runs on the server, fire and forget
Scanning with OCR on and OCR off takes the same time at the panel. The PDF is what arrives late, not the machine that stays busy.
There is no device win to be had. Finding 01 would be wrong, and the only case left is time-to-document, throughput and classification.
OCR runs on the server, but the panel waits for it
The panel sits on a processing screen, or asks for an index value, or shows a confirmation that has to come back from the server.
Exactly the gateway change this site describes — acknowledge on receipt rather than after processing.
Scan the same document twice — once with OCR on, once with it off
Turning OCR off is a file-format or profile setting, not a mode the machine is locked into, so this is always available. Time from the last sheet leaving the feeder to the panel showing ready, both ways.
The first of those results kills this project, and we would report it as readily as either of the others. That is what makes the other two worth believing.
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 →