WordPress Announces Migration to Node.js

Matt Mullenweg, the CEO of Automattic, the parent corporation of WordPress, generated a lot of excitement when he announced recently that WordPress.com was beginning to migrate away from PHP to JavaScript and Node.js in particular. Why would the No. 1 content management system in the world make such a major change? Could this negatively affect the more than 74 million WordPress websites on the Internet?

What Is Node.js?

Node.js is a single threaded, non-blocking, open-source JavaScript runtime environment. It is also one of the fastest-growing projects on the Internet, and it was originally created in 2009 by Ryan Dahl and a team of developers at Joyent. It is powered by Google Chrome’s V8 JavaScript runtime and uses a non-blocking, event-driven I/O that lets you rapidly create fast, efficient and scalable applications.

Node.js is particularly well-suited for real-time applications that are data intensive. It also plays well across distributed devices. With Node.js, you can create applications for the server and JavaScript, much like you would in other programming languages like Python. JavaScript is ideal for this environment because it is already well-known to client-side developers, and it handles I/O applications with aplomb. Currently, JavaScript is primarily used as a lightweight language interpreted by browsers once a Web page loads.

Why Go From PHP to Node.js?

If PHP has been rock solid for so many years, what specific things does Node.js do for WordPress that prompted the change? Specifically, it offers these advantages:

  • Node.js is fast because it is asynchronous and non-blocking. Synchronous systems that use blocking are slower because each request must be served in turn.
  • Node.js was built around modern computing architectures. It is not hampered by decades-old legacy code.
  • JavaScript is a modern language that can be molded and extended in a myriad of ways.
  • Node.js “speaks” JSON, allowing developers to use a single syntax from the web browser through the server to the database.
  • Node.js makes event loops available on the server. You can quickly write applications to do things like connecting databases to powerful Web APIs.

Node fits the needs of a fast-changing Internet that is increasingly mobile. The Web is becoming ubiquitous, as we see it implemented in everything from appliances to clothing. Node.js is more suited to that environment than PHP.

Two Major Challenges

When Matt Mullenweg became CEO of Automattic in January of 2014, he realized the WordPress project had two major challenges:

  • Lack of capital
  • Limits of current technology

It was the second reason that led him and the Automattic team to consider new approaches. The current codebase has helped the platform grow rapidly–currently, 25 percent of websites on the Internet are powered by WordPress. It is powerful, flexible and cheap to run.

Backward Compatibility

However, one of the downsides has been the area of administration. Mullenweg felt the strengths of WordPress were also creating weaknesses for wp-admin–the administration section of WordPress–and they needed a new plan for the future.

One of the main challenges was that they needed to step away from backward compatibility to get a fresh start, yet one of the platform’s strengths has always been that it was compatible with every release. In contrast, some other popular content management systems like Drupal routinely broke backward compatibility to be able to use the latest technology bells and whistles. It didn’t always make users happy, but it kept the platform on the cutting edge.

Worldwide Contributors

More than 120 contributors combined efforts over many months to meet this challenge, and the result is Calypso. Project Calypso was in-house effort at Automattic to rethink the WordPress codebase and see where it could be improved. Adding Node.js was a natural fit, yet few of the team members in the organization were strong JavaScript coders. However, through trial and error, they began to succeed, and the original handful of developers grew to 127 with more than 26,000 commits.

100 Percent Open Source

Calypso is 100 percent open source, written using libraries from Node.js and React.js. React.js, originally created by developers at Facebook to build user interfaces that worked across many platforms, is used for the user-facing front end.

Node.js is used to make the back end. It is entirely driven by open APIs available to everyone. A single-page application (SPA) runs in the client, taking advantage of multiple JavaScript modules.

REST APIs

Calypso is entirely driven by open representational state transfer (REST) APIs that are available to everyone. The open API means you can manage any of your sites through Calypso. It is blazing fast with pages that load almost instantly, and you can now employ social features like statistics and notifications.

Multi-Site Management

One of WordPress’ strengths is the ability to run multiple sites off the same database. However, managing many blogs can be daunting. Calypso lets you manage many WordPress sites from one administration screen off of any desktop computer, smartphone or mobile device.

Currently, Calypso is deployed on WordPress.com, the site that hosts many free WordPress blogs. Just how big is WordPress.com? Consider these numbers. In 2014:

  • More than 18 million new blogs were created–that’s about 50,000 per day
  • More than 550 million posts were published–that’s the equivalent of 1.5 million per day
  • 47 million posts were originated from mobile devices

Self-Hosted WordPress Sites

