Serving 200M requests per day with a CGI-bin • Hacker News Board

Re: Serving 200M requests per day with a CGI-bin

#21

Post by bob1029 » Fri, Jul 04, 2025, 4:07 PM UTC

> These days, we have servers with 384 CPU threads. Even a small VM can have 16 CPUs. The CPUs and memory are much faster as well.

With this hardware, if you reach for Kestrel you can easily do a few trillion requests per day. The development experience would be nearly identical - You can leverage the string interpolation operator for a PHP-like experience. LINQ and String.Join() open the door to some very terse HTML template syntax for tables and other nested elements.

The hard part is knowing how to avoid certain landmines in the ecosystem (MVC/Blazor/EF/etc.). The whole thing can live in one top-level program file that is ran on the CLI, but you need to know the magic keywords - "Minimal APIs" - or you will find yourself in the middle of the wrong documentation.

Re: Serving 200M requests per day with a CGI-bin

#22

Post by nickjj » Fri, Jul 04, 2025, 4:11 PM UTC

atemerev wrote: post #3

Traubenfuchs wrote: post #2

Try an apache tomcat 11 next. You can just dump .jsp files or whole java servlet applications as .war file via ssh and it will just work! One shared JVM for maximum performance! It can also share db connection pools, caches, etc. among those applications! Wow!

I miss this so much. Deployment should be just copying the file (over ssh or whatever). Why people overcomplicated it so much?

Docker helps with this nowadays. Of course you need to understand setting things up the first time you do it but once you know, it can apply to any tech stack.

I develop and deploy Flask + Rails + Django apps regularly and the deploy process is the same few Docker Compose commands. All of the images are stored the same with only tiny differences in the Dockerfile itself.

It has been a tried and proven model for ~10 years. The core fundamentals have held up, there's new features but when I look at Dockerfiles I've written in 2015 vs today you can still see a lot of common ideas.

Re: Serving 200M requests per day with a CGI-bin

#23

Post by anoojb » Fri, Jul 04, 2025, 4:15 PM UTC

bob1029 wrote: post #21

> These days, we have servers with 384 CPU threads. Even a small VM can have 16 CPUs. The CPUs and memory are much faster as well. With this hardware, if you reach for Kestrel you can easily do a few trillion requests per day. The development experience would be nearly identical - You can leverage the string interpolation operator for a PHP-like experience. LINQ and String.Join() open the door to some very terse HTML…

The amount of Director/VP level promos that have come from creating abstractions on top of core technology no one gets rewarded for is amazing.

Re: Serving 200M requests per day with a CGI-bin

#24

Post by rascul » Fri, Jul 04, 2025, 4:18 PM UTC

simonw wrote: post #20

geocar wrote: post #16

Earlier quoted context omitted.

I think you might have found that CGI scripts deployed as statically-linked C binaries, with some attention given to size, you might've not been so disappointed. The "performance hit of starting a new process" is bigger if the process is a dynamically-linked php interpreter with gobs of shared libraries to load, and some source file, reading parsing compiling whatever, and not just by a little bit, always has been, s…

That's likely true - but C is a scary language to write web-facing applications in because it's so easy to have things like buffer overflows or memory leaks.

Can use rust, go, or whatever compiled language you want and it'll probably be much more performant starting up than any interpreted language.

Re: Serving 200M requests per day with a CGI-bin

#25

Post by lukeasrodgers » Fri, Jul 04, 2025, 4:18 PM UTC

