[emergentcypher]

Drupal has always performed like shit. 10/sec is actually pretty good for Drupal It's only good for managing static content, the only way you get any sort of performance out of it is super aggressive caching.

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.

[onli]

It gets pointed out below, but I think that is really important.

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

[yxlx]

I think the way to read that paragraph is as two separate statements.

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

[thrownear]

> PHP is not at fault.

Well, it is the fault of Php's shared nothing model that throws everything away after each request...

[debacle]

That's not how modern PHP works.

[vamur]

>>PHP is a slow abomination.

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.

[ohthehugemanate]

You're thinking of Drupal 6. Or maybe 7. Drupal 8 (if you use a released version) gets thousands of requests per second. To be fair, that's because it aggressively caches page components and uses cache tags like a demon. But that's the ootb configuration, no special tools required.

[debacle]

> PHP is a slow abomination.

Compared to?

[emergentcypher]

Anything else.

[debacle]

Like? PHP is faster than both Ruby and Python. Only scripting languages that are currently faster are Lua and Perl.