I always try to be a little bit politically incorrect when writing these articles, after all I do it for fun (but always trying to be respectful and provide useful information!) I was about not to publish this particular one because I didn't like the final numbers and had the feeling that there was something wrong. It all got messed up when I came accross the bug in PHP and spent more than expected on the benchmark because I took my time to workaround it in D8 for the tests and report it to the PHP bug queue. When the time to do the benchmarks came, I was on a rush.
1) You are right, but I have seen that the issues that get the most "commercial" visibility are those related to high level caching.
Issues like this one "Make D8 2x as fast [...]" got a lot of attention, but the title itself is missleading. D8 twice as fast in..... what scenarios?
Take a look the issue Figure out why Drupal 8 is slow. Having such an issue when the final piece of software is close to release is not a bad thing after all. But compare these two different interpretations of that same issue:
a) We designed all this to be blazing fast, we followed best practices and have been meticulous in the development, but it is still too slow, something must be wrong and we need to spot it.
b) We are close to release, and this thing is still full of performance issues, what's up?
What is that issue closer to, a or b? They are even paying attention (which is good) to 1ms/request performance gains patches, but that starts to sound like the north is lost.
2) You are right again. I must confess that Drupal 8 tag based caching system and its fine integration with the overal architecture is extremely good. It will sure come in handy and make a big difference. But that does not invalidate any of the statements I made. Many people rely on high level caching on a regular basis to cover for an application's poor perfomance. That happens too often in D7. I've heard people say like yes this "site" is fast - with page caching turned on - but it's barely usable for anything that is not read-only anonymous pages.
3) Let's run it again with more time! I am unable to disable internal page caching. This is supposed to be a module now, but it is required in the standard install profile, so I cannot disable it? The numbers have gotten worse compared to the last benchmark. This is about 1/5 slower than Berdir's benchmarks.
PHP7, page cache on:
Requests per second: 81.23 [#/sec] (mean)
Time per request: 12.311 [ms] (mean)
PHP7, page cache off:
Requests per second: --- [#/sec] (mean)
Time per request: --- [ms] (mean)
PHP 5.6, page cache on:
Requests per second: 24.47 [#/sec] (mean)
Time per request: 40.863 [ms] (mean)
PHP 5.6, page cache off
Requests per second: --- [#/sec] (mean)
Time per request: --- [ms] (mean)
I always try to be a little bit politically incorrect when writing these articles, after all I do it for fun (but always trying to be respectful and provide useful information!) I was about not to publish this particular one because I didn't like the final numbers and had the feeling that there was something wrong. It all got messed up when I came accross the bug in PHP and spent more than expected on the benchmark because I took my time to workaround it in D8 for the tests and report it to the PHP bug queue. When the time to do the benchmarks came, I was on a rush.
1) You are right, but I have seen that the issues that get the most "commercial" visibility are those related to high level caching.
Issues like this one "Make D8 2x as fast [...]" got a lot of attention, but the title itself is missleading. D8 twice as fast in..... what scenarios?
Take a look the issue Figure out why Drupal 8 is slow. Having such an issue when the final piece of software is close to release is not a bad thing after all. But compare these two different interpretations of that same issue:
a) We designed all this to be blazing fast, we followed best practices and have been meticulous in the development, but it is still too slow, something must be wrong and we need to spot it.
b) We are close to release, and this thing is still full of performance issues, what's up?
What is that issue closer to, a or b? They are even paying attention (which is good) to 1ms/request performance gains patches, but that starts to sound like the north is lost.
2) You are right again. I must confess that Drupal 8 tag based caching system and its fine integration with the overal architecture is extremely good. It will sure come in handy and make a big difference. But that does not invalidate any of the statements I made. Many people rely on high level caching on a regular basis to cover for an application's poor perfomance. That happens too often in D7. I've heard people say like yes this "site" is fast - with page caching turned on - but it's barely usable for anything that is not read-only anonymous pages.
3) Let's run it again with more time! I am unable to disable internal page caching. This is supposed to be a module now, but it is required in the standard install profile, so I cannot disable it? The numbers have gotten worse compared to the last benchmark. This is about 1/5 slower than Berdir's benchmarks.
PHP7, page cache on:
Requests per second: 81.23 [#/sec] (mean)
Time per request: 12.311 [ms] (mean)
PHP7, page cache off:
Requests per second: --- [#/sec] (mean)
Time per request: --- [ms] (mean)
PHP 5.6, page cache on:
Requests per second: 24.47 [#/sec] (mean)
Time per request: 40.863 [ms] (mean)
PHP 5.6, page cache off
Requests per second: --- [#/sec] (mean)
Time per request: --- [ms] (mean)