Even so, that strikes me as very low. I've always wondered where the bottlenecks are in Drupal (I haven't looked at it in many years). Getting that kind of throughput even on paltry hardware would give me pause about doing this in production.
- 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.