4 ms·

> It took less than a week to migrate our codebase (a 10 years old PHP monolith)... > And it took 4 hours to migrate our custom extensions. That seems like a

> It took less than a week to migrate our codebase (a 10 years old PHP monolith)... > And it took 4 hours to migrate our custom extensions. That seems like a very small amount of work; I'm impressed at how smooth a transition that must've been. I'm also quite surprised that > we can handle twice more traffic with same infrastructure. Wow, I didn't think that PHP application code would be such a bottleneck. Maybe it's not that, but if the entire codebase is written in PHP, and you replace it all in one shot, you just get such an improvement. But I thought DBs, etc. would play a bigger role.

skippyta 10y ago
In the world of PHP 7, blocking I/O will still be a problem (at least, it was when I looked at the proposed feature set over a year and a half ago), but in PHP 5.x, the Zend engine is actually just incredibly inefficient, to the point where it is often the largest bottleneck on the request path.
geerlingguy 10y ago
For a lot of array-heavy applications (where you store all kinds of data in giant multi-level PHP arrays), the memory usage alone counts for most of the speedup; instead of wading through tens or hundreds of MB of array structures, PHP 7 trimmed things down by a factor of 2 or more. There are a lot of PHP apps/CMSes/etc that gained 30-50% speedups due to just that improvement. Other more optimized apps/scripts saw a much more modest gain.
- mgkimsal 10y ago
  IIRC, a PHP array entry had 127 bytes of overhead. PHP 7, that went down to 42(?). Also, IIRC, for JVM, it's .. 37? 40? PHP7 got array overhead down a lot, and I do believe that's where a lot of speed improvement came from (though certainly not all of it).
  - ucho 10y ago
    PHP array is equivalent to LinkedHashMap and yes, it has 40 bytes overhead per entry in Java.
  - TazeTSchnitzel 10y ago
    This talk's slides have a good summary of how much overhead was reduced: http://www.slideshare.net/nikita_ppv/php-7-what-changed-internally-php-barcelona-2015 http://www.slideshare.net/nikita_ppv/php-7-what-changed-inte...
brianwawok 10y ago
have you ever loaded a stock magento server? Set it up, add maybe 10 products with basic images, and turn it loose. Give it a reasonable box. 2 CPU cores, 2 GB of ram. You are capped at something like 3-5 requests per second, with an average load time of 5 seconds.. Just blows my mind. Simple Java web app on the same server is doing 500 requests per second. Python app, with the horrible gil and all that nasty is going 200 requests per second. And magento is rocking 3 requests per second??!?!?!?!?! I wonder how much global energy consumption would go down if PHP was not a thing.
- mgkimsal 10y ago
  comparing "simple java app" to something as complex (overly? needlessly in some cases? sure) as magento is nowhere near apples and oranges. compare it to broadleaf or konakart, maybe. I've no doubt java will probably still be faster, but it won't be 500 rps vs 3 rps.
  - brianwawok 10y ago
    Except I have built Java apps that did the same kind of things as Magento, and yes it really was 500 to 3.
    - corobo 10y ago
      Benchmarks or no you haven't.
      - kasey_junk 10y ago
        Without getting into a pissing war if Brian says he's done something on the JVM, trust him. Also if you need someone to validate that their system does 500 qps, you really need to check your assumptions. I'm trying very hard to think of what kind of system I'd build that would do less than that (hint each q would be big)
        corobo 10y ago
Noony 10y ago
Hey, I'm the author of this blog post, I'll try to respond to your questions: > Wow, I didn't think that PHP application code would be such a bottleneck. Maybe it's not that, but if the entire codebase is written in PHP, and you replace it all in one shot, you just get such an improvement. But I thought DBs, etc. would play a bigger role Indeed front-end servers not the only bottleneck to handle more queries. We also made data migrations on mysql databases to optimize memory utilization, two months after the php7 migration. Code migration and the validation that we hadn't introduced new regressions / errors by redirecting a small percentage of the traffic through two servers with php7 configured during few days before full deployment. Full deployment on our production farm (more than 250 servers) was done in less than two hours with the possibility of rollback) >> It took less than a week to migrate our codebase (a 10 years old PHP monolith)... >> And it took 4 hours to migrate our custom extensions. >That seems like a very small amount of work; I'm impressed at how smooth a transition that must've been. We used phan and phpcs to discover our incompatibilities, it doesn't find 100% of problems, but it really reduced time to find where there was backward incompatibilities. It's a first step before unit tests / small load test on production. I wrote a small blog post on how to use this tools to migrate your applications : https://medium.com/@colomb.thomas/php7-how-to-migrate-your-application-88154d99a88a#.qxbjwsatl https://medium.com/@colomb.thomas/php7-how-to-migrate-your-a... Thanks!

