6 ms·

One often finds derogatory remarks about PHP, or that the popularity of the language is declining. Interestingly, the concept of PHP prevents exactly such probl

One often finds derogatory remarks about PHP, or that the popularity of the language is declining. Interestingly, the concept of PHP prevents exactly such problems, as a monolith written in PHP only ever executes the code paths that are necessary for the respective workload. The failure that the Rails app experienced in the post simply wouldn't have happened with PHP. Especially for web applications, PHP's concept of "One Request = One freshly started process" is absolutely brilliant. So, OP is right, write more monoliths, and I would add: write them in languages that fit the stateless nature of http requests.

lawrjone 3y ago
Small note that the app in the post was not Rails, it’s a Golang app. You’re right in that PHP couldn’t fail like this though, as the isolation level is at a unix process, where the OS should contain all your errors.
- stefano_c 3y ago
  The irony is that in a normal Rails app workloads are already split by default (requests and background jobs are handled by different processes that share the same codebase).
  - lawrjone 3y ago
    Yep, it's a very normal thing in the Rails world to separate things like this. For Django too. I'd encourage people to look a past just the splitting of workloads though. The other point about resource limits for shared resources across workload tiers is really key, such as having very granular database connection pools even inside of a single workload deployment. That's less common – though not unheard of – in Rails-land.
anditherobot 3y ago
PHP is amazing, yes the syntax is a little awkward. I love working with it. Especially with libraries/ framework that are 10+ years old Their documentation is extremely detailed. So you have more confidence that you'll deliver a working product. Instead of reading github issues to fix an obscure error message. Old does not always mean outdated.
InformalAnybody 3y ago
> "One request = one freshly started process" This isn't true for all (most?) PHP applications today. PHP installations include the FastCGI Process Manager (php-fpm). According to Wikipedia (https://en.wikipedia.org/wiki/FastCGI https://en.wikipedia.org/wiki/FastCGI), > Instead of creating a new process for each request, FastCGI uses persistent processes to handle a series of requests. According to the PHP Internals book (https://www.phpinternalsbook.com/php7/memory_management/zend_memory_manager.html#the-two-main-kind-of-dynamic-memory-pools-in-php https://www.phpinternalsbook.com/php7/memory_management/zend...), is close to a "share-nothing architecture" thanks to custom implementations of `malloc()` and `free()` that know about the lifecycle of a request.
- hu3 3y ago
  It depends on the configuration. One can set pm.max-requests=1 and have the process respawn per request. https://www.php.net/manual/en/install.fpm.configuration.php#pm.max-requests https://www.php.net/manual/en/install.fpm.configuration.php#... And the main point still stands: If a request manages to crash a php-fpm child process, other requests are unaffected and another process is spawned to replace the crashed one.
quickthrower2 3y ago
It comes down to how you want to do concurrency I guess? Processes? Threads? Event loop? Is there a clear winner? I often see debates or even flamewars about what is the best approach.
martin_drapeau 3y ago
This is a good point. Having a single process to handle all requests is asking for trouble.
pphysch 3y ago
> Interestingly, the concept of PHP prevents exactly such problems, as a monolith written in PHP only ever executes the code paths that are necessary for the respective workload. This is just lovely when you have hundreds of PHP endpoints written by your predecessors and each endpoint has rewritten an arbitrary slice of the stack (usually data model layer) because there is no common code path required. Refactoring anything below the html layer becomes impossible. In fact, calling it a software monolith is misleading, because each PHP script is its own little microservice with poorly-defined API boundaries.
- withinboredom 3y ago
  Hmmm. When was the last time you wrote php? One file per route has been outdated for over 10 years.
  - pphysch 3y ago
    This particular codebase I am maintaining is 10-20 years old. The point stands. Isolated code paths are great until you have to care about the ways they are not actually isolated (e.g. common database, platform-specific code, etc.).
    - withinboredom 3y ago
      I wasn’t arguing that, just arguing that that is quite an unusual approach in modern php.

lawrjone 3y ago

Small note that the app in the post was not Rails, it’s a Golang app. You’re right in that PHP couldn’t fail like this though, as the isolation level is at a unix process, where the OS should contain all your errors.

stefano_c 3y ago
The irony is that in a normal Rails app workloads are already split by default (requests and background jobs are handled by different processes that share the same codebase).
- lawrjone 3y ago
  Yep, it's a very normal thing in the Rails world to separate things like this. For Django too. I'd encourage people to look a past just the splitting of workloads though. The other point about resource limits for shared resources across workload tiers is really key, such as having very granular database connection pools even inside of a single workload deployment. That's less common – though not unheard of – in Rails-land.

anditherobot 3y ago

PHP is amazing, yes the syntax is a little awkward. I love working with it. Especially with libraries/ framework that are 10+ years old Their documentation is extremely detailed. So you have more confidence that you'll deliver a working product. Instead of reading github issues to fix an obscure error message. Old does not always mean outdated.

InformalAnybody 3y ago

> "One request = one freshly started process" This isn't true for all (most?) PHP applications today. PHP installations include the FastCGI Process Manager (php-fpm). According to Wikipedia (https://en.wikipedia.org/wiki/FastCGI https://en.wikipedia.org/wiki/FastCGI), > Instead of creating a new process for each request, FastCGI uses persistent processes to handle a series of requests. According to the PHP Internals book (https://www.phpinternalsbook.com/php7/memory_management/zend_memory_manager.html#the-two-main-kind-of-dynamic-memory-pools-in-php https://www.phpinternalsbook.com/php7/memory_management/zend...), is close to a "share-nothing architecture" thanks to custom implementations of `malloc()` and `free()` that know about the lifecycle of a request.

hu3 3y ago
It depends on the configuration. One can set pm.max-requests=1 and have the process respawn per request. https://www.php.net/manual/en/install.fpm.configuration.php#pm.max-requests https://www.php.net/manual/en/install.fpm.configuration.php#... And the main point still stands: If a request manages to crash a php-fpm child process, other requests are unaffected and another process is spawned to replace the crashed one.

quickthrower2 3y ago

It comes down to how you want to do concurrency I guess? Processes? Threads? Event loop? Is there a clear winner? I often see debates or even flamewars about what is the best approach.

martin_drapeau 3y ago

This is a good point. Having a single process to handle all requests is asking for trouble.

pphysch 3y ago

> Interestingly, the concept of PHP prevents exactly such problems, as a monolith written in PHP only ever executes the code paths that are necessary for the respective workload. This is just lovely when you have hundreds of PHP endpoints written by your predecessors and each endpoint has rewritten an arbitrary slice of the stack (usually data model layer) because there is no common code path required. Refactoring anything below the html layer becomes impossible. In fact, calling it a software monolith is misleading, because each PHP script is its own little microservice with poorly-defined API boundaries.

withinboredom 3y ago
Hmmm. When was the last time you wrote php? One file per route has been outdated for over 10 years.
- pphysch 3y ago
  This particular codebase I am maintaining is 10-20 years old. The point stands. Isolated code paths are great until you have to care about the ways they are not actually isolated (e.g. common database, platform-specific code, etc.).
  - withinboredom 3y ago
    I wasn’t arguing that, just arguing that that is quite an unusual approach in modern php.