Hacker News Reader

Comment by ahofmann | Hacker News Reader

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.

View on HN

> "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),

> 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...), is close to a "share-nothing architecture" thanks to custom implementations of `malloc()` and `free()` that know about the lifecycle of a request.

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#...

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.

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.

> 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.

Hmmm. When was the last time you wrote php? One file per route has been outdated for over 10 years.

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.).

I wasn’t arguing that, just arguing that that is quite an unusual approach in modern php.

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.

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).

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.

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.

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

Reply on news.ycombinator.com