skippyta 10y ago

In the world of PHP 7, blocking I/O will still be a problem (at least, it was when I looked at the proposed feature set over a year and a half ago), but in PHP 5.x, the Zend engine is actually just incredibly inefficient, to the point where it is often the largest bottleneck on the request path.

geerlingguy 10y ago

For a lot of array-heavy applications (where you store all kinds of data in giant multi-level PHP arrays), the memory usage alone counts for most of the speedup; instead of wading through tens or hundreds of MB of array structures, PHP 7 trimmed things down by a factor of 2 or more. There are a lot of PHP apps/CMSes/etc that gained 30-50% speedups due to just that improvement. Other more optimized apps/scripts saw a much more modest gain.

mgkimsal 10y ago
IIRC, a PHP array entry had 127 bytes of overhead. PHP 7, that went down to 42(?). Also, IIRC, for JVM, it's .. 37? 40? PHP7 got array overhead down a lot, and I do believe that's where a lot of speed improvement came from (though certainly not all of it).
- ucho 10y ago
  PHP array is equivalent to LinkedHashMap and yes, it has 40 bytes overhead per entry in Java.
- TazeTSchnitzel 10y ago
  This talk's slides have a good summary of how much overhead was reduced: http://www.slideshare.net/nikita_ppv/php-7-what-changed-internally-php-barcelona-2015 http://www.slideshare.net/nikita_ppv/php-7-what-changed-inte...

brianwawok 10y ago

have you ever loaded a stock magento server? Set it up, add maybe 10 products with basic images, and turn it loose. Give it a reasonable box. 2 CPU cores, 2 GB of ram. You are capped at something like 3-5 requests per second, with an average load time of 5 seconds.. Just blows my mind. Simple Java web app on the same server is doing 500 requests per second. Python app, with the horrible gil and all that nasty is going 200 requests per second. And magento is rocking 3 requests per second??!?!?!?!?! I wonder how much global energy consumption would go down if PHP was not a thing.

mgkimsal 10y ago
comparing "simple java app" to something as complex (overly? needlessly in some cases? sure) as magento is nowhere near apples and oranges. compare it to broadleaf or konakart, maybe. I've no doubt java will probably still be faster, but it won't be 500 rps vs 3 rps.
- brianwawok 10y ago
  Except I have built Java apps that did the same kind of things as Magento, and yes it really was 500 to 3.
  - corobo 10y ago
    Benchmarks or no you haven't.
    - kasey_junk 10y ago
      Without getting into a pissing war if Brian says he's done something on the JVM, trust him. Also if you need someone to validate that their system does 500 qps, you really need to check your assumptions. I'm trying very hard to think of what kind of system I'd build that would do less than that (hint each q would be big)
      - corobo 10y ago

Noony 10y ago

Hey, I'm the author of this blog post, I'll try to respond to your questions: > Wow, I didn't think that PHP application code would be such a bottleneck. Maybe it's not that, but if the entire codebase is written in PHP, and you replace it all in one shot, you just get such an improvement. But I thought DBs, etc. would play a bigger role Indeed front-end servers not the only bottleneck to handle more queries. We also made data migrations on mysql databases to optimize memory utilization, two months after the php7 migration. Code migration and the validation that we hadn't introduced new regressions / errors by redirecting a small percentage of the traffic through two servers with php7 configured during few days before full deployment. Full deployment on our production farm (more than 250 servers) was done in less than two hours with the possibility of rollback) >> It took less than a week to migrate our codebase (a 10 years old PHP monolith)... >> And it took 4 hours to migrate our custom extensions. >That seems like a very small amount of work; I'm impressed at how smooth a transition that must've been. We used phan and phpcs to discover our incompatibilities, it doesn't find 100% of problems, but it really reduced time to find where there was backward incompatibilities. It's a first step before unit tests / small load test on production. I wrote a small blog post on how to use this tools to migrate your applications : https://medium.com/@colomb.thomas/php7-how-to-migrate-your-application-88154d99a88a#.qxbjwsatl https://medium.com/@colomb.thomas/php7-how-to-migrate-your-a... Thanks!