If you have a self-hosted WordPress site, you can still take advantage of Node.js developments through the Jetpack plugin. To make it work, you must have a WordPress.com account. Jetpack connects to WordPress.com, which allows you to:

  • Edit and administrate all of your blogs
  • Manage pages, posts, themes, menus, plugins and various settings
  • Write and edit posts very quickly

There is also an application available for Macintosh OS X, with other platforms like Windows to be released soon.

Uncharted Waters

Is WordPress moving into uncharted waters? Not entirely. There are blogging platforms that already use Node.js extensively. One example is Ghost, called by some enthusiastic backers the “WordPress killer,” when it was released in 2012. Ghost was originally built with Backbone, a lightweight JavaScript framework that uses Underscore.js as its single JavaScript library, and the Handlebars semantic templating engine. The developers then transitioned to the Ember.js platform for the client-side and Node.js for the server, while retaining SQL for databases.

First Step Forward

Calypso is the first step in what many see as a continuing move of WordPress.com from the safe harbors of PHP and MySQL. In effect, the site is becoming a client for the API, similar to any application that uses the API. That makes it speedier and lighter for the mobile computing environment that is taking over the world.

With Calypso and Node.js, end users can expect a better experience with WordPress–pages will load faster and respond snappier. Users that also function as webmasters on their own blogs will benefit from new tools for:

  • Multi-site management
  • Desktop blogging
  • Statistics and analytics
  • Website security
  • Site monitoring
  • Image delivery via CDN
  • Stunning Slideshows
  • Improvements in sharing capability

Although these features will allow a significant percentage of general users running self-hosted blogs to use Jetpack to replace much of their current plugins, power users will demand more power and the ability to tweak settings and configuration. For that reason, advanced users will more than likely stay with the majority of their plugins.

The Future of PHP and Node.js

The vast world of WordPress wondered if Calypso was a harbinger of things to come. Would all of WordPress eventually run on Node.js? According to Mullenweg, Calypso shows what is possible. In an interview with Venture Beat, he said he thinks the technology behind the server side and the client side will probably split. PHP is still dominant on the server side, but Calypso and JavaScript, much like Node.js, is the way of the future for the client side.

Does the implementation of Node.js mean the death knell of PHP? If so, it will take some time. PHP is a tough racehorse and has been carrying WordPress around the track for 13 years.

Eventual Takeover

Node.js may take over PHP eventually — it has made huge inroads:

  • After a successful Black Friday test, Walmart began moving their mobile traffic to Node.js.
  • Early on, Yahoo started to migrate to Node.js for their Web stack.
  • LinkedIn reported giant performance gains when they began implementing Node.js.

At this point, Calypso is an administration area with a dashboard. It’s really a combination of React.js with Node.js sitting on the server to generate the Web page. It then talks to the WordPress site through a REST API, and the site is still written in PHP.

However, the future of computing is mobile, and Node.js is a clear winner on distributed devices and the Internet of Things. The way forward isn’t entirely clear, but you can expect Node.js to be in the driver’s seat for a very long time.

Running a Node.js app? Make sure to check out my Node.js Cheat Sheet.

An Example of How Node.js is Faster Than PHP – Part 2

In my previous post I installed and configured Ghost (a node.js based blogging platform) and WordPress (a PHP based blogging platform and CMS). The purpose of that blog post was to test relative performance of the 2 platforms to see which one could handle more load. The test doesn’t compare like code between node.js and PHP, but instead was designed to understand what platform was faster from a basic blog functionality standpoint.

The result of the first set of tests was that Ghost was 678% faster than WordPress in their “out of the box” configurations. The test and results spurred a lot of interesting dialogue with many people requesting another test where an opcode cache was in place for WordPress. So that is exactly what this next blog post is about.

The Setup

I fired up the exact servers that I had used in my last round of testing so I have the same configuration as in my original blog post. For this set of tests I stuck with Apache as the web server for both Ghost and WordPress. I also added APC opcode cache by following the instructions in this blog post. It was pretty easy and painless getting APC installed and functional and it definitely made a nice difference in the performance of WordPress.

The Results

As before, I used Siege to apply load to the platforms. As a reminder of our WordPress baseline I ran a load test on Apache + WordPress first without the APC opcode cache. Those results are shown below.

Apache+Wordpress-NoCache-HeavyLoad

Apache+Wordpress under heavy load.

Wordpress-Heavy-Load-CPU

CPU utilization during Apache + WordPress load test.

This load test resulted in 100% CPU utilization just as we had seen in my last blog post. I load tested Apache + Ghost again so that we could compare the base configurations and those results are shown below.

