undefined | Better HN

0 pointsImplicated1y ago0 comments

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

0 comments

that_guy_iain1y ago

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.

j / k navigate · click thread line to collapse