About Us / Our Blog

Early Drupal 7 vs Drupal 8 performance comparison


I'm very excited about the upcoming Drupal 8 release and its features and even though I'm not a core developer (yet), I follow its development as close as I can. There are numerous blog posts about it and the new features it has. There are hundreds (if not thousands) of issue queues where you can watch our community discuss and build the new system, you can even try the freshest dev release by using SimplyTest.me.

But, while there is a vast amount of information about Drupal 8, I couldn't find any metrics about how it will compare with Drupal 7 performancewise. I know that we're not in code freeze yet and that performance improvements are scheduled for the "polish phase" which officially starts on 1 July, but I was curious to see how Drupal 8 performs at this stage, where many API's have changed, a lot of hooks have been replaced and a new framework is implemented into it (Symfony2).

So, I thought that since there was no such information on the net yet, I would find out myself. So, here is a quick and dirty performance comparison between the latest Drupal 7 version (7.22) and the latest dev build (1 June) of Drupal 8.

Test setup & methodology

I downloaded and installed both systems on my MacBook Air (1.7 Ghz Intel Core i5, 4Gb 1600 Mhz DDR3 RAM) and measured requests per second on MAMP with PHP 5.4.4. I used ab (apache benchmark) with 20 concurrent requests (-c 20 -n 20). So, on the following table, you can see the amount of requests per second that MAMP was able to serve for 4 different cache settings and 3 default pages: Admin home page and site homepage as it comes when you install the Drupal standard profile for both anonymous and logged in users.

For each metric, I used the highest number I got after 10-15 consequent measurements.



Requests/sec (more is better)


Drupal 7.22

Drupal 8 dev

APC & internal cache disabled

admin homepage (/admin)10.255.07
homepage, logged in10.574.25
homepage for anonymous users11.664.56

APC disabled, internal cache enabled

admin homepage (/admin)10.325.09
homepage, logged in10.584.17
homepage for anonymous users11437

APC & internal cache enabled

admin homepage (/admin)4914.02
homepage, logged in4311.44
homepage for anonymous users491147

APC enabled, internal cache disabled

admin homepage (/admin)5014.17
homepage, logged in4311.43
homepage for anonymous users6514.04


When I saw the results, I got disappointed. I had a secret hope that I would see Drupal 8 perform better, even though this was not the logical result.

In the above table we see a 50%-78% performance regression which is rather big. Do you think this is the expected result? Do you see any flaws in the above methodology? Am I missing something? At which phase do you think it would be wise to test again? Feel free to leave your comment below.

Anyhow, I hope the Drupal community will do a really good job at the polish phase and deliver a really fast Drupal 8.


