Hacker News Reader

Comment by juliangregorian | Hacker News Reader

I did some server engineering for a large media property based on WordPress. The New Relic graph normally indicated > 80% of request turnaround was spent in PHP. An average request (there was a frontend caching layer in place) that hit the app would normally take ~700ms, of which ~550 would be spent in WordPress. I attributed it mostly to WordPress being WordPress though. A lean PHP API can turn a typical request around on similar machinery in 1/10 the time.

That doesn't discount that the database is ridiculously ugly, though.

View on HN

"I attributed it mostly to WordPress being WordPress though."

One of the unfortunate issues with Wordpress is their continued support for outdated PHP versions. Wordpress is compatible with as far back as PHP 5.2.4, which was released back in 2007. There have been many performance improvements to PHP since the early versions of 5.x. The fact that Wordpress is eating up so much CPU on trivial CRUD logic is probably attributed to the sheer amount of technical debt/cruft in the code base, but also compounded by the need (insistence?) to support legacy systems, thus not being able to take advantage of newer features of PHP.

The conservative choice of PHP 5.2 as the minimum requirement for WordPress doesn't stop performance sensitive sites using later versions of PHP, or HHVM, or Phalanger, or whatever floats their boat.

Indeed, only 30% of WordPress installs use PHP 5.2.

Runtime features are not a problem for WordPress users.

If you think the minimum requirement is limiting potential for optimisation, what are some relevant language and library features in subsequent versions that the WordPress team can’t use?

In that example, I bet WordPress on its own would have spent less than 550ms without having to replenish your cache layer. Also how much of that time was actually PHP vs. PHP waiting for MySQL? I bet if you scattered microtimers throughout WordPress, you would see 99% of your 550ms would be waiting for the disk and MySQL.

No, actually MySQL was the remainder (~150ms).

WordPress wasn't updating the cache; I mention that because 700ms is painfully slow, once all the JS and ads run load time can cross 2 full seconds. The cache becomes the only acceptable way to run it in production.

New Relic actually provides a breakdown of how much time was spent in each function; while I don't remember offhand what that was, there wasn't any low-hanging fruit that could be optimized.

Reply on news.ycombinator.com