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 test.domain.com. 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.