5 ms·

Few months ago I was debating with a friend working since 15 years on PHP, my point was php is slow and max throughput is 200-500 rps, which is quite low compar

Few months ago I was debating with a friend working since 15 years on PHP, my point was php is slow and max throughput is 200-500 rps, which is quite low compared to Go, node.js, C# and others, he answered that 100-200 request per second is more than enough for most use cases. I'm working on systems with 25K RPS at peaks, but for simple projects and small companies he is right ... But why should anyone start a new project in php now that we have so many good alternatives?

codegeek 6y ago
"he answered that 100-200 request per second is more than enough for most use cases" Exactly this. If you already know PHP and can produce results (mostly CRUD apps) and it doesn't need millions of rps, why do we need to use another language because they are so much better ? So much better at what ? It is like saying "I have a hammer, so everything looks like a nail to me". Not every web app has to be written in Lua/Rust/Go/Julia etc. Each language comes at a cost. No free lunch. "But why should anyone start a new project in php now that we have so many good alternatives?" Because everything comes at a cost. You want to use Rust instead of PHP ? Sure, sounds great. Now lets go find a really good Rust developer who also understands how to host it correctly and then if he leaves, can I easily find another Rust developer ? Hmmm. You also need to account for maturity, ecosytem, hosting, maintenance etc which are all real world problems. Building a new shiny toy project ? Go ahead use whatever language you love. Again, it is about cost vs benefit.
- codeulike 6y ago
  Reminds me of "PHP Hammer" I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there. You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes. You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways. You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever. And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools. Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door. That’s what’s wrong with PHP. https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ edit: Flickr user @raindrift made an actual PHP hammer, famously https://www.flickr.com/photos/nicoletbn/6949293600 https://www.flickr.com/photos/nicoletbn/6949293600 2012 discussion of hammer https://news.ycombinator.com/item?id=3866488 https://news.ycombinator.com/item?id=3866488 TechCrunch defence of the hammer https://techcrunch.com/2012/07/28/not-that-kind-of-filthy-get-your-mind-out-of-the-gutter/ https://techcrunch.com/2012/07/28/not-that-kind-of-filthy-ge...
  - hnarn 6y ago
    That's funny and all, but it doesn't drive home much more of a point than "PHP is bad because PHP is bad". The insinuation that all "houses" built with PHP are defective and waiting to fall apart is so obviously untrue that it feels unworthy of discussion. A more reasonable analogy would be that there's a standardized toolbox that carpenters use that's weird, quirky and sometimes so bad that you need to know workarounds to use it correctly, but the houses that are being built do what they're supposed to in the vast majority of cases because most of the carpenters know the quirks well. The question then is, if you're contracting someone to build your house, or you're the manager of a construction company, do you go with the standard toolbox that's used by the X% majority of carpenters, or do you hire carpenters that use more obscure (but functionally "better") toolboxes while running the risk of now ending up with unmaintainable or deviating houses that are hard to recruit additional carpenters for because they refuse to work on what is quite objectively "non-standard" houses? The answer in my mind is no less complex than it would be for software development: it depends, and you should be wary of anyone telling you that it's "obvious" that the answer is one or the other.
    - codeulike 6y ago
      Fair point about the houses
  - xd 6y ago
    As yes, the 2012 fractal of bad design, being peddled out yet again - your post is just pure hate, it adds no valid argument whatsoever.
  - wccrawford 6y ago
    I think a better analogy would be that the PHP carpenters have standard old tools that people have used forever, and they work just fine. Normal hammer with wooden handles, normal planes, etc etc. But there are modern carpenters that have hammers that are 100% metal and never break and actually improve your hammering power. The new electric hand planes work a lot faster, though you do have to be more careful because they can get out of hand quicker. etc etc. In the end, they both build houses. The old-school carpenters might take longer, and they might have to know more techniques, but they get there in the end. On the other hand, the modern carpenters sometimes go a littler overboard with their tools and have problems that old-school carpenters don't have, especially with their tools randomly stopping working in the middle of a job. It might not be often, but it happens. To add to that, the old-school carpenters can actually use a lot of the new tools, too. They fit into the workflow and can be adapted to their old tools. It's just that they primarily stick with their old tools because they're used to them. It's kind of interesting how much the world of woodworking and software development overlaps in that way.
