Hacker News Reader

Comment by hipadev23 | Hacker News Reader

> PHP doing hundreds of requests per second.

You may want to update your understanding of PHP and Go's speed . Both of your estimates are off by a couple orders of magnitude on commodity hardware. There are also numerous ways to make PHP extremely fast today (e.g. swoole, ngx_php, or frankenphp) instead of the 1999 best practice of apache with mod_php.

Go is absolutely an excellent choice, but your opinion on PHP is quite dated. Here are benchmarks for numerous Go (green) and PHP (blue) web frameworks: https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

View on HN

Sure, PHP can process logs of any volume, but it would require 5–10 times more servers to handle the same workload as something like Go. Not to say Go just works out of the box while for PHP you must set up all those additional daemons you listed and make sure they work -- more machinery to maintain, and usually they have quite a lot of footguns, too. Like, recently our website went down with just 60 RPS because of a bad interaction between PHP-FPM (and its max worker count settings) and Symfony's session file locks. For Go on a similar machine 60 RPS is nothing, but PHP can already barely process it, unless you're a guru of process manager settings.

In a different PHP project, we have a bunch of background jobs which process large amounts of data, and they routinely go OOM because PHP stores data in a very inefficient way compared to Go. In Go, it's trivial to load hundreds of thousands objects into memory to quickly process them, but PHP already starts falling apart before we hit 100k. So we have to have smaller batches (= make more API calls), and the processing itself is much slower as well. And you can't easily parallelize without lots of complex tricks or additional daemons (which you need to set up and maintain). It's just more effort, more waste of time and more RAM/CPU for no particular gain.

This isn't a PHP problem, this is a configuration problem. You shouldn't be using the filesystem to handle your sessions in a production application.

Anything that unexpectedly blocks a process can bring down your entire PHP server because you will run out of worker processes. For example, imagine you experience a spike in requests while another server you're trying to call is timing out. You can't set the maximum worker count to a very high value because the operating system has an upper limit. Since the limit must remain low enough, you can quickly run out of your worker processes.

In contrast, Go can efficiently manage thousands of such blocked goroutines without issue. Sure, you can address this problem in PHP, but you need:

- understand PHP-FPM (or whatever you use) configs and their footguns

- understand NGINX configs and their footguns

- fiddle with PHP configs/optimizing your code to fit within PHP's maximum limits

- rent larger servers to have the same throughput

True. I stand corrected.

This is a footgun, regardless of if it's a block from file systems or remote requests or whatever.

My claim that it's a configuration problem is just a 'fix' and there are ultimately an unlimited list of ways this same thing can come up to bite you. Well, outside of aggressive timeouts - and even then, with enough volume of requests that's even not going to save you :D

> In Go, it's trivial to load tens of objects into memory to quickly process them, but PHP already starts falling apart before we hit 100k.

I'm not going to argue that PHP is _better_ than Go. Just starting off with that.

But if your background jobs are going OOM when processing large amounts of data it's likely that there's better ways to do what you're trying to do. It is true that it's easy to be lazy with memory/resources with PHP due to the assumption that it'll be used in a throwaway fashion (serve request -> die -> serve request -> die) - but it's also perfectly capable of long-running/daemonized processes that aren't memory issues rather trivially.

What you're talking about is generally not considered production-ready. While you can use these tools you will almost certainly run into problems. I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP.

What we see here is a classic case of benchmarks saying one thing when the reality of production code says something else.

Also, I used go as a generic example of compiled languages. But what we see is production-grade Go languages outperforming non-production-ready experimental PHP tooling.

And if we go to look at all of them https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

We'll see that even the experimental PHP solution is 43 and being beat out by compiled languages.

> ... you can have Go doing thousands of requests per second vs PHP doing hundreds of requests per second.

> I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP.

As an active PHP developer as well it sounds like you have no idea what you're talking about.

> While you can use these tools you will almost certainly run into problems.

Which tools are "generally not considered production-ready"? From what I'm seeing on the linked list of benchmarks...

- vanilla php - workerman - ubiquity - webman - swoole

I'd venture to bet all of these are battle tested and production ready - years ago now.

As someone who has built a handful of services that ingest data in high volume through long-running PHP processes... it's stupidly easy and bulletproof. Might not be as fast as go, but to say these libraries or tech isn't production-ready is rather naive.

Having read your post:

* Vanilla PHP can't read anywhere near the same RPS as the others

* Using those results in removing the ability to use a large amount of the ecosystem. While if you used the correct language you would be able to use it's entire ecosystem.

* In my opinion, if you're using workerman or Swoole you've already realised the limitations of PHP and should be using another language.

This seems like a classic case of "if all you have is a hammer everything looks like nail"

> Might not be as fast as go, but to say these libraries or tech isn't production-ready is rather naive.

This strawman argument. Firstly, you admit my original point. Secondly, those aren't the tech in question and I notice you left off the tech in question. Roadrunner, FrankenPHP, etc. All the tooling that can make your average PHP app go faster.

Nobody is suggesting PHP beats compiled. We’re arguing with you about your utter lack of expertise in the language, knowledge of the ecosystem and “production-ready” status of the many options, and your overall coding ability when it comes to PHP.

> Nobody is suggesting PHP beats compiled.

Actually, there seems to be people arguing that.

> We’re arguing with you about your utter lack of expertise in the language, knowledge of the ecosystem and “production-ready” status of the many options, and your overall coding ability when it comes to PHP.

If you're doing that with benchmarks you're doing a shitty job. My numbers came from experience in production environments with production workloads.

Not to mention that you're talking experimental tooling as examples. I've literally seen multiple companies try to use FrankenPHP. Not one even made it to QA aka it broke because during the dev testing.

Again, you don't have the slightest clue what you're talking about. There are numerous production-ready choices that myself and others have mentioned.

As soon as you add C#, ASP.NET Core shoots to the top of the Fortune stack.

Reply on news.ycombinator.com