PHP is a slow abomination. The entirety of Drupal and all modules have to be bootstrapped and run on every request. It runs far too many SQL queries and those queries look atrocious (nested selects, tons of joins, etc).
Same with Magento Commerce. I was always shocked at just how slow it is.
> PHP is a slow abomination. The entirety of Drupal and all modules have to be bootstrapped and run on every request. It runs far too many SQL queries and those queries look atrocious (nested selects, tons of joins, etc).
Those statement don't go together. If it is drupal that is doing too many requests, that is not the fault of PHP.
I'm working partly on an PHP open source blog engine and we are getting way better results. Though caching also helps there, as soon as the SQL statements are properly cached performance increases a lot. That will be true for Drupal, but it most likely will be true for any other CMS that has an equvalent workload on every request. And that those caches help actually show that PHP is not at fault.
>PHP is a slow abomination. The entirety of Drupal and all modules have to be bootstrapped and run on every request.
and
>It runs far too many SQL queries and those queries look atrocious (nested selects, tons of joins, etc).
So the first part is about slowness due to how PHP is usually run. The second part is about slowness due to the implementation of Drupal.
When I say "how PHP is usually run", I mean that strictly speaking one could probably write PHP in a way such that there is one part which comprises all the things that take most of the time to load and have this run standalone. However, I think going to such extents might be more work to do in PHP compared to picking another language. Then again, I haven't written PHP for several years and even when I did I never did any advanced stuff so for all I know what I'm saying here might be something PHP professionals have already thought of.
Well, it is the fault of Php's shared nothing model that throws everything away after each request...
In my benchmarks, for accessing databases, string concatenation and output, PHP is faster than Nodejs, Go and Python and is on par with Luajit. So no.
And it's not PHP's fault that Drupal and Magento developers don't care about performance and think caching is a solution to all performance problems.
>>The entirety of Drupal and all modules have to be bootstrapped and run on every request. It runs far too many SQL queries and those queries look atrocious (nested selects, tons of joins, etc).
Agree with the above. However, PHP has reactphp which Drupal could have used.
Compared to?
The static assets will be served directly by the webserver, without invoking Drupal, without any of that overhead.
- Drupal has to bootstrap itself and all modules on every request.
- Drupal makes waaaaay too many SQL queries
- Drupal generates horribly performing SQL queries
Drupal, on the other hand, is so slow because it has a terrible architecture.
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)!?
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.
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.
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.
where can I read more about this? I enjoy good programming drama
"I don't believe CMF is as stable as Symfony core" this is at best FUD, Symfony CMF won't see a stable release for another ten months http://symfony.com/blog/the-symfony-cmf-released-its-first-s... Symfony 2 core had several stable releases http://symfony.com/blog/symfony-2-1-3-released by this point.
I have no idea how the core committers didn't catch all this -- but you can't really blame them, there was a gigantic pressure to move ahead. And then based on this foundation, everything link related, inbound and outbound was converted to route names instead of paths which is a) absolutely unnecessary b) destroys performance.
Of course, there was history and reason trying to avoid review of this pile of code. Symfony, in general, is an extremely poor fit for Drupal: Drupal was a convention based system and Symfony is very heavily a config based system. The most obvious and very glarring misfit is hooks vs events and despite hooks being the central Drupal building block there never was a fundamental, through research as to what if anything to replace them with. Compare the scrutiny Symfony Foundation received in https://groups.drupal.org/node/167299 to how Symfony HTTP Kernel got added: via an admittedly "off-the-cuff" prototype https://groups.drupal.org/node/198538 . Note that I was trying to push back on this immediately with little success then or ever. So after shoehorning HTTP Kernel in over some bitterness and fighting it stands to reason the architect wants to avoid any scrutiny this pile of code would receive.
Ps. Events have so much overhead that by now Drupal only uses the interface for them as we rewrote the dispatcher to scale. Benchmarks at https://www.drupal.org/node/1972300#comment-9216069 .
I used D5/D6/D7 for a low-traffic site these years.
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).
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.)
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.
Agreed.
I had a static site running on Drupal 7 on Azure and it was really slow. I did a ton of optimizing the front-end code and caching everything I could and it still took between 3-5 seconds to serve pages.
Once I switched to a static site generator, I was floored at how much faster the pages loaded and the performance was night and day; and I was still hosting it on Azure. The only variable that had changed was Drupal.
I've built some substantial D7 sites and have completely uncached page response times in the median of 100-300ms. Slow, sure, but anything over 1s and I figure out what's causing such abysmal performance.
With PHP 7 on a standard D7 site, those times are down sub-200ms.
And these are sites with over 100 contrib modules, usually 20-30 extra custom modules, and at least a million+ (Mostly anonymous, so those are cached) page views per day.
I'll be the last person to defend Drupal, but I don't think it's fair to say that Drupal was the only variable that changed. What about the amount of stuff coming off disk each time, the removal of an interpreted language, the database access?
I'm not impressed by Drupal's preformance even on a low-traffic site, but then again I could not find a "better" CMS yet.