3 ms·
Could you speed up CGI by, say, having an array of processes ready and waiting to receive data? Like an array of Haskell CGI processes or something...
by jancsika 3y ago
Could you speed up CGI by, say, having an array of processes ready and waiting to receive data?
Like an array of Haskell CGI processes or something...
- duskwuff 3y agoNot as CGI is currently designed. Many components of the request, like the HTTP headers, request method, and path, get passed to the CGI script as environment variables. You could redesign CGI to change this, of course. But at that point, you've lost compatibility with existing CGI scripts, and you might as well use FastCGI and/or HTTP over a socket instead.
- zokier 3y agoWith some hackery you might be able to do it even with plain CGI. I'm thinking doing something like user-land exec[1] and pausing the execution of child just before `main` (or whatever entrypoint). You still need to do one fork per request, but still you could improve average case latency by having children pre-forked. No, it absolutely would not be worthwhile to go through such hoops, but fun thought experiment. [1] https://news.ycombinator.com/item?id=37025843 https://news.ycombinator.com/item?id=37025843
- whartung 3y agoThis is the Fast CGI model, using pre-forking in something like Apache. Apache creates a new process for each incoming connection, but pre-forks them (so they sit idle without a connection), and when those processes fire up, Fast CGI starts up the "cgi" program and just waits for the data. After the request, the process and cgi program remain and linger, ready for the next request.