Coding in the Cloud – Rule 5 – CMS Plugins

By: Adrian Otto

This continues my series on Rules for Coding in the Cloud. These are rules I’ve developed after watching applications encounter problems at scale when deployed on Cloud Sites.

A lot of our customers use WordPress, Drupal, or other content management systems and leverage plug-ins and design templates (aka: Themes) supplied by an avid developer community. With so many plug-ins available, it’s easy to turn on every plug-in under the sun, which could potentially leave you with a lot of poorly written and sloppy code on your site. Soon there are hundreds of plug-ins consuming resources like crazy.

So the first question we ask anybody who says, “I have a slow WordPress site” is “What plug-ins do you have turned on, and can you turn some off?” The infamous example is the geo location plug-in, which really only calls the web service of a free geo location service (for more details about why this is a problem, see Rule 4 about avoiding external dependencies).

Turn all that junk off.

Make an effort to turn on plug-ins only if you know what they do, who published them, and that they’re reasonably efficient—as demonstrated through your own testing or from experience. I wouldn’t recommend running experimental plug-ins, especially on a site with a lot of activity. Once you install any plug-in that happens to be in the WordPress “Extend” directory, the next thing you know, your usage is up a hundred times and you receive a hefty compute cycle bill. Many times we will note the day the high usage started and ask if something was installed around that time. The culprit is often a new plug-in. You must not assume that just because a plug-in exists that it’s well written or well tested, even if it has positive reviews and a lot of downloads.

Run a test site.

Running a test site is a good idea when you try new plug-ins or any other kind of change that might affect your compute cycle usage. Since you can create another site on Cloud Sites at no additional charge, you can make a copy of your site and upload it to a new area, like Run a few thousand hits of test traffic through it and look at the compute cycle usage. Then install the plug-in and repeat the experiment so you can see the difference.

The best approach is to turn off all plug-ins and then turn on one at a time, as necessary. Remember that any plug-in, even if it is just there and loaded, consumes additional resources. Ask yourself if you really need all the plug-ins you have loaded and if you are aware of their performance impact. If not, you might want to disable or remove them to ensure better site performance and lower compute cycle bill.

Adrian serves as a Distinguished Architect for Rackspace, focusing on cloud services. He cares deeply about the future of cloud technology, and important projects like OpenStack. He also is a key contributor for and serves on the editing team for OASIS CAMP, a draft standard for application lifecycle management. He comes from an engineering and software development background, and has made a successful career as a serial entrepreneur.


  1. Whilst I found your other posts helpful and even bookmarked them, this one I don’t like. You’re exaggerating the dangers of plugins/modules.

    Basically this article can be summed up: use trustworthy and efficient code, esp. when coming from third party; full stop.

    Hope the next post will be better.

    Btw, I would welcome also some quality news about what RackspaceCloud prepares for its users in this context. I see little development in terms of speed, functionality and monitoring tools.

    For example, one thing that would help us all find plugins of low quality would be precise statistics about how many cycles what scripts consume! MediaTemple has had it for years, so why not the otherwise excellent CloudSites?!

    (Besides, still no SSH terminal for CloudSites, slow Control Panel, extremely poor Client Control Panel, too short timeout for DB connections, etc.)

  2. I don’t completely agree with Tomas. I have seen many CMS plugins (Joomla in particular) that use very inefficient code. Sometimes just being aware of the fact that crap code exists helps designers/developers consider the penalties for plugin-happy design.

    For example, we had one plugin on a number of our websites that our creative department liked to use because it allowed them to display articles in a way that appealed to their creative tastes. Sure, it was useful, and it did it’s job. However, after I performed some performance research on some of these sites, I found that this plugin was a common factor for slowness across the board. Each article listed in this plugin required two completely separate MySQL queries, resulting in 100+ queries per request. Furthermore, I found that this plugin reported to support caching (it even had an option to enable caching), but the author did not include any caching logic in his code whatsoever. I had to modify this plugin myself to get the performance we needed.


Please enter your comment!
Please enter your name here