Apache+Ghost-HeavyLoad

Apache + Ghost heavy load test results.

Ghost-Heavy-Load-CPU

CPU utilization during Apache + Ghost heavy load test.

As expected Ghost had a much higher transactional throughput ~654% more than WordPress. So now came the real fun. Configure PHP to use APC, restart Apache, and restart the load test. Those results are shown below.

Apache+Wordpress+APC-HeavyLoad

Apache + WordPress + APC heavy load test results.

Much better results for WordPress this time with ~159% improvement in throughput over WordPress without an opcode cache. Transaction response times were also much better showing with ~70% reduction in shortest response time and ~63 percent reduction in longest response time. That’s a nice performance gain for a small bit of work installing and configuring APC. I have included a couple of screenshots for those who are curious about key cache metrics (notice the high cache hit rate)…

APC Cache Info

APC Cache Hit Rate

While the improvement to WordPress was admirable the fact still remains that Ghost handled the load way better than WordPress. The results of this test show Ghost with a ~190% lead over WordPress when it comes to total throughput, ~51% faster for shortest response time, and ~80% faster for the longest response time.

It’s worth mentioning that the CPU load did not decrease while using the opcode cache during this test. Utilization stayed pegged at 100% for the duration of the test even though throughput and responsiveness improved.

What about lighter loading?

It’s also interesting to understand the difference in platform response time under light loading conditions. The following screen shots all show loads of 10 concurrent users in batches that are spaced 5 seconds apart. The combination of Apache and Ghost is just flat out fast and sets the bar for transaction response time with .01 seconds for the fastest transaction and .07 seconds for the slowest transaction.

Apache+Ghost-LightLoad

Apache + Ghost light load test results.

Apache and WordPress without any opcode cache (shown below) is respectably fast coming in at .20 seconds for the fastest transaction and .66 seconds for the slowest. That is 1900% and 842% worse than Ghost respectively. The percentages are high but the reality is that the page loads are still fast.

Apache+Wordpress-LightLoad

Apache + WordPress light load test results.

Adding the APC opcode cache to the Apache and WordPress combination clearly makes pages load faster even under light load. You can see below that the fastest transaction took .07 seconds and the slowest took .25 seconds. That’s a very nice improvement in speed. It’s still considerably slower than Ghost response times but at these speeds nobody will notice the difference.

Apache+Wordpress+APC-LightLoad

Apache + WordPress + APC light load test results.

Conclusion

One of the major difference between these two platforms is that Ghost was designed to be just a blogging platform so it is not bloated like WordPress is these days. I love the functionality that WordPress offers but as far as plain old blogging platforms go I think Ghost is going to be pretty tough to beat if you need a high throughput platform.

No matter what programming language is used on a project there will always be good code and bad code. By that I mean code that is efficient and effective (good) versus code that is resource heavy and potentially buggy (bad). If your application isn’t performing the way you want it or the way the business needs it to, then you should try installing AppDynamics for free and figure out what the problems are.

An example of how Node.js is faster than PHP

I wanted to see what all the Node.js hype was about so I decided to run some head to head load tests using Ghost (Node.js) and WordPress (php). The results were incredible with Ghost soundly trouncing WordPress. It was like watching a starship racing an airplane (well, what I imagine that would be like anyway).

There is a new blogging platform that was recently made available to the general public called Ghost. What’s interesting about Ghost is that it is built on the Node.js platform. If you’re not familiar with Node.js you should read my blog post about it here. If your not familiar with Ghost you can read about this kickstarter project here.

The Setup

To provide a little background, Ghost is just a blogging platform and nothing more while WordPress is a full up CMS. I wanted to make this comparison as fair as possible so I limited my load testing scripts to executing against only the blog pages. I also wanted to test the “out of the box” experience so I did not make configuration changes to either platform (besides hooking them both up to MySQL). I spun up a single 64-bit RHEL m1.large (reference server sizing image below for specs) instance on Amazon EC2 to host both blogging platforms.

Amazon Server Sizes

I wanted to test the most common configurations so I used NginX to front end Ghost and used Apache to front end WordPress. Both platforms shared the same local MySQL backend database instance (Ghost comes with SQLite by default but I wanted to make sure I provided a level playing field on the back end).

I had both Ghost (listening on port 80) and WordPress (listening on port 8080) running at the same time but only applied load to one blogging platform at any given time.

That brings me to the load generation portion of this little experiment. I spun up another EC2 instance (64-bit ubuntu, size m1.medium – reference server sizing image above for specs) in the same availability zone in an attempt to minimize network impact on test results. I asked my colleague @dustinwhittle to recommend a load test configuration and he referred me to his blog post about load test tools and recommended I used a combination of Siege and Sproxy.

