Built for the load real print pipelines put on it.
AmazeLPD separates a fast, highly-parallel receive path from a throttled dispatch stage, acknowledges a job only after it is durably on disk, and degrades gracefully under overload instead of collapsing. Here is how it performs, how it is built, and how it is secured.
Proven under load
Tested head-to-head against the Microsoft Windows LPD service on the same hardware (8 vCPU, ~4 GB Windows VM), driving 500 concurrent clients × 5,000 jobs, deliberately pushed to saturation.
(Microsoft LPD: 4.1%)
below a 2% failure line
(1.4× growth under overload)
then lost
| Metric | Microsoft LPD | AmazeLPD |
|---|---|---|
| Jobs succeeded | 205 / 5,000 (4.1%) | 4,989 / 5,000 (99.8%) |
| Sustainable throughput (<2% fail) | 0 jobs/s (overloaded) | 378 jobs/s |
| Median acknowledgement latency | 6,934 ms | 152 ms |
| Latency growth under overload | 13.3× | 1.4× |
| Connections starved (never acknowledged) | 1,916 (38%) | 0 |
| Acknowledged-then-lost jobs | — | 0 |
Microsoft LPD showed the classic worker-starvation collapse — 38% of connections were accepted but never acknowledged, and sustainable throughput was zero. AmazeLPD, driven to saturation, degraded gracefully: it absorbed a 4,733-item internal backlog and drained it cleanly to zero without losing a single acknowledged job. Its 11 failures (0.2%) were connection-level on the load host, never data loss — because a job is acknowledged only after its bytes are durably written to disk, the client's success count always matches what is actually on the server. There is no acknowledged-but-lost failure mode.
Figures are AmazeLPD's own controlled stress testing, measured on identical hardware.
How it's built
The on-disk spool folder is the single source of truth for job data; the embedded SQLite database (Write-Ahead Logging) holds metadata only. Keeping the data on disk rather than in the database is the decision that gives AmazeLPD its throughput.
Decoupled receive & dispatch
A massively-parallel receive path (auto-sized from RAM) is separated from a throttled dispatch stage, so clients keep getting sub-200 ms acknowledgements even while an internal backlog drains. A slow destination never stalls receiving.
Acknowledge-after-spool
Jobs are acknowledged only once durably written. On start-up, jobs stuck in Processing reset to Pending, orphaned spool files are recovered, and genuinely-missing jobs fail cleanly — no silent loss.
Safe concurrent writes
A single global write lock plus a batched writer thread eliminate SQLITE_BUSY job loss; reads use WAL and are lock-free. Exactly one worker runs per queue, and a job is claimed before dispatch, so no job is ever sent twice.
Fair, tunable concurrency
A global dispatch semaphore rotates fairly across all active queues, so one busy queue can't monopolise delivery. Concurrency, timeouts, retention and receive-thread floor are all operator settings.
Performance & tuning
| Control | Effect | Default |
|---|---|---|
MaxProcessors | Global cap on concurrent destination dispatches. Raise for REST endpoints that absorb concurrency. | 4 |
ReceiveThreadFloor | Minimum receive-worker floor. 0 auto-sizes from physical RAM to a safe ceiling. | 0 = Auto |
JobTimeoutSeconds | Per-request REST timeout. | 60 |
HistoryRetainDays | Retention window for completed/failed jobs and spool files. | 30 |
VerboseLogging | Per-job/per-connection trace logging (off keeps the hot path fast). | Off |
Security posture
Presented candidly — each area with its mitigation.
| Area | Posture & mitigation |
|---|---|
| Least privilege | Runs as the built-in NetworkService account (not LocalSystem). Optionally a dedicated domain account or passwordless gMSA, selected at install. Ports below 1024 need no elevation. |
| Stored credentials | REST usernames, passwords and tokens are protected with Windows DPAPI — never stored in plaintext. |
| Licence integrity | Licence files are RSA-signed and validated against an embedded public key, with optional machine binding and expiry. Tampering invalidates the signature. |
| Data in transit | LPD/LPR and IPP are clear-text by design (as is Microsoft LPD). Terminate them on a trusted segment, use HTTPS REST destinations, and firewall 515/631 to known senders. |
| Data at rest | Spool files and the SQLite DB are plaintext on disk; the installer ACL-restricts the data folder. Enable BitLocker / volume encryption on the host. |
System requirements
Windows Server 2016 / 2019 / 2022 / 2025, or Windows 10 / 11 (x64) · .NET Framework 4.8 (ships with Windows Update) · ~50 MB disk · TCP 515 (LPD) and/or 631 (IPP), both configurable.