Does anyone know if the benchmarking tool the author uses, plow, avoids coordinated omission (https://www.scylladb.com/2021/04/22/on-coordinated-omission/)? I didn’t see any mention in the docs, and haven’t been able to peruse the source code yet.

Re: Serving 200M requests per day with a CGI-bin

#26

Post by citrin_ru » Fri, Jul 04, 2025, 4:36 PM UTC

simonw wrote: post #10

I got my start in the CGI era, and it baked into me an extremely strong bias against running short-lived subprocesses for things. We invented PHP and FastCGI mainly to get away from the performance hit of starting a new process just to handle a web request! It was only a few years ago that I realized that modern hardware means that it really isn't prohibitively expensive to do that any more - this benchmark gets to 2…

CGI never was prohibitively expensive for low load and for high load a persistent process (e. g. FastCGI) is still better. CGI may be allows to handle 2k rps but FastCGI app doing the same job should handle more. You would need to start an additional server process (and restart it on upgrade) but it's worth to do if performance matters.

Re: Serving 200M requests per day with a CGI-bin

#27

Post by foobiekr » Fri, Jul 04, 2025, 4:41 PM UTC

cb321 wrote: post #12

Even back in the 1990s, CGI programs written in C were lightning fast. It just was (is) an error prone environment. Any safer modern alternative like the article's Go program or Nim or whatever not making database connections will be very fast & low latency to localhost - really similar to a CLI utility where you fork & exec. It's not free, but it's not that expensive compared to network latencies then or now. People…

You know, CGI with pre-forking (for latency hiding) and a safer language (like Rust) would be a great system to work on. Put the TLS termination in a nice multi-threaded web server (or in a layer like CloudFront).

No lingering state, very easy to dump a core and debug, nice mostly-linear request model (no callback chains, etc.) and trivially easy to scale. You're just reading from stdin and writing to stdout. Glorious. Websockets adds a bit of complexity but almost none.

The big change in how we build things was the rise of java. Java was too big, too bloated, too slow, etc. so people rapidly moved into multi-threaded application servers, all to avoid the cost of fork() and the dangers of C. We can Marie Kondo this shit and get back to things that are simple if we want to.

I don't even like Rust and this sounds like heaven to me. Maybe someone will come up with a way to make writing the kind of web-tier backend code in Rust easy by hiding a lot of the tediousness and/or complexity in a way that makes this appealing to node/js, php and python programmers.

Re: Serving 200M requests per day with a CGI-bin

#28

Post by p0w3n3d » Fri, Jul 04, 2025, 4:42 PM UTC

This was something that I've been suspecting for some time. We're moving towards complicated architecture while having possibility to use good ol' tech with newest CPUs.

I've been asked about architecture of a stocks ticker that would serve millions of clients to show them on their phone the current stock price. First thought was streams, Kafka, pubsub etc but then I came up with static files on a server.

I wonder how much would it cost though

Re: Serving 200M requests per day with a CGI-bin

#29

Post by foobiekr » Fri, Jul 04, 2025, 4:46 PM UTC

simonw wrote: post #20

geocar wrote: post #16

Earlier quoted context omitted.

I think you might have found that CGI scripts deployed as statically-linked C binaries, with some attention given to size, you might've not been so disappointed. The "performance hit of starting a new process" is bigger if the process is a dynamically-linked php interpreter with gobs of shared libraries to load, and some source file, reading parsing compiling whatever, and not just by a little bit, always has been, s…

That's likely true - but C is a scary language to write web-facing applications in because it's so easy to have things like buffer overflows or memory leaks.

CGI basically is a protocol between the webserver and some process. It didn't go out of fashion because of C (many/most CGI scripting for a time was perl and php or even bash), it went out of fashion because people wanted (or were told that smart people did this) to use languages that had runtimes which were expensive to run in a fork()+exec() execution model like Java.

You can use it with any language that can read stdin and write stdout. Yes, printing and reading.

Re: Serving 200M requests per day with a CGI-bin

#30

Post by simonw » Fri, Jul 04, 2025, 4:46 PM UTC

rascul wrote: post #24

simonw wrote: post #20

Earlier quoted context omitted.

That's likely true - but C is a scary language to write web-facing applications in because it's so easy to have things like buffer overflows or memory leaks.

Can use rust, go, or whatever compiled language you want and it'll probably be much more performant starting up than any interpreted language.

We didn't have so many options in the 90s!