- iamgopal 6y ago
  well, on the other hand, if you are starting from scratch as a new developer, trying out go or rust is not too risky as large orgs backing it up. Also, for me, hosting go is much easier than php, as I am not from that era.
- andi999 6y ago
  I am wondering this: are people who do crud apps (in php or otherwise) do consider race-conditions in the database? Like one query and then based on that query another one which inserts/updates? And if so, where can I read about the standard techniques used in practice?
  - SPBS 6y ago
    https://blog.coeo.com/a-cheat-sheet-for-isolation-levels-in-sql-server https://blog.coeo.com/a-cheat-sheet-for-isolation-levels-in-... The standard technique is deciding which isolation level you want to use for your queries.
  - jpalomaki 6y ago
    Database transactions is the topic you should look into. There's ways to handle these in all environments. https://en.wikipedia.org/wiki/Database_transaction https://en.wikipedia.org/wiki/Database_transaction
    - andi999 6y ago
      Thanks. So is the general industry practice? I read MySql only supports this since like 2004, somehow reading material doesnt seem to be too concerned about these.
- SergeAx 6y ago
  You can't rely on a compiled/JIT language to address performance requirements. There's always time when your server is overloaded, no matter if it can handle 100 or 10000 RPS. You should architect your app with scalability in mind. And then there's not much difference between languages, only marginal savings on infrastructure. But one month of decend web server host costs about the same as one hour of decent software engineer.
glandium 6y ago
That's true, until a stupid non-rate limited web spider takes most of your resources.
jetter 6y ago
Well, good performance of http request/response cycle is mostly related to async operation, in some form, when long-lived daemon can process big amount of requests without spending time on initialization. Workerman and swoole, powered by async PHP approach, are very fast and suitable for high load. The problem with async PHP, though, is that you need to be careful with libraries (e.g. mysql client) because most of them were designed with short-lived PHP script execution in mind.
Cthulhu_ 6y ago
200-500 requests per second? I'm sure it can do a ton more. Here's some benchmark numbers: https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=composite&l=zik073-1r https://www.techempower.com/benchmarks/#section=data-r19&hw=... I don't believe the constraint would be the language itself, not with accellerators, opcode caches, JIT compilers, etc. I've always been told that PHP's performance is more down to the database than anything else.
Mikushi 6y ago
> my point was php is slow and max throughput is 200-500 rps Absolutely not, you could already go to 5k rps 10 years ago and PHP has massively improved since.
fetbaffe 6y ago
Because the alternatives is actually not good, it just a fallacy. There will always be something negative regardless of what you pick, problem is to decide what your core values are when writing different types of software. If you don't, you are just comparing apples to oranges. When it comes to PHP, core values are usually things that has to do with tooling, server architecture & deployment, not much the language (syntax, expressions, lambdas, classes etc) it self, except maybe it is easy to learn & use. This means that developers who comes from a background of that the language itself is the most important part of a project will most of the time just get confused what PHP is about.
kijin 6y ago
> php is slow and max throughput is 200-500 rps I don't know where you pulled that number out of, but I just used an outdated version of `ab` to request the Hello World page of a fairly heavy PHP framework on a modest virtual server and got over 4k rps. Give me a proper server box and a well-written application, and I'll deliver the 25k rps that you want. Besides, most webapps spend most of their execution time waiting for the database, memcached, redis, elasticsearch, or whatever. The speed of the language runtime makes very little difference.
fraktl 6y ago
Dev. here, using PHP for 20 years. Short story: I'm working on a system that peaks at 200k rps. Using PHP with Swoole.
deleted 6y ago
[deleted]
zapt02 6y ago
This is correct only if you run "Hello World" apps on a single server. PHP scales horizontally so any real-world application can easily scale to 10, 100 or 1000 servers. If there is no other scaling challenges (like databases) then it can scale forever thanks to its beneficial process model.