After I had the blogging platforms installed and tested as working I added an 8 part blog series in plain text (no images) to each site and removed any pre-existing blogs. In WordPress I left the standard URL pattern in place and did NOT implement permalinks so that I would not slow things down by using that feature. I also did not turn on any caching technology for WordPress as I was trying to measure the out of the box experience. Basically I didn’t attempt any sort of tuning at all on either platform.

The other major configuration to note was that I used the AppDynamics machine agent to collect and chart OS metrics during these load tests.

The Tests

In order to use Siege to test many concurrent connections against many URLs I had to create a list of the URLs in a text file. For this I used Sproxy. Reference slides 20-23 of the following presentation for the details on using Sproxy https://speakerdeck.com/dustinwhittle/agile-performance-testing-checklist

I ran Sproxy against both Ghost and WordPress and ended up with my list of URLs. I modified each of these files to include the exact same list of blog posts so that the load tests would be as similar as possible. You can see the contents of each file below.

Ghost Load Test URLS

Wordpress Load Test URLS

So now I was ready to fire up Siege and start hitting each blog with load. Siege is a nice tool that allows you to manipulate some key parameters. The ones I played with the most were the number of concurrent connections (-c) and the delay (-d in seconds) between batches of requests. Here is the command for your reference… siege -v -c 100 -i -t 10M -f urls.txt -d 1

The Results

In a word, staggering! I ran siege for 10 minutes with 100 concurrent connections and a 1 second delay between batches of web requests. The results are shown below…

Ghost Performance Under Heavy Load

Siege load test results for Ghost with Nginx under heavy load.

Wordpress Siege Results

Siege load test results for WordPress and Apache under heavy load.

As you can see from the output shown above, Ghost with Nginx outperformed WordPress with Apache by about 678% when looking at total transactional throughput over a 10 minute test. Impressively, the longest transaction response time for Ghost was 2.62 seconds compared the an abysmal 33.41 seconds for WordPress. I repeated these test runs multiple times and got very similar results so I am not going to show the rest of the test results since they are redundant. My goal here was not to run an exhaustive analysis of performance at varying loads but instead to create a substantial load and to see how each platform handled it.

Some other interesting data points to note. During the load test, Ghost ran with only 1 process and Nginx had a total of 2 processes. WordPress and Apache on the other hand spawned a total of ~110 httpd processes which makes sense since Siege was throwing 100 concurrent connections at it. The interesting part is in the CPU data during the load tests. I have plotted Average, Min, and Max CPU utilization on the charts below. You can clearly see that Ghost CPU consumption was about 40% while WordPress consumption was about 70%.

Ghost Heavy Load - AppDynamics

CPU consumption during Ghost load test showing Average, Min, and Max values.

Wordpress Heavy Load - AppDynamics

CPU consumption during WordPress load test showing Average, Min, and Max values.

Now don’t think that I have forgot about normal loading patterns. How do things look with a moderate load as compared to the super high load that I placed on these platforms with the 100 concurrent connections test? To find out I dropped the number of concurrent connections to 10 and set the delay between batches of connections to 5 seconds. The results are shown below and are still incredibly impressive for Ghost. WordPress was outperformed in every way possible. Ghost had higher throughput and most importantly the slowest transaction response time was .18 seconds compared to 2.72 seconds for WordPress. From a CPU perspective Ghost only consumed ~4% on average during this test while WordPress consumed ~30% on average.

Siege load test results for Ghost with Nginx under light load.

Siege load test results for Ghost with Nginx under light load.

Siege load test results for WordPress with Apache under light load.

Siege load test results for WordPress with Apache under light load.

Update on 10/18/2013 – It’s not fair!!! Apples and Oranges!!!

There have been some who say I’m comparing apples to oranges. To this I say, you’re damn right! In this post I set out to compare the common combinations of Nginx + Ghost and Apache + WordPress. I set out to compare these in their most basic forms, no tuning, no caching, just what you get out of the box. But I understand the outcry and I decided to level the playing field. Some people thought that Apache was a bottleneck so I decided to use Apache as the front end web server for Ghost and to re-run my load tests. I ran multiple tests again but they were all very consistent so I am only going to show the output from one of them (shown below).

Apache and Ghost Siege Results

Load test results of Apache + Ghost.

Load test results for Nginx + Ghost for easy comparison with the results above.

Load test results for Nginx + Ghost for easy comparison with the results above.

