Hacker News Reader

Comment by JJMcJ | Hacker News Reader

CGI is still a reasonable choice for low query rate and simple pages, like an AJAX responder.

Especially when there won't framework already in use on this particular server.

Why add <framework of the day> to your setup when every 10 minutes or so, it's time to read the temperature sensor and return a string with the reading.

Also, since it's served by a transient process, there is no problem of memory leaks, file handle leaks, other resource capture by long running processes.

Per Murphy's Law, of course, everything is fine until one day the internal app goes public and suddenly there are 500 queries a second.

View on HN

> CGI is still a reasonable choice for low query rate and simple pages

By which you mean, "Almost every website in the Universe which isn't actively being DDoSed" with the understanding that essentially nobody can stand up to a modern, competent DDoS.

> Per Murphy's Law, of course, everything is fine until one day the internal app goes public and suddenly there are 500 queries a second.

Omae wa mou shindeiru. You are already dead.

It's humorous to think every random person on HN is working on a site that gets more traffic than Slashdot did in 1999. A site that ran on mod_perl and, by modern standards, fairly basic hardware.

And for the most part, CGI went on the decline the day mod_perl came out. Which was 1996. So we really didn't use basic CGI for that long. The popularity of putting Perl right in Apache eclipsed running standalone Perl via CGI. It would be at least another decade before the world started to move on from this arrangement (mod_php or mod_perl).

agreed. I launched a cgi-based thingy a few months ago for my job to render a really basic template across a ton of sites with very low volume. Had it out in less than an hour.

Honestly, sensors is a really bad example.

Each CGI request has to create a new process, that can easily mean entire seconds of CPU per request.

A few sensors sending information from time to time will quickly turn into a massive resource hog. Having used CGI extensively, one of the biggest caveats is resource exhaustion and the ensuing DDoS.

That's why I explicitly chose every 10 minutes.

There are situations like that.

I have seen CGIs where usage started very slow and then gre t the point of friendly DDoS, and it's not fun because the CGI is usually built deep into the architecture by that point.

Also, sensors was the first thing that came to mine.

Also some sensors read very fast, like in Linux "sensors -f" returns the CPU temperatures.

came to minD

not

came to mine

I think one of the overlooked things of the process-per-request CGI scripts we ran back in the day is how you might run out of PIDs. I remember this happening once, but I think(50/50) it was because the PID was a 16-bit value at the time and the system and an uptime of about 6 months.

PIDs will recycle rather than exhausting. As an aside, that's also the reason why it's unsafe to use a PID from any process other than the parent process. As soon as the parent calls wait(2), the PID is released and could be reused for a fresh process at any moment.

The only way to run out of PIDs is not wait() properly, leading to zombie processes, or else some CGI processes time out and don't exit, so never reaped by a wait().

In my experience PHP is the CGI of 2019.

Reply on news.ycombinator.com