[emergentcypher]

- PHP is slow. Unlike JS, it's generally interpreted and not JIT (unless you're Facebook).

- Drupal has to bootstrap itself and all modules on every request.

- Drupal makes waaaaay too many SQL queries

- Drupal generates horribly performing SQL queries

[epimetheus]

PHP isn't that slow[0] by itself. Notice it's 10th on the list (Php5-raw), it outperforms Nodejs, Python, RoR and many others.

Drupal, on the other hand, is so slow because it has a terrible architecture.

[0] - https://www.techempower.com/benchmarks/

[knieveltech]

I'm kind of enjoying watching the developer community turn on Drupal like a pack of wolves. That said, aren't performance issues more or less unavoidable when you're dealing with a CMS? The scope of use cases they try to cover is pretty wide which is sure to lead to bloat.

[epimetheus]

I deal with Drupal (7.x) on a daily basis, so that's why you'll probably detect bitterness from me. Personally there are a myriad of reasons why Drupal rubs me the wrong way, most are Developer issues though (Such as their annoying comment form API, and arrays, arrays everywhere).

There are better CMSs out there, IMO, but we have to use Drupal because it's the only one that has a Certification of Networthiness (I work in the DOD) - and to make things worse for us, we have to use Drupal on IIS with MSSQL (for now). Why can't we just go with Umbraco (.Net)!?

[knieveltech]

I've been working with Drupal professionally since 4.7, have code in several contributed modules in D6 and D7, and used to organize the local Drupal User's Group. I know all about the bitterness. I've spent the last 10 years watching a lightweight and infinitely hackable CMS turn into a bloated morass of opinionated overweight APIs that make easy things complicated. Yeah I'm looking at you renderable arrays.

Anyway I'm counting the minutes until an Acquia PM spots this post and starts spraying down the comments section with 35 paragraph word salad breathlessly defending the heroic efforts of the core dev team to drag D8 into the 21st century, in the process entirely missing the point that this may very well be the first core release of Drupal that will not run on commodity hosting due to resource requirements.

[chx]

Note: I am not an Acquia PM. I am just someone who sent in a few core patches over the last 11 years.

When I got aboard Drupal core was a very lightweight CMS. Infinitely hackable, yeah, if you go and hack core. Been there, done that, got the T-shirt. Time flies, years pass, and contrib modules happen because users want to click in a browser and not hack core. CCK. Views. All that jazz. Maybe your core is still lightweight but surely not your whole site. Comes Drupal 7, we move some of that into core. Core near collapses under the tech debt incurred. Remember the issue "Field attach API integration for entity forms is ungrokable" reported by the ... field API maintainer. Opsie. So the core developers try to decrease that tech debt and move towards something they found desirable. That's how Drupal 8 came to be.

Dissing Acquia for core when the chief architect of everything wrong with Drupal 8 (who have basically pulled a fast one over the community in an ingenious breach of process) is not working for Acquia is pointless. There are quite a number of things you could diss Acquia for, there's no doubt, but core is hardly one of them. In fact, they paid Wim Leers to undo as much of the performance damage -- by introducing vast amounts of caching -- as possible.

[knieveltech]

Hold on bub, you're trying to tar me with the "Acquia-has-taken-over-core" conspiracy theorist brush and that's not what's happening here.

I'm dissing Acquia for their history of ridiculous marketing blasts that try to convince IT managers to upgrade to Drupal $N 18 months in advance of the contrib module space becoming sufficiently stable to seriously consider platforming a production environment on top of. Also for their PMs skulking around in various media channels breathlessly defending Drupal from any criticism regardless of accuracy.

I've been intermittently following your attempts to get various core initiatives to back away from the metaphorical ledge off and on since DC Portland. Sorry for all of us you weren't more successful.

[mitm2mitm]

> Dissing Acquia for core when the chief architect of everything wrong with Drupal 8 (who have basically pulled a fast one over the community in an ingenious breach of process) is not working for Acquia is pointless.

where can I read more about this? I enjoy good programming drama

[ausjke]

Does it have anything to do with symphony used in D8? or D7 is the same bad?

I used D5/D6/D7 for a low-traffic site these years.

[emergentcypher]

OK, I'll grant it this, PHP performance has improved quite a lot in recent years.

[dallbee]

PHP's speed is here is a bit of a red herring. I dislike linking to benchmarks, but https://www.techempower.com/benchmarks/#section=data-r12&hw=.... In I/O bound situations, PHP performs within an order of magnitude of C. You don't have to be Facebook, you literally just need to enable APC or XCache.

Let's focus on how horribly awful Drupal is. Or, to the point of the topic, let's congratulate the author for discovering that yes, you can in fact replace a single server with any number of cheaper computing devices (you just have to disregard all of the other reasons why we use servers).

[aasarava]

I'm an independent developer. The majority of my clients are on Drupal. Here's what I've learned:

While it's true that someone looking at Drupal's architecture for the first time is likely to say, "Whaaaa? Why, why, why?", the truth is that a lot of the decisions start to make sense once you need a CMS for more than a basic blog.

For example, the reason there are so many joins just to retrieve all the fields of data for a page is that Drupal allows each field to be shared across different content types, or to have different revisions, or even to have different translations from other fields on the same page.

Yes, this is going to feel awkward and slow if all you need is a simple blog post table with one post per row. But if your site is complicated enough or has enough traffic, chances are that you're going to start relying on caching to help out, no matter what CMS you use.

Drupal's no different. There's its own internal caching (which bypasses most of the queries for anonymous users), PHP's APC caching (which gets over the PHP loading hurdle), memcache (to bypass queries for logged in users), and Varnish (bypassing Drupal altogether for static content.)

[nkozyra]

I know it's been mentioned above, but PHP is very much not slow on its own. On that particular benchmark it's the highest interpreted language on the list (same with single query, fortunes and data updates). In fact, despite some atrocious language design, speed hasn't been a problem in a long time. And that's just PHP5, PHP7 offers claims of 100% speedup, not to mention HHVM.

I would wager that the typical bottlenecks are where the slowdowns are happening, and your hints about the # and types of queries would be my first guess.

[owyn]

Drupal isn't alone here. Mediawiki without caching does some horrible stuff. I just loaded a random page (with caching turned off) that does 1874 database queries. For one page. That it still loads in 7 seconds is a miracle.

[brianwawok]

How many SQL queries end up getting run if you are loading a simple page with 1 row read out of 1 table as the actual payload?

[knieveltech]

That never happens though. Drupal has to bootstrap itself so it loads it's registry cache, variables cache, current user record (split across at least four tables to pull in the user account, associated roles, and user access permissions), any dynamic menu builds are going to the menu table, access callbacks and other function calls associated with dynamic menu rendering may also trigger other database calls, uncached content blocks have to be pulled out of the database, and we haven't even gotten to loading the node for the page which could be split across a bunch of tables if the content type has fields added to it...