codegeek 6y ago

"he answered that 100-200 request per second is more than enough for most use cases" Exactly this. If you already know PHP and can produce results (mostly CRUD apps) and it doesn't need millions of rps, why do we need to use another language because they are so much better ? So much better at what ? It is like saying "I have a hammer, so everything looks like a nail to me". Not every web app has to be written in Lua/Rust/Go/Julia etc. Each language comes at a cost. No free lunch. "But why should anyone start a new project in php now that we have so many good alternatives?" Because everything comes at a cost. You want to use Rust instead of PHP ? Sure, sounds great. Now lets go find a really good Rust developer who also understands how to host it correctly and then if he leaves, can I easily find another Rust developer ? Hmmm. You also need to account for maturity, ecosytem, hosting, maintenance etc which are all real world problems. Building a new shiny toy project ? Go ahead use whatever language you love. Again, it is about cost vs benefit.

codeulike 6y ago
Reminds me of "PHP Hammer" I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there. You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes. You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways. You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever. And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools. Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door. That’s what’s wrong with PHP. https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ edit: Flickr user @raindrift made an actual PHP hammer, famously https://www.flickr.com/photos/nicoletbn/6949293600 https://www.flickr.com/photos/nicoletbn/6949293600 2012 discussion of hammer https://news.ycombinator.com/item?id=3866488 https://news.ycombinator.com/item?id=3866488 TechCrunch defence of the hammer https://techcrunch.com/2012/07/28/not-that-kind-of-filthy-get-your-mind-out-of-the-gutter/ https://techcrunch.com/2012/07/28/not-that-kind-of-filthy-ge...
- hnarn 6y ago
  That's funny and all, but it doesn't drive home much more of a point than "PHP is bad because PHP is bad". The insinuation that all "houses" built with PHP are defective and waiting to fall apart is so obviously untrue that it feels unworthy of discussion. A more reasonable analogy would be that there's a standardized toolbox that carpenters use that's weird, quirky and sometimes so bad that you need to know workarounds to use it correctly, but the houses that are being built do what they're supposed to in the vast majority of cases because most of the carpenters know the quirks well. The question then is, if you're contracting someone to build your house, or you're the manager of a construction company, do you go with the standard toolbox that's used by the X% majority of carpenters, or do you hire carpenters that use more obscure (but functionally "better") toolboxes while running the risk of now ending up with unmaintainable or deviating houses that are hard to recruit additional carpenters for because they refuse to work on what is quite objectively "non-standard" houses? The answer in my mind is no less complex than it would be for software development: it depends, and you should be wary of anyone telling you that it's "obvious" that the answer is one or the other.
  - codeulike 6y ago
    Fair point about the houses
- xd 6y ago
  As yes, the 2012 fractal of bad design, being peddled out yet again - your post is just pure hate, it adds no valid argument whatsoever.
- wccrawford 6y ago
  I think a better analogy would be that the PHP carpenters have standard old tools that people have used forever, and they work just fine. Normal hammer with wooden handles, normal planes, etc etc. But there are modern carpenters that have hammers that are 100% metal and never break and actually improve your hammering power. The new electric hand planes work a lot faster, though you do have to be more careful because they can get out of hand quicker. etc etc. In the end, they both build houses. The old-school carpenters might take longer, and they might have to know more techniques, but they get there in the end. On the other hand, the modern carpenters sometimes go a littler overboard with their tools and have problems that old-school carpenters don't have, especially with their tools randomly stopping working in the middle of a job. It might not be often, but it happens. To add to that, the old-school carpenters can actually use a lot of the new tools, too. They fit into the workflow and can be adapted to their old tools. It's just that they primarily stick with their old tools because they're used to them. It's kind of interesting how much the world of woodworking and software development overlaps in that way.
