Serving a half billion requests per day with Rust and CGI

Original Article ↗ Hacker News Discussion ↗

Traffic metrics and provisioning

  • Several commenters say “requests per day” is a poor performance metric; peak RPS and tail latency matter far more.
  • Example: systems with low average RPS but large peaks (e.g. 50 RPS avg, 6k RPS peak, tight P99 SLA) show why daily totals can mislead.
  • Historical note: “hits per day” persists mainly as an intuitive, marketing‑style number.
  • Separate thread about massively over‑specced corporate deployments (ERP, monitoring) that barely use their allocated CPU/RAM.

Why CGI at all? Arguments for and against

  • Critics: CGI is an “outdated” model; fork+exec per request wastes resources, complicates permissions when code lives under document root, and is unnecessary when FastCGI/HTTP app servers are easy to run.
  • Pro‑CGI side: one‑process‑per‑request simplifies lifecycle (no stuck/leaky daemons), improves isolation between requests, and leverages OS security primitives; for many apps performance is “good enough”.
  • Some note it’s ideal for very low‑traffic, one‑off tools, shared hosting, or where ops simplicity (“boring”) is more valuable than raw throughput.

Performance results & database contention

  • Shared benchmark: Bash/Perl/JS/Python CGI far slower than Go, Rust, and C; Rust and C are only slightly ahead of Go.
  • People speculate the bottleneck may be SQLite contention and/or the Go web server.
  • SQLite’s WAL behavior and exponential backoff under contention are discussed as an explanation for heavy tail latencies, especially during WAL checkpoints.

Legacy, small systems, and embedded use

  • CGI remains attractive for:
    • Legacy systems that already use it, sometimes with SCGI/variants grafted on.
    • Tiny internal tools or appliance UIs where full stacks (Kubernetes, npm, etc.) are wildly overkill.
    • Embedded devices: tiny shells plus CGI scripts can provide web UIs; caveat about security and lack of MMUs on many devices.

Serverless vs CGI

  • Long sub‑thread debates whether “serverless” is essentially CGI-as-a-service or a broader PaaS abstraction.
  • Consensus within the thread: programming model is similar (request‑scoped, ephemeral execution), but cloud “serverless” primarily markets away server and capacity management, not a specific protocol.

Ecosystem and tooling notes

  • Some praise the multi-language guestbook repo as a “Rosetta stone” but note TOCTOU and synchronization pitfalls inherent to CGI.
  • Python’s cgi module deprecation spawns discussion; suggested workarounds include WSGI CGI handlers, third‑party reimplementations, or sticking to older Python versions.
  • A few compare CGI/SQLite setups to modern FastAPI/Go servers, finding far higher RPS for in‑process HTTP servers at similar complexity.

Web bloat and frontend choices

  • Complaints about heavy JavaScript frontends (multi‑MB bundles) harming UX on high‑latency links; renewed appreciation for server‑rendered HTML.
  • Several mention returning to “vanilla JS + jQuery” or web components for small apps, aided by modern AI tools, instead of React/Vue toolchains.