3 ms·

Maybe not for the user, at least not directly, but developer experience is something to optimise for. PHP is also the one language whose choice can make an imp

by dvdkon 3y ago

Maybe not for the user, at least not directly, but developer experience is something to optimise for. PHP is also the one language whose choice can make an impact on users' experience, since its shared-nothing (sans caches) runtime model is almost CGI-like and can, in my experience, lead to higher latency, as each request simply does more. Maybe some experienced PHP devs can tell me how they combat this?

mattnewton 3y ago
The most common defense I hear here is that the inefficiency just never mattered.. and if it did it was because the product was a blockbuster success and you could hire to rewrite the slow parts or adopt hack or whatever.
- oaiey 3y ago
  It does not when your project has not 100s of users hitting at the same time. And honestly, which application survives that at first sight and does not need to solve the problem one level higher (like building for load balancing, writer/read databases, etc ).
  - bawolff 3y ago
    I mean, generally what matters is how things scale. This type of slowness is trivially solved with horizontal scaling. Not just that, as a design choice, shared-nothing makes horizontal scaling easier. So this type of slowness isn't really the type that matters, and if anything is actually a net benefit at scale. [Unless you are truly latency-critical, but quite frankly that is pretty rare and php would probably not be the best choice for that at any scale]
9dev 3y ago
There are multiple options by now. For one, PHP got a JIT compiler a while ago. That, in combination with the existing opcode cache, actually causes PHP to outperform its interpreted competitors in most cases. Additionally, there are several application server strategies, sometimes with a process manager that keeps preloaded request workers at hand, sometimes hosting an event loop, and sometimes a request worker that gets partially reset after handling requests. This yields performance comfortably comparable to optimized Node.js apps. In general, PHP has a highly optimized runtime, and we didn’t even really touch caching yet. Trust me when I say performance is not one of the problems PHP poses :)
- oaiey 3y ago
  And not to forget traditional web server caching. Since they mimick html files on the server, doing your app right, you can use the very mature caching options in the web server / proxies.
monkey_monkey 3y ago
If you need it, Swoole and Roadrunner exist
bawolff 3y ago
> since its shared-nothing (sans caches) runtime model is almost CGI-like and can, in my experience, lead to higher latency, as each request simply does more. Maybe some experienced PHP devs can tell me how they combat this? I mean, you kind of answered your own question - they use caches like apcu or memcached. Apcu is just shared memory so its basically ends up being very similar to languages that don't do shared nothing.

by dvdkon 3y ago

mattnewton 3y ago

The most common defense I hear here is that the inefficiency just never mattered.. and if it did it was because the product was a blockbuster success and you could hire to rewrite the slow parts or adopt hack or whatever.

oaiey 3y ago
It does not when your project has not 100s of users hitting at the same time. And honestly, which application survives that at first sight and does not need to solve the problem one level higher (like building for load balancing, writer/read databases, etc ).
- bawolff 3y ago
  I mean, generally what matters is how things scale. This type of slowness is trivially solved with horizontal scaling. Not just that, as a design choice, shared-nothing makes horizontal scaling easier. So this type of slowness isn't really the type that matters, and if anything is actually a net benefit at scale. [Unless you are truly latency-critical, but quite frankly that is pretty rare and php would probably not be the best choice for that at any scale]

9dev 3y ago

There are multiple options by now. For one, PHP got a JIT compiler a while ago. That, in combination with the existing opcode cache, actually causes PHP to outperform its interpreted competitors in most cases. Additionally, there are several application server strategies, sometimes with a process manager that keeps preloaded request workers at hand, sometimes hosting an event loop, and sometimes a request worker that gets partially reset after handling requests. This yields performance comfortably comparable to optimized Node.js apps. In general, PHP has a highly optimized runtime, and we didn’t even really touch caching yet. Trust me when I say performance is not one of the problems PHP poses :)

oaiey 3y ago
And not to forget traditional web server caching. Since they mimick html files on the server, doing your app right, you can use the very mature caching options in the web server / proxies.

monkey_monkey 3y ago

If you need it, Swoole and Roadrunner exist

bawolff 3y ago

> since its shared-nothing (sans caches) runtime model is almost CGI-like and can, in my experience, lead to higher latency, as each request simply does more. Maybe some experienced PHP devs can tell me how they combat this? I mean, you kind of answered your own question - they use caches like apcu or memcached. Apcu is just shared memory so its basically ends up being very similar to languages that don't do shared nothing.