4 ms·
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 part
by JJMcJ 7y ago
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.
- liveoneggs 7y agoagreed. 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.
- aliceryhl 7y agoIn my experience PHP is the CGI of 2019.
- msla 7y ago> 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.
- deckard1 7y agoIt'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).
- user5994461 7y agoHonestly, 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.
- JJMcJ 7y agoThat'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.
- rwbaskette 7y agoI 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.
- charliesome 7y agoPIDs 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.
- JJMcJ 7y agoThe 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().