Click here to Skip to main content
Click here to Skip to main content

Tagged as

Go to top

My Performance Budget Continued

, 18 Mar 2014
Rate this:
Please Sign up or sign in to vote.
In my previous post, I talked about the performance budget for my website. My goal is to load from a cold cache in two seconds. From a primed cache, just one second. Before optimizations, I was at seven seconds. I haven’t been working with WordPress for very long, but I have a gut feeling that

In my previous post, I talked about the performance budget for my website. My goal is to load from a cold cache in two seconds. From a primed cache, just one second. Before optimizations, I was at seven seconds.

I haven’t been working with WordPress for very long, but I have a gut feeling that WordPress is slow. It is super easy to customize, get running, and is pretty reliable. But when it comes to raw speed, I get the feeling that it’s gonna take some work.

WordPress is written in PHP. I’ve been using PHP as my primary server-side language since 2005, so I know a thing or two about it. I’ve written a blog or two on scaling PHP. The techniques I discuss in there apply to making PHP applications run on multiple servers, and it also helps with general speed.

The first replacement I made was getting rid of Apache for Nginx and PHP-FPM. Nginx is the best lightweight static file server I’ve ever used. PHP-FPM is quickly becoming the industry standard to evaluate PHP scripts. I also added the APC op-code cache to PHP-FPM so my scripts could have some internal caching.

Even with every trick I knew, I was still running at 7 seconds to load the index page.

I love a challenge, so it was time to get creative. Two or three years ago, I was interviewing a potential employee who had their website on their resume. Being the nerd I am, I brought up the website with Chrome’s DevTools open. When I looked at the Network tab, I saw a HTTP response header I’ve never seen before:

X-Cache: HIT

Huh? That seems strange. I did some research, and found it was coming from a caching accelerator named Varnish.

The way Varnish works is simple. It stores a cache of webpages using memcached. That means it puts it effectively in the server’s RAM. Which is fast. Really fast.

Orders of magnitude faster. I helped put Varnish on the Keyhole Software corporate website recently. It was running at 4 transactions a second before Varnish. After Varnish, I was getting 100 transactions per second.

Yeah, it’s fast. After getting rid of images and putting Varnish in front, this is what I got:

images

Coming from a cold cache, Varnish was serving my website in 1.7 seconds. So far so good. How about a primed cache:

cached

Less than one second. Booyah.

I achieved my performance goals without any code changes. Zip, zero, zilch. All it took was being smart about my design, and making sure I was using the latest technologies to achieve my goals.

The next post I do will be about how to setup Varnish with Nginx and PHP-FPM for a WordPress site.

Booyah.

The post My Performance Budget Continued appeared first on Zach Gardner's Blog.

License

This article, along with any associated source code and files, is licensed under The Apache License, Version 2.0

Share

About the Author

Zachary Gardner
Software Developer Keyhole Software
United States United States
No Biography provided
Follow on   Twitter

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web04 | 2.8.140916.1 | Last Updated 18 Mar 2014
Article Copyright 2014 by Zachary Gardner
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid