4 ms·

The 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

by lotyrin 11y ago

The 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 ago
I 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 ago
  Agreed, 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.

by lotyrin 11y ago

tyingq 11y ago

I 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 ago
Agreed, 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.