The results shown above are interesting. Apache + Ghost was actually slightly FASTER than running Ghost with Nginx. Ghost is still super fast regardless of using Apache or Nginx as the web server.

The Conclusion

Ghost is way faster and can handle way more load than WordPress while also consuming much less CPU resource (Ghost also has considerably less functionality than WordPress but that’s not relevant for the purpose of this test). It would be interesting to run Ghost in a 2 process Node.js cluster and see  what difference it makes in throughput and CPU utilization. Hmmmm, that sounds like a really good subject for another blog post…

Another interesting topic that I didn’t cover here is monitoring for both of these platforms. In my mind it’s not enough to just observe the behavior of these platforms from the outside. I want to see what’s going on from the inside. In a future blog post I am going to monitor Ghost with Nodetime and will monitor WordPress with AppDynamics. I can’t wait to see how they both look from the inside!

Update on 11/14/2013: Due to popular request I have performed more testing, this time with an opcode cache for PHP. You can read all about it in An Example of How Node.js is Faster Than PHP – Part 2

Appendix

Here are the links to the information I used to build out my blogging and testing platforms (I used the relevant portions of each article since my configuration was different than what was in each article alone):

How to install Node.js: https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager

How to install Ghost: http://docs.ghost.org/installation/

How to install MySQL: http://www.cyberciti.biz/faq/how-to-install-mysql-under-rhel/

How to install and configure NginX and use MySQL: http://0v.org/installing-ghost-on-ubuntu-nginx-and-mysql/#.Ul26n2RATL4

Where to find Siege: http://www.joedog.org/siege-home/

Where to find Sproxy: http://www.joedog.org/sproxy-home/

More good information on using Siege and Sproxy: http://www.euperia.com/linux/tools-and-utilities/speed-testing-your-website-with-siege-part-two/771

AppDynamics selects AppDynamics to monitor AppDynamics.com

Today we announced a great milestone at AppDynamics: We have selected an application performance management (APM) solution to monitor our Drupal/WordPress website, and we decided to go with AppDynamics. In order to get a pretty sweet discount on the product we agreed to sell our souls and do a press release AND a video testimonial. Here are both of those (totally serious) marketing assets. Enjoy.

AppDynamics Selects AppDynamics to Monitor AppDynamics.com

Leading APM Company Chooses Leading APM Company to Ensure Performance of Company Web Site

Today AppDynamics announced that it selected AppDynamics to monitor the performance of its web site, AppDynamics.com. The company’s marketing team evaluated multiple potential vendors but chose AppDynamics due to its unmatched ability to identify bottlenecks and resolve problems in production web sites.

Chris Tiwald, Technical Operations Engineer at Conductor who uses AppDynamics, commented, “I don’t understand why the marketing team at AppDynamics didn’t talk to me for this press release. I’m an actual customer who loves AppDynamics, and I would have been happy to share that we’ve seen amazing uptime, performance gains, and ability to correct critical web site problems fast using their easy-to-use and deploy solution. But if they want to do the press release by themselves, whatever, I’m fine with that, I guess.”

The AppDynamics marketing team selected AppDynamics.com based on its ability to gain 100% visibility when monitoring their PHP environment, its rapid troubleshooting capability, and the solution’s overall ease of use.

“The AppDynamics.com web site drives a majority of the leads that ultimately become revenue for the company, and therefore it’s critical that we find and fix web site issues in record time,” said Greg Howard, Sr. Director of Marketing at AppDynamics. “We’ve found that AppDynamics for PHP does exactly that. Another plus was its simplicity and lack of required configuration—after all, I was a liberal arts major and I need my APM tool to be simple.”

“We evaluated other PHP solutions and found that they were hard to use, worked poorly in production, and had terrible looking dashboards,” said Stephen Burton, Director of Product Marketing and Technology Evangelism for AppDynamics. “Only AppDynamics met the requirements of the AppDynamics marketing team. And I play poker with the sales guy, so that was a plus.”

“If our solution is good enough for the likes of Netflix, Priceline, TiVo, AMICA Insurance, Hotels.com, StubHub, Staples, Insight Technologies, and Cornell University, it ought to be good enough for AppDynamics. Therefore, I’m pleased that the AppDynamics marketing team selected AppDynamics to monitor AppDynamics.com,” said Jyoti Bansal, Founder and CEO of AppDynamics. “As we continue to disrupt the market with our application management solution designed for production environments, we’re seeing companies flock to our new approach and throw out legacy vendors that are overly complex, expensive, and ill-suited for today’s highly distributed applications. Furthermore, this validates that the people I hire have very good taste.”