[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.

[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...