3 ms·
This seems like a bit of a strange article to me. When we talk about being "slow", that is typically relative to a non-CGI technology, essentially something tha
by nu11ptr 3y ago
This seems like a bit of a strange article to me. When we talk about being "slow", that is typically relative to a non-CGI technology, essentially something that keeps the code in memory ready to run. The reason CGI was "slow" was because 1) It had to start a new process for each invocation 2) When using tech that needed some form of warmup (I think PHP did??), you paid that for each invocation as well. In short, for some hobby or small setup it probably doesn't matter, and perhaps that is the authors point, but relative to an in-memory solution the situation probably hasn't changed much.
- sargun 3y agoAlso memory usage. An interpreter per active request would chew through RAM. I forget which Python project it was, but it introduced forking per request, and man that saved a lot of memory.
- cryptos 3y agoBoth points could be addressed by using a file system cache (or RAM disk) and a compiled language. A CGI application could, for example, be written in Go (https://pkg.go.dev/net/http/cgi https://pkg.go.dev/net/http/cgi).