Andrei's picture
"At which phase do you think it would be wise to test again?" How about after we fix all known regressions? https://www.drupal.org/node/1744302
John_B's picture
Thanks for doing this. Interesting. You should probably mention which modules were enabled on each test site. With Views in Core in D8, maybe your tests were run on a site with Views enabled? in which case a fairer test would be to compare D8 with D7 + Views. And so for other modules.
Ανώνυμος's picture
Make sure the xdebug extensions isn't loaded. D8 is extraordinarily affected by its slowing down of function calls.
yannisc's picture
Andrei, this is a very interesting issue. I'll follow that. John_B, I tested both systems with the standard profile. So, D8 has views enabled by default, D7 not. You have a point there, I'll try testing with views enabled in D7. Anonymous, Xdebug was not installed.
Marius's picture
Very interesting article. But besides views, drupal 8 has a lot more modules enabled by default that can cause that performance regression. I think you should try to compare with drupal 7 and all these modules. Here's a list of what I found: Breakpoint, Ckeditor, Configuration Manager, Contact, Custom Block, Datetime, Edit, Entity, History, Tour, Views, Views UI, Interface Translation, Language.
yannisc's picture
Marius, my goal was to compare 2 clean, default installations. If Drupal 8 adds more modules by default and that causes performance regressions, then I think this is an issue. By the way, I don't believe it's a matter of enabled modules, but a matter of a different framework which is not optimized yet.
dave's picture
Drupal 8 makes heavy use of the Object Oriented design pattern. Nearly all procedural code from Drupal 7 has been (or will be) converted to OOP. This comes with a tradeoff. Procedural code is faster because it's easier for PHP to interpret. It works well for small projects, but as a the codebase grows, it quickly becomes unmaintainable. OOP code collects functions and variables into objects called Classes. The result is code that is easier for humans to understand but requires more effort for PHP to interpret. It's not terribly surprising and certainly shouldn't be disappointing to see these results. What Drupal 8 is losing in performance is made up for in code maintainability. This means a lower barrier-of-entry for developers wanting to contribute to core development. As others have mentioned, Drupal 8 is still under heavy development and performance issues are expected to be addressed after the code freeze at the end of this month.
Nate Haug's picture
Nate Haug
Thanks for doing these tests. It seems pretty much inline with what we know already about D8... that it's quite a bit slower. I found your numbers on D8 APC to be interesting. With APC I would have expected a similar 5x improvement over D8 non-APC. You might want to make sure that APC has enough memory allocated that it didn't run out while caching all D8's files. I'd also suggest you rename "internal cache enabled" to "page cache enabled". Drupal does not allow you to disable its internal cache, which is used for many, many things. The page cache is the only setting you have control over, and it only affects anonymous users viewing cached pages. Authenticated or admin pages with the page cache either on or off doesn't make any difference.
yannisc's picture
Nate, this is not quite a bit slower. It's much much slower. I agree that we're still in early stages and that this may change until final release. As for the internal cache naming, I understand what you say, but I used the term that is used in Drupal 8 performance settings page "Use internal page cache".
nbz's picture
Since Views is in core and Views in enabled on like 80% of sites out there, maybe compare Drupal 8 with its almost comparable - "Drupal 7 + Views"?
rdickert's picture
Great article. I'd love to see follow up articles tracking D8's progress in this area. D7 is already very marginal on shared hosting. Is D8 going to run on shared hosting at all? If so, what of all the small sites using Drupal? When I first was looking for a CMS, my organization had a Godaddy account. This was early after the release of D7, when building on D7 carried a large risk (the date module recommended running views' dev build), but Godaddy insisted on offering only D7 for automatic installation, as they incorrectly surmised that D6 support was ending. If they do this with D8, there will be lots of people who casually try it and decide Drupal is not worth pursuing. We could be leaving the small site behind at the very moment when Drupal is achieving the feature set they will need.
peter's picture
@dave: "This means a lower barrier-of-entry for developers". Who would ever say OOP is easier than procedural? I have been writing Drupal modules since D4 days and would have to say that the coding complexity jump from 5 to 6 was manageable. From 6 to 7 was significantly more extreme. And from 7 to 8 is more extreme than that. A think Acquia is pushing (and maybe rightly so??) Drupal to be the solution THEY need for their enterprise clients by adding complexity that will be used on less than 2% of Drupal sites. I do see advantages in OOP; but honestly had always assumed performance was one of these (ease of programming certainly isn't). This is an excellent report to show that even performance is not one of the gains here.
Diane Bryan's picture
Diane Bryan
Don't you hate it when clients ask to look over the site before you've had a chance to tighten it up? Of course what they see is the thing you did not yet give any attention to, and they start drawing conclusions that, as yet, have no foundation in the reality of the final product. These metrics serve the purpose of underscoring the importance of final tweaking (fixing regressions), and of balanced testing. You definitely want to compare apples to apples. I always use Views, so let's see (at least) adjusted results with Views loaded and active on both. Or better yet, let's understand these results to be a simple call to action.
Mark W. Jarrell's picture
Mark W. Jarrell
Thanks for helping to draw some attention to the performance issues before we get too far down the road in the Drupal 8 development life cycle.
Slava's picture
Well, it's like let's compare Boeing in the air with half-built airplane in design department and (no wings & tail added yet) and see which is faster. Is this article useful? I'm sorry, no. Why? see above. Let's do comparison D7 versus D8 alpha or beta at least (i'm not even speaking about RC version).
IanMThomasUK's picture
@peter "Who would ever say OOP is easier than procedural?" For a relatively small set of scripts procedural is definitely easier than OOP, but as the code base grows it can become unmanageable. OOP adds a level of modularisation, reducing the complexity of each module. Yes you need to learn the OOP concepts first, but speaking as a developer who came to Drupal at version 7 when I was already confident in OOP, I'm expecting Drupal 8 to be easier to code for.
Phil's picture
Hate to say it, but installing views for D7 won't make much of a difference. D7 views out of the box, doesn't handle any admin tasks whereas D8 admin tasks are mostly handled by views (I think?) I haven't dove into how exactly D8 works, but from what I've seen, it will be extremely heavy on disk I/O until some proper caching methods are implemented. D7 is mainly only reading one area of the disk I.E. the database file which will provide less disk time. (In theory) Regardless, an interesting comparison. I've wondered myself how the two would compare in this department and thought that a caching system of compiling a yaml file on the fly or something might be in order to help reduce the disk I/O issues... I'm a nobody in this area of expertise though and only have theories to go on :-/
Frank Church's picture
Frank Church
I have always felt that the Drupal community should leverage its skills on a better language than PHP. Something like Drupal should be built on its own scripting language. PHP is just too unwieldy and verbose for that purpose. With the breadth and depth they possess it shouldn't be too difficult. They should use Drupal 8 get the OOP bits sorted out and switch by Drupal 10.
alex.barylski's picture
Thanks for the profile. I downloaded 8 a few weeks ago and started playing with it. When I heard about the usage of Symphony I was excited to see Drupal heading in a OO manner. After browsing the implementation and experimenting with building a module I have to say I am disappointed by the added complexity and for what appears (I am not an expert Drupal dev to take with grain of salt) to be little benefit other than using OOP for the sake of using OOP. Also the performance seemed so sluggish running side by side with D7 and here your tests confirm this. Regards, Alex