4 ms·

PHP has to bootstrap everything on every single request. It is definitely great for reloadability and local development but terrible for production performance.

PHP has to bootstrap everything on every single request. It is definitely great for reloadability and local development but terrible for production performance. Most teams that do not need PHP or love it (Laravel is great I know) have moved to using languages and frameworks that provide a long running application server.

mjburgess 6y ago
The "run once and die" model of php applications however, it extremely clarifying and simplifying. It is a bit like the unix philosophy of "simple apps, in sequence" -- in the sense that it clarifies what development should be. PHP apps, at their best, were multiple "run once and die" endpoints -- the drive to "Front Controller" and "run long" apps throws away much of the value of this paradigm. Part of the community problem, id say, is that this paradigm was never well-articulated; and always associated with "a mess". People like rasmus tried: yes have your long-running apps (eg., in Java), but your front-end should be die-quickly.
toast0 6y ago
PHP isn't that bad for production performance, if you have the right mindset. Another way of saying PHP has to bootstrap everything on each request (which is a bit of an overreach; it doesn't reload C libraries, and you can do opcode caching and data caching, etc), is that PHP throws away everything you've done after each request. That means everything that you build that isn't output somewhere is garbage. If you spend a lot of time making a sculpture out of garbage, only to throw it away, you'll have poor performance. If you use the minimum of scaffolding to send out the bytes you want to send, you can get pages (or api responses, whatever) with a few ms of overhead in addition to your underlying data fetches. You could certainly go faster with something else, but PHP can be decently fast. On the other hand, your code won't look at all like what people think of as 'modern' PHP.
allan_s 6y ago
I'm really sorry to say this but you're spreading FUD 1. slack backend is written in php and other big companies. 2. php is actually faster than python/ruby 3. opcache in production (which is both simple to activate AND a well-known best practices among people doing php professionally) eliminate the performance hit you will get. 4. your backend language performance is often far from being the bottleneck in most endpoint where performance do matters , it's often either a database optimization problem, an algorithm problem or a really CPU intensive tasks that you will offload to a dedicated library written in C. I perfectly understand PHP does have a lot of flaws, but production performance is not one.

mjburgess 6y ago

The "run once and die" model of php applications however, it extremely clarifying and simplifying. It is a bit like the unix philosophy of "simple apps, in sequence" -- in the sense that it clarifies what development should be. PHP apps, at their best, were multiple "run once and die" endpoints -- the drive to "Front Controller" and "run long" apps throws away much of the value of this paradigm. Part of the community problem, id say, is that this paradigm was never well-articulated; and always associated with "a mess". People like rasmus tried: yes have your long-running apps (eg., in Java), but your front-end should be die-quickly.

toast0 6y ago

PHP isn't that bad for production performance, if you have the right mindset. Another way of saying PHP has to bootstrap everything on each request (which is a bit of an overreach; it doesn't reload C libraries, and you can do opcode caching and data caching, etc), is that PHP throws away everything you've done after each request. That means everything that you build that isn't output somewhere is garbage. If you spend a lot of time making a sculpture out of garbage, only to throw it away, you'll have poor performance. If you use the minimum of scaffolding to send out the bytes you want to send, you can get pages (or api responses, whatever) with a few ms of overhead in addition to your underlying data fetches. You could certainly go faster with something else, but PHP can be decently fast. On the other hand, your code won't look at all like what people think of as 'modern' PHP.

allan_s 6y ago

I'm really sorry to say this but you're spreading FUD 1. slack backend is written in php and other big companies. 2. php is actually faster than python/ruby 3. opcache in production (which is both simple to activate AND a well-known best practices among people doing php professionally) eliminate the performance hit you will get. 4. your backend language performance is often far from being the bottleneck in most endpoint where performance do matters , it's often either a database optimization problem, an algorithm problem or a really CPU intensive tasks that you will offload to a dedicated library written in C. I perfectly understand PHP does have a lot of flaws, but production performance is not one.