Another new era of WordPress
bethesignal.org
bethesignal.org
Is the database not the bottleneck? Especially with the way wordpress stores "post meta data" with key and value columns it seems that the joins could get a bit ugly.
Most of the large, healthy PHP-based sites I’ve worked on spend 5-20% of their average request time in the database. Which means PHP is chewing 80-95%. Which makes PHP the slow bit.
Not because PHP is bad: That’s a pretty reasonable figure for platforms based on Ruby, Python, PHP, etc. (Less so for Java and .NET.)
It's a really good rule of thumb: If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed.
You’ve probably hit a database scalability limit, or tried to get the database to do something silly. (And hey, that’s easy to do with MySQL, which is fast primarily because it’s dumb.)
(By the way: WordPress, out of the box, doesn't spend much time in the database at all.)
Very rarely was the issue with the databases. I've had people not want to normalize data and create some generally disgusting tables and code because "joins bad"... On tables that will only ever have a few 10k records. If you have the proper indexes and queries in place, your database is just traversing btree's in memory and it will be blazing fast.
For most webapps, I/O typically should be the bottleneck. This holds especially true for wordpress, which has nothing computationally heavy to do, and is...rather liberal with the way it queries the database. Certainly the large installations I've managed spent most time doing I/O (either in the database or memcached.)
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.
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.
(Who are, interestingly enough, putting a non-PHP-based high performance dynamic front-end in front of WordPress using... WP-API.)
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).
Or doing something epicly wrong. One of the two...
(I didn't end up taking it live because HHVM did not render the page entirely correctly, but the speedup was still pretty nice.)
That doesn't discount that the database is ridiculously ugly, 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.
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?
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.
Even a small site with a low level of traffic can bring a modest DB server to it's knees without caching of some type. It's really ridiculous but just due to the modular nature of WordPress.
It shouldn't be. If it is, it's because you missed a cache result. Even for highly dynamic sites, the DB should never be the slowest part of your app because you rarely hit it.
I don't mind PHP though :)
Things like upgrading the core software...with WordPress it's so easy that it doesn't even take thought; hell, they've made upgrades automatic by default a few days ago. With Drupal, I'm months into a migration process to get our site onto Drupal 7 (not even kidding). It's been more complicated, and more error-prone, than the process of migrating from OpenACS to Joomla and then from Joomla into Drupal 6.
WordPress also seems to have the ecosystem right. No matter what kind of task you're trying to solve, there are a dozen plugins for it, some free, some commercial, some a hybrid of the two (sometimes annoyingly spammy about it). I've whipped up several websites in the past few weeks for various side projects I have, and it's downright fun to build complicated sites with WordPress. And, because there are more themes than there are people using WordPress (exaggeration to make a point), getting a site looking good and not like every other WordPress site is trivial and cheap. I find myself wanting to make new websites because it's more fun than working on my company website running Drupal. When it comes to building custom code, I prefer Drupal (mostly), but I do that pretty rarely; I interact with the frontend and admin interface daily.
I've almost talked myself into migrating my company site to WordPress+bbPress. I wonder if there's a really good ticket tracker option for WordPress...
This is a double-edged sword that can get you into trouble quickly. Personally, I prefer systems that focus on one thing and one thing only.
Seriously, if the API is stable, why not just build something that matches it using a faster, cleaner language? The user gets the speed benefits, the developers get to start again from a clean(er) slate. The only hole in this idea is the shortage of cheap hosting which offers something other than PHP for dynamic websites.
I doubt very much that the WP team has any intention of moving away from PHP anytime soon (if ever). Yes, they could start again on a clean slate of code, but they'd also have to start again on a clean slate of the community. But the community is worth way more than the code.
WP-API is important so that Wordpress can continue to grow into more complex projects. Javascript front-ends are getting more popular, and if WP cannot feed data to them in a flexible and performant way, it will lose out to other content frameworks that can (for example, Drupal), or custom development of content stores.
You've misunderstood me. I didn't envision this move would be made by the WP team. Anyone with the prerequisite skills to build server software could do it. A new open-source project, a WP-compatible drop in replacement. Even just for environmental reasons it'd be worth it, imagine what a difference it would make if a significant portion of the world's websites switched to a more efficient solution.
I hear a lot of these comments from very well respected developers, but as a user and webmaster (not a developer) of WordPress I am very satisfied with it, and rarely see a WordPress site that runs slow, with the exceptions of poorly coded themes which will slow down ANY CMS.
I manage a lot of websites, probably 200 or so of them are WordPress. Over the last 5 years I've seen about 5 hacks, 3 were due to outdated plugins and 2 were brute forced. Backups are incredibly easy (file structure and database) for an end user with plugins, and maintenance for an average WordPress takes about 20 minutes per month.
I think this discussion is very positive in the fact that the core of WordPress is very outdated and has not really been touched in the last 5 years (or more?) or so. I'd love to see version 5 or 6 be a full re-write or even a partial rewrite of the main functions and core includes, perhaps even a more efficient language but that is not really my territory. The problem I see with all that is backwards compatibility. There are so many themes, plugins, and addons that depend on WordPress core hooks, I don't know how that could work seamlessly. I suppose that is what beta testing is for.
As I've already said in this thread, WordPress is a huge success in the mainstream and is gaining in popularity every day. 75 million WP sites last I checked vs a fraction of that in Drupal and Joomla.
Node is on the rise but is still a custom solution and not deployable unless you are a skilled developer with knowledge of the network stack.
We live in an age where end users want to be able to control their website backend. They want to blog, make changes to static pages, add images from events and even add their own products. Have you ever tried to teach someone to do this in Joomla and Drupal? I have, with success but it is 100x more difficult than WordPress.
Wordpress is failing on mobile.
Most of the themes are poorly optimized for mobile. For example open http://wordpress.org/news on your phone - there's so much mobile fail happening here, from the hamburger menu and the poor use of space at the top to tiny fonts and navigation elements. Over at blog.wordpress.com there's other fail going on, like the performance of opening the menu top left. Both of these reflect the general state of Wordpress themes from my experience.
Meanwhile, aside from some app-based editing tools, Wordpress has completely failed to bring blog content to apps.
The #1 use case here is for app developers who won't content from their blog to be available somewhere in their app.
And actually it's not just Wordpress failing here. There's such a gap in the market that mobile marketing platforms like AppBoy are filling the gap with product features e.g. http://www.adweek.com/socialtimes/appboy-reveals-in-app-news...
I don't know much about WP, so I'm really curious, is it WP that is failing on mobile, or is it the poorly designed themes?
The consequence is a generation of Mobile developers are ignoring Wordpress, at least in their apps. Wordpress needs to have a drop-in SDK that allows content from an app developers blog to be displayed in a friendly way in-app, plus push notifications / badges etc. to inform users of new content. How do you tell users about new features in your app for example?
Then there are some deeper questions to answer like blog comments - do they make sense on mobile at all? Most people aren't going to write more than a sentence on their phone. What about finding different ways to provide feedback? Yelp for example spend a long time soul-searching about whether to allow reviews from mobile - http://officialblog.yelp.com/2013/08/oh-snap-yelp-app-now-po... - I don't think they found the answer but they certainly saw the problem. But that's another story...
I do admit that there are probably way more bad themes out there than good, and that most WP 'developers' do not stick to the codex / standards and just want to make money on themes.
I'm sure the vast majority of WP sites have been built for a paying client.
I would love to see a user-friendly universal app for managing static sites (Jeckyl, Docpad) that is something someone of my Mom's tech capability could use. (and let's be honest, WP itself is sometimes "way too much")
They want a friendly easy way to manage a complex case management system, but they don't understand how some of interconnected relationships work between the data they want. So trying to cross that chasm, of explaining what they actually want implies for the data has been miserable. Somethings just aren't simple :(
Using either of the above, you'd reduce the latency and increase the through-put of WP to the likes of hosting a simple HTML page on nginx.
The picture gets a bit more complicated with the back-end admin area, user logins, sessions, dynamic page parts, etc. And there are ways to either handle it or just bypass the caching layer for it, but for handling reader traffic, caching is the key regardless of which CMS you use.
Also, the more visits, the less of a need for a dynamic CMS.
Wordpress is the triumph of style and marketing over all other considerations. Having managed a small fleet of Wordpress sites for over a decade, I am not a fan.
And I am not very optimistic about Grand Visions In Blog Posts. I've had a few of those myself.
However, I can't wrap my mind around like React.js. Having a mental roadblock on even diving it to do prototypes with it to give it a whirl (which I often do with new libraries or languages even).
(god I'm such a nerd)
I'm biased but this is best quote I've heard in quite a while.
WP causes endless security problems for hosting companies. Even when it's locked down it's (often) still wide open, and most users don't know how to lock it down.
But it's never going to die, because ecosystem. Static alternatives are never going to take over, because they don't have gargantuan theme factories supporting them. And most users like pretty.
So I guess we're stuck with it for a while yet.
The vanilla WP environment means goodies like React (which requires V8 to compile on the server) and HHVM are not in the cards. But PHP and WordPress really doesn't need to be fast (just put it behind a CDN).
Isomorphic rendering over the WP-API is all you need - I've had a lot of benefit using logic-less templates like Handlebars on the client and the server.
"PHP and WordPress really [don't] need to be fast"... until you're doing anything dynamic at all, and then they do. :-)
This seems to me like a bit of an exaggeration (or maybe just facetious).
But all of the benefits of the React Virtual DOM don't really come into play if the content is static (like most WordPress sites). If no data is changing, you don't need observables to automatically update views, and the built in underscore.js templating will do a fine job.
If there is something that slows down WordPress it's the database queries, the amount of external assets and bloated themes. There are more then files being downloaded for each requests and all served from the same server.
Throw in hhvm or any optimization on the code and you still have to deal with the other issues.
The database is not where raw performance opportunities lie on a sensibly built WordPress site.
http://wptavern.com/heroku-wp-a-template-for-installing-and-...
My only wish is that a proliferation of horrible themes based on inefficient JS does not occur. Front-end MVC can be done right, but don't abuse it with bad code that gives the rest a bad name!
EDIT: So it turns out there's a third party project that kinda sorta does this: WP-CLI (http://wp-cli.org/). Anyone used it?
Ruby need something similar to HHVM, progress on the RuJIT sponsored by Ruby Association looks like stalled. IronRuby ( or something similar ) on the new Microsoft CoreCLR will take years.
And Rails Core team, or DHH seems to be against the Rails API ideas.
There is nothing great about this sort of thing:
<?php for($i=0; $i<$num_rows; $i++) { ?>
<div><?php echo htmlspecialchars($db_row[$i]['field']); ?></div>
<?php } ?>
And then somebody decides to drop php variables directly into javascript and css...
No. No no no.
<?php foreach($row in $results) { ?>
<div><?=h($row->field)?></div>
<?php } ?>
I would have added it in real code... but manually escaping everything is still what you have to do with raw php. At the very least, have something to recursively escape an array (keys and values) before it gets dumped onto the page.
Twig at least lets you escape by default (and you don't have to worry about double-escaping), but the equivalent wouldn't be much less verbose. Twig's syntax is a bit cleaner in couple of places I think, and it lets you use array bracket syntax [] in versions of PHP too old to support it natively.
{% for row in results %}
<div>{{ row.field }}</div>
{% endfor %}
<? foreach($row in $results): ?>
<div><?= $row['field'] ?></div>
<? endforeach ?>
A lot of self-described minimalist templating languages do wind up looking a lot like that. I personally don't want to see raw PHP in anything i'm calling a template but to each their own.
I completely disagree. PHP is rarely the issue and I don't know where people get this idea that PHP is slow. Unless you're calculating the flight trajectory to Mars, the main bottleneck of WordPress is MySQL. Fill up you PHP application with microtimers, you'll see PHP only needs milliseconds to do its job even without caching. If there's anything slowing you down, you're waiting for MySQL or Curl or some external application, which is unnecessary most of the time if you designed the application properly.
(When more time is spent elsewhere, you have a problem that needs to be fixed. For example, waiting for I/O because you've done something silly with a database query or you've pushed it beyond its scaling limits and everyone's waiting for I/O.)
http://pjbrunet.com/microtimers-on-hooks-to-measure-wordpres...
Good for you.
Putting microtimers throughout your code is like using printf for "debugging": It's banging rocks together. Use xdebug, xhprof, New Relic, something sensible. You'll learn much more about your stack.
You can use something like Ambidex to render HTML from your React components on the web server, backed by your WP-API.
------
More info (in video form): https://www.youtube.com/watch?v=yaymfLj5tjA
Ambidex (one of many ways you could implement this paradigm): https://github.com/appsforartists/ambidex
Who's next up on the soapbox?
The reason WP did - and does - so well is that for most hosts, it's very easy to deploy, does what most sites need, and is reasonably easy to teach. It's also trivially extensible, within it's somewhat limited framework.
So any other PHP application (various shopping carts, etc) can be easily put on top of a normal WP site, and with a little glue, made to be a plugin that "just works" (most of the time. And occasionally makes the whole site return a completely empty page and no errors...).
However, there is going to be a general decline in PHP being easier to deploy than other server site languages, an interesting proposition might be to make a language agnostic WP 'database core'.
Currently, it's all a bit of a mess underneath - lots of the system still thinks it's a pure blogging engine, lots of the internal functions are aimed at that, etc.
But the core idea of the data model is
[post] >- [categories] and [metadata] which can be attached to those somewhat ad hoc. Posts can be different 'types', dependant on the current theme (yeah - WP is kind of messed up).
But the idea of all your content pieces are roughly equivalent, so a blog post is basically the same thing as a static page, is basically the same thing as a custom-post-type-video, cat picture, etc, is reasonably powerful.
If the core of the database concepts were codified and 'locked down', and the PHP back end simplified down to being a RESTful interface on top of it (JSON for the back end, pretty HTML for the front end) + a few oddments, then that could be ported to any number of different languages quite easily.
This way mysql could be factored out, if desired, or PHP, and a lot of the concepts would still keep on working.
The trouble is you lose the WP 'it's PHP, so a custom theme can do ANYTHING!!!!! magic'. Which might be good for security, but bad for popularity.
If the core were codified enough, then many plugins and theme control stuff could simply become front-end javascript plus templating files, which would be good though. (And back-end agnostic).
But it's kind of interesting, for all PHP's warts, it has made it so easy to build things, allowing a huge amount of plugins and themes to develop. For all these years, devs didn't need to worry about the latest library, from backbone to angular, from react to mithril etc. It's the stability and ease of access that has been so important to growth.
Now that the web is so javascript oriented it's really compelling to just think about how WP can adapt to it. But a big push toward adopting new methodologies just strips away the number one reason to develop with WordPress: the huge ecosystem that has solutions coded with PHP. And if you are going to create that rift, you might as well start with some other platform.
But it's really hard to pick a winner now, React for example, could easily be overtaken by another lib in a years time. We're unsure how Nodejs is going to develop. The json API's current state is not superfast or fully developed yet.
I sometimes wonder that we're underestimating the advantages of having something stable like PHP continuing to run at least part of the show. For example, I have yet to see any kind of theme (A WP theme or otherwise) coded with some kind of front-end oriented mvc setup that results in a qualitatively superior site experience.