You really can't compare Drupal 7 on PHP 5.5 with Drupal 8 on PHP 7. Perhaps try compare it to Drupal 8 on PHP 5.5, or if your D7 site runs on PHP 7 then compare that.
[Update: It turns out the Drupal 7 site we tested had page caching disabled. With page caching enabled, the scalability of anonymous pages seems very comparable -- we're seeing between 30 and 83 requests per second on both Drupal 7 and Drupal 8 on our base server configuration, with caching enabled, varying by website.
However, page caching can be enabled on many more Drupal 8 sites than Drupal 7 -- many Drupal 7 sites cannot enable page caching due to content that varies by user -- whereas nearly every Drupal 8 site can use caching, thanks to Drupal 8's intelligent cache tagging and invalidation.]
We had a client reach out about an error page they got on their site:
What? Normally we get alerted to this kind of thing. Sometimes it's a result of a "Denial of Service" attack, but we have had some stability trouble recently with a Linux kernel killing processes because it prematurely thinks it's out of memory -- when this happens we need to go into the server and restart the affected container.
Not this time -- the site loaded up and looked fine. What happened?
First, I checked our alerting system. No sign of any alerts sent, no indication of a recent change. The system does wait for 5 minutes before sending an alert, but nothing got sent.
Next, I checked our performance monitoring system, and it showed a big load spike during the time in question:
... and there was a similar spike in traffic. What happened, and why didn't we get alerted?
Well, we didn't get alerted because the entire event was over and done and back to normal in less than 3 minutes -- not long enough to trigger anything.
Next, I hopped on the server to see what was going on there. Looking through the Nginx error logs, I found a bunch of messages:
2017/02/09 16:47:56 [alert] 43#43: 768 worker_connections are not enough
... This was right in the affected time. A bit of log analysis later, and I had determined that all of this traffic was generated from a single IP address over the course of 2 minutes, and had resulted in over 2900 error responses. And these all came from "artillery 2.3.3 (https://artillery.io)".
Artillery turns out to be a very cool website load testing tool. We've used jMeter and ab in the past for this kind of thing, though we haven't yet worked this into our regular routine. So I decided to check out Artillery. It's written in node.js, which is one of the technologies we use routinely here, and it seems to be very easy to get started and use. So, of course, I had to give it a quick spin.
Drupal 7 results - Nginx, PHP5.5, MariaDB - 2 requests per second
So I pointed it at a handy Drupal 7 site out of curiosity -- you can guess which one -- built up to handle a similar amount of load as our client. This is already a bit faster stack than most regular shared hosting, but starting with the example in the documentation for "artillery quick", 10 requests per second were enough to crush the server. We had to go down to 2 requests per second to have the server able to handle the traffic without starting to back up requests. At 3 per second, the latency started creeping up over 10 seconds, and any more we started getting gateway timeouts.
Drupal 8 results - Nginx, PHP7.0, MariaDB - 83 requests per second
Curious, I pointed artillery to a recent Drupal 8 site on pretty much the same infrastructure, the only other difference being PHP7. And kept throwing more and more requests at it -- the server kept turning them around in less than 3 tenths of a second, until we went all the way to 100! At 100 requests per second, we finally got some errors -- on about 0.5% of the requests (30 out of ~6000!)
To get a sustainable amount with the current relatively stock tuning we have on the server, 83 requests per second was the magic number -- at that rate, the maximum latency was still less than 0.3 seconds (which already beat the minimum latency on the D7 site at ~0.5 seconds!)
Drupal 8 is a speed demon.
I've heard people complain about Drupal 8 being bloated, slow, and unweildy. And... that turns out to be utter hogwash. Drupal 7 with some caching configuration can easily beat similarly complex WordPress sites, but it's not even in the same race as Drupal 8, handling 1/40th as much traffic on essentially the same hardware.
And, we haven't even optimized anything on the Drupal 8 configuration yet. We can add Redis for higher speed caching, a Content Delivery Network to speed up assets and allow multiple front ends, and much more.
If you're looking to have the fastest, most flexible, most powerful CMS out there, look no further than Drupal 8. And contact us if you need any help!
Yeah those results are almost exclusively the result of PHP7. I'm cool w/ the push to get people to upgrade to D8 but at least use fair numbers. D7 + contrib is still just as fast as D8 (especially once in the PHP7 land) from what I've seen previously when environments are comparable (though this was before big pipe). If your talking stock D7 vs D8 that would be another fair assessment (tho no one runs D7 stock)
I had tested Drupal 8 and Drupal 7 under PHP 7.. The results are clear, Drupal 7 is 3x times faster than Drupal 8 for dynamic content (for logged in users).. The results can be found here: https://www.drupal.org/node/2666614#comment-11185301
What caching did you have enabled with that? Because that doesn't jibe with my findings for D7/D8 author's traffic when the Dynamic Internal Page Cache is enabled on D8. It is significantly faster for authenticated users, my teats show by 4-5x.
That kind of result makes me wonder what other differences there are in terms of modules on the site, views or other elements on the page that might render slow, front end widgets like share buttons that might also cause front end delays, etc.
I've done a lot of testing with various configurations on Drupal 7 and 8 sites, and D8 is always slower uncached. Cached, D7 with nothing in front of it is still slightly faster, but the more granular caching levels in D8 mean that real world use can lead to more cache hits, meaning better average performance.
However, blanket statements like 'Drupal 8 is blazing fast’ need a lot more qualification, and reproducibility.
But it turns out that caching is -- the site I was testing had page caching disabled.
We've run a bunch more tests, and will update the blog post soon.
In short, changing from PHP5.5 to PHP7.0 on the site that could handle 2 requests per second got it to ... 4 requests per second. On another site, the difference between PHP5.5 and PHP7 was 60 requests per second to 80 requests per second. Clear improvement, but not huge.
Caching made a huge improvement. Turning caching on made the site go from 2 requests per second to 60 requests per second -- but it also broke functionality, and so the granular caching ability of D8 is a clear improvement here.
We are seeing between 27 requests per second and 83 requests per second on our Drupal 8 sites, depending on how complex -- though the sites we were testing have 1/2 as much RAM on the server as many of the D7 sites. For D7, we're seeing very similar numbers, 30 request per second to 83 requests per second.
We're not seeing Drupal 8 sites slower than our Drupal 7 sites, though a lot of our sites are on the more complex end of the scale -- the Drupal 8 sites we work on "feel" snappier, except when doing cache rebuilds...
Test results like these are useless when not mentioning hardware/server configuration. And a change from 60 to 80 concurrent requests is 50% improvement, so how come u call this small
These are all run on a very similar server configuration, on Cloud VPSs (in these cases, Digital Ocean and Google Cloud Engine). Base server OS is Ubuntu, but the actual server daemons are all running in Docker. Nginx 1.10.1, MariaDB 10.1.21 (Debian Jessie). The PHP differences were measured on exactly the same environment, the only difference being from swapping the PHP5.5 container for an equivalent PHP7.0 container.
The Drupal 7 site I was testing I would expect to handle more traffic, because it has 3.7GB of RAM available, some tuning done on MariaDB, and the base OS is running Ubuntu 16.04 with kernel 4.4. The D8 site is actually running on only 2GB of RAM, on Ubuntu 14.04 with kernel 3.13. It does look like the virtual CPU available for the D8 site is 2 cores running at 2.4GHz, while the D7 site is a single core at 2.6GHz.
60 - 80 is a 33% increase, not a 50% increase... and not the "Big factor," which was the 3000% increase of turning on page caching (and breaking the functionality of the site...)