iamgopal 6y ago
well, on the other hand, if you are starting from scratch as a new developer, trying out go or rust is not too risky as large orgs backing it up. Also, for me, hosting go is much easier than php, as I am not from that era.
andi999 6y ago
I am wondering this: are people who do crud apps (in php or otherwise) do consider race-conditions in the database? Like one query and then based on that query another one which inserts/updates? And if so, where can I read about the standard techniques used in practice?
- SPBS 6y ago
  https://blog.coeo.com/a-cheat-sheet-for-isolation-levels-in-sql-server https://blog.coeo.com/a-cheat-sheet-for-isolation-levels-in-... The standard technique is deciding which isolation level you want to use for your queries.
- jpalomaki 6y ago
  Database transactions is the topic you should look into. There's ways to handle these in all environments. https://en.wikipedia.org/wiki/Database_transaction https://en.wikipedia.org/wiki/Database_transaction
  - andi999 6y ago
    Thanks. So is the general industry practice? I read MySql only supports this since like 2004, somehow reading material doesnt seem to be too concerned about these.
SergeAx 6y ago
You can't rely on a compiled/JIT language to address performance requirements. There's always time when your server is overloaded, no matter if it can handle 100 or 10000 RPS. You should architect your app with scalability in mind. And then there's not much difference between languages, only marginal savings on infrastructure. But one month of decend web server host costs about the same as one hour of decent software engineer.

glandium 6y ago

That's true, until a stupid non-rate limited web spider takes most of your resources.

jetter 6y ago

Well, good performance of http request/response cycle is mostly related to async operation, in some form, when long-lived daemon can process big amount of requests without spending time on initialization. Workerman and swoole, powered by async PHP approach, are very fast and suitable for high load. The problem with async PHP, though, is that you need to be careful with libraries (e.g. mysql client) because most of them were designed with short-lived PHP script execution in mind.

Cthulhu_ 6y ago

200-500 requests per second? I'm sure it can do a ton more. Here's some benchmark numbers: https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=composite&l=zik073-1r https://www.techempower.com/benchmarks/#section=data-r19&hw=... I don't believe the constraint would be the language itself, not with accellerators, opcode caches, JIT compilers, etc. I've always been told that PHP's performance is more down to the database than anything else.

Mikushi 6y ago

> my point was php is slow and max throughput is 200-500 rps Absolutely not, you could already go to 5k rps 10 years ago and PHP has massively improved since.

fetbaffe 6y ago

Because the alternatives is actually not good, it just a fallacy. There will always be something negative regardless of what you pick, problem is to decide what your core values are when writing different types of software. If you don't, you are just comparing apples to oranges. When it comes to PHP, core values are usually things that has to do with tooling, server architecture & deployment, not much the language (syntax, expressions, lambdas, classes etc) it self, except maybe it is easy to learn & use. This means that developers who comes from a background of that the language itself is the most important part of a project will most of the time just get confused what PHP is about.

kijin 6y ago

> php is slow and max throughput is 200-500 rps I don't know where you pulled that number out of, but I just used an outdated version of `ab` to request the Hello World page of a fairly heavy PHP framework on a modest virtual server and got over 4k rps. Give me a proper server box and a well-written application, and I'll deliver the 25k rps that you want. Besides, most webapps spend most of their execution time waiting for the database, memcached, redis, elasticsearch, or whatever. The speed of the language runtime makes very little difference.

fraktl 6y ago

Dev. here, using PHP for 20 years. Short story: I'm working on a system that peaks at 200k rps. Using PHP with Swoole.

deleted 6y ago

[deleted]

zapt02 6y ago

This is correct only if you run "Hello World" apps on a single server. PHP scales horizontally so any real-world application can easily scale to 10, 100 or 1000 servers. If there is no other scaling challenges (like databases) then it can scale forever thanks to its beneficial process model.