4 ms·

It is, absolutely. And Wordpress is notoriously liberal with its queries and use of storage in relational database (unless something monumental has changed in

by nkozyra 12y ago

It is, absolutely. And Wordpress is notoriously liberal with its queries and use of storage in relational database (unless something monumental has changed in the last year). There's a reason there are 8 million caching plugins. If PHP is the slowest part of your application, you're probably in good shape. If your Wordpress application is slow, replacing PHP with Hack is like putting a souped up engine in a car with no gas in the tank. PHP scaled poorly at Facebook not because it was PHP, but because it was Facebook. They would have run into the same (or worse) performance issues with most dynamically-typed languages.

ircmaxell 12y ago
> If PHP is the slowest part of your application, you're probably in good shape. Or doing something epicly wrong. One of the two...
chc 12y ago
Anecdotally, I got a pretty noticeable speedup on an experimental WordPress-on-HHVM setup even on a page that was running dozens of database queries. (I didn't end up taking it live because HHVM did not render the page entirely correctly, but the speedup was still pretty nice.)
- cheald 12y ago
  I presume this is the case, but were you comparing against PHP with APC or similar in place?
  - chc 12y ago
    Yep. I double-checked that I hadn't borked the PHP install because I was surprised at the result. I'm not sure what it was doing to make the big difference since the inconsistencies with real PHP behavior were enough to write it off as a drop-in replacement, so I didn't continue experimenting much more, but it seemed promising.
deanotron 12y ago
HHVM was needed at Facebook because it's a dynamic app with rapidly changing content. WordPress sites are typically static content that are perfectly fit for static caching with a CDN - it really shouldn't matter how many milliseconds you are able to save on the server if your site is only being hit once every two hours from the CDN. The 8 million caching plugins are unnecessary when you can just sign up for cloudflare.
- jdub 12y ago
  How many big WordPress sites do you reckon can say, "Fuck it, it's all static anyway"? I mean, your blog, sure, but the New York Times? (Who are, interestingly enough, putting a non-PHP-based high performance dynamic front-end in front of WordPress using... WP-API.)
- nkozyra 12y ago
  Cloudflare is - in this example - just one of the 8 million (albeit as a CDN, a far wiser choice). Ultimately that sacrifice comes down to real-time dynamic site versus having some content be static or conditionally dynamic. None of that is a symptom of PHP as the backend (unless you have a LOT of traffic).
- pjbrunet 12y ago
  8 million caching plugins is a total exaggeration. As far as I can tell there's only two options: WP Super Cache (which seems to have been abandoned by the author) and W3 Total Cache which is a spammy mess of nag screens to join New Relic and MaxCDN. (No wonder it was banned by WP-Engine.) If I wasn't busy on other projects, I would take on W3 Total Cache--it's the worst UI I have ever seen and it doesn't even work. I had to mostly disable it today because my CPU went from 100% to 600% after installing it.
  - juliangregorian 12y ago
    Seeing a lot more than two: https://wordpress.org/plugins/tags/cache https://wordpress.org/plugins/tags/cache
  - gibrown 12y ago

by nkozyra 12y ago

ircmaxell 12y ago

> If PHP is the slowest part of your application, you're probably in good shape. Or doing something epicly wrong. One of the two...

chc 12y ago

Anecdotally, I got a pretty noticeable speedup on an experimental WordPress-on-HHVM setup even on a page that was running dozens of database queries. (I didn't end up taking it live because HHVM did not render the page entirely correctly, but the speedup was still pretty nice.)

cheald 12y ago
I presume this is the case, but were you comparing against PHP with APC or similar in place?
- chc 12y ago
  Yep. I double-checked that I hadn't borked the PHP install because I was surprised at the result. I'm not sure what it was doing to make the big difference since the inconsistencies with real PHP behavior were enough to write it off as a drop-in replacement, so I didn't continue experimenting much more, but it seemed promising.

deanotron 12y ago

HHVM was needed at Facebook because it's a dynamic app with rapidly changing content. WordPress sites are typically static content that are perfectly fit for static caching with a CDN - it really shouldn't matter how many milliseconds you are able to save on the server if your site is only being hit once every two hours from the CDN. The 8 million caching plugins are unnecessary when you can just sign up for cloudflare.

jdub 12y ago
How many big WordPress sites do you reckon can say, "Fuck it, it's all static anyway"? I mean, your blog, sure, but the New York Times? (Who are, interestingly enough, putting a non-PHP-based high performance dynamic front-end in front of WordPress using... WP-API.)
nkozyra 12y ago
Cloudflare is - in this example - just one of the 8 million (albeit as a CDN, a far wiser choice). Ultimately that sacrifice comes down to real-time dynamic site versus having some content be static or conditionally dynamic. None of that is a symptom of PHP as the backend (unless you have a LOT of traffic).
pjbrunet 12y ago
8 million caching plugins is a total exaggeration. As far as I can tell there's only two options: WP Super Cache (which seems to have been abandoned by the author) and W3 Total Cache which is a spammy mess of nag screens to join New Relic and MaxCDN. (No wonder it was banned by WP-Engine.) If I wasn't busy on other projects, I would take on W3 Total Cache--it's the worst UI I have ever seen and it doesn't even work. I had to mostly disable it today because my CPU went from 100% to 600% after installing it.
- juliangregorian 12y ago
  Seeing a lot more than two: https://wordpress.org/plugins/tags/cache https://wordpress.org/plugins/tags/cache
- gibrown 12y ago