4 ms·
CGI. Any language can do it. Language runtimes that have long startup times or don't cache the output of any of their compilation steps are less suited though.
by lotyrin 11y ago
CGI. Any language can do it. Language runtimes that have long startup times or don't cache the output of any of their compilation steps are less suited though.
A binary or script gets called with environment variables providing info about the request (e.g. query parameters), standard in contains the request headers and body. You can provide headers and response body via standard out.
RAM and CPU usage when your site has no traffic = 0. Running a bunch of this kind of site on a single web server becomes extremely economical. (In the sense that disposable cutlery and 99 cent cheeseburgers are economical.)
This side of 1999, it's worth it to have a few tens of megabytes of application code resident in ram to shortcut start up times. Instead of having each page start its own process, multi-threaded apps running on highly parallel hardware allows you to share effort between requests without bothering with cache coordination (or waiting on round-trips to the cache service). The benefit of faster page loads (higher conversion rates, happier readers, etc.). Since the age of CGI, moore's law and disintermediation has made these things cost less than a child's allowance.
- tyingq 11y agoJust making sure this isn't misinterpreted as saying that people run PHP (or really anything) on the old, traditional CGI model that forks a new process for each invocation of a script. Most php installations are either mod_php, running within the Apache process itself, or via fastcgi. In either case, the processes are pre-started and pooled.
- lotyrin 11y agoThe distinction isn't as big as proponents like to make it seem. FastCGI still acts like CGI, the app has to boot itself up every page -- just not the process handling the request (the interpreter, etc.) Thus opcode caches to be able to skip compiler steps. If Wordpress or Drupal, for instance, could boot up to the point just before they start doing anything dependent on values pulled from the request, then prefork and wait for incoming requests in that warm ready state, that would be more on par with modern application runtimes.
- tyingq 11y agoI see what you mean, but there's more to it. The same issues exist for every other script language that's been around a while. They all targeted CGI, because it was what was available to the masses. The opcode cache, for example, isn't much different than python's pyc files, just shared memory based. And, yes, some code gets re-interpreted that wouldn't have to. But, there are optimizations, like database connections that persist across requests. There's also a popular pattern of saving costly work that can be cached in shared memory (apcu, for example). So "the app has to boot itself up" isn't as terrible as it seems.
- lotyrin 11y agoAgreed, it's not the end of the world. The biggest headache I get from CGI-style app runtimes is that most do not allow me to open and use a database transaction across multiple requests. They tend to be designed around the assumption that database connections are stateless that keeping one open is only effecting a sort of cache. If it's not clear why I'd want this, it can be nice for integration testing (each test happens inside a transaction, aborts the transaction to clean up after itself) and you can extend those transactions as a feature to your user interface, let users start a transaction begin making changes, interact with the domain model inside their transaction but still let them confirm or revert the set of changes, or in the typical usage where an exception of some kind reverts the transaction, but where the exception and the changes that the exception should cause to be aborted might occur in different requests.