Madeglobal Wordpress Plugins

There are many posts online claiming the best way to speed up wordpress, and many of them are very good. But this is the Madeglobal take on what we did to speed up one site from a massive 21 second load time to a lovely 3 or 4 seconds.

Firstly, the site in question is http://www.theanneboleynfiles.com,  and the reason the site needed speeding up was because the site was getting up to 1000 people a day visiting. The site had been working fine, but as more and more people began visiting, it suddenly hit a “wall” and was mostly unresponsive.

So what did we do?

First Steps

1. Update all the plugins.
   That’s because we found that one particular plugin was causing more than 2000 accesses to the database for each page load (wp-e-commerce) and of course that was terrible! It’s also ALWAYS good practice to update your plugins
2. Update wordpress.
   Don’t need to say this? Of course you keep it up-to-date??!
3. Find out which components are taking a long time to load
   Ok, that’s an easy statement to make, but we’ll look into it a little more below…
4. Use a Content Delivery System CDN for Wordpress
   What’s one of them then? A system where images, css and javascript files can be served from other people’s computers. We have started using www.maxcdn.com and it is absolutely amazing!
5. Use w3-total-cache
   It is more complicated to use than wp-super-cache, but it flawlessly integrates with your CDN. And it minifies your CSS and your JS AND it does lots of other things really really well.
6. Use GravatarLocalCache plugin
   This makes your gravatar images be served from Your computer (but we went one better and made them served from the CDN!), which saves a huge amount of time doing DNS lookups for these images. Simple and easy!
7. Run your site through Firebug “YSlow” on firefox
   This will quickly tell you what is big/slow/wrong
8. Shrink every single image file you use, using Smush.it
   Simple to do if you run it from YSlow (step above) because it automatically feeds all the images into Smush.it, and you can download the shrunk results in the correct directory structure before re-uploading them onto your server. This can save hundreds of kb without any work on your own behalf!
9. Use “top” command from linux to see what is going on
   This command shows you which processes are taking a lot of time, and also how busy your server is. Looking right now at our server, we have 30 simultaneous users online RIGHT NOW, and the server load is around 0.50. NOTE that this is AFTER all of the changes on this page have been added.
10. Use “free” command from linux to see the state of your memory
    The key to this command is the +/- buffers line. Ours says:
    -/+ buffers/cache:     135832     637100
    And that is good… lots and lots of free memory!

See how your database is performing

If you have access, add the following lines into the footer part of your template files:

<!–<?php echo $wpdb->num_queries; ?> <?php _e(‘queries’); ?>. <?php timer_stop(1); ?> <?php _e(’seconds’); ?>.–>

Then reload your page and look at the source code from the browser. This was how we found out that one plugin had gone crazy. We typically get:

<!--114 queries. 1.235 seconds.-->

And of course, this is then cached by W3-total-cache, so that the page AND the database entries are cached, page load is typically 3 seconds in total, for this complicated site.

Use an Op-Code Cache – use APC

This is a huge speed up if your site is hosted on your own server, or a server where you can alter the core linux settings.

We installed APC (there are many sites online as to how to do this, depending on your linux flavour) and then we found that it instantly filled up and was refreshing thousands of times. The default setting sets aside 32MB for the APC cache and this simply was not enough. Right now we have increased this to 128MB (there was plenty to spare in our server) and it has vastly increased the speed of the site.

How did we do that?

http://php.net/manual/en/apc.configuration.php

Want to avoid segmentation with apc.shm_segments?If your linux server limits the shared memory block size and you're forced to use apc.shm_segments instead, change the setting by using (here is 512M but change it as you like):
# sysctl -w kernel.shmmax=536870912

(but if you want the change to be permanent after a restart you would have to add the following line in /etc/sysctl.conf

kernel.shmmax=536870912)

and updating apc.ini

apc.shm_segments=”1″
apc.shm_size=”512″

Ok. Then make sure that you make your w3-total-cache database caching use the APC cache method and your database accesses are speed up to mega ultra speed!

The other thing to do is to put in the recommended APC settings (with more memory available) which are outlined within the w3-total-cache plugin. These really do work!

Tune Apache and MySQL for Wordpress

We initially had a lot of problems with the server having out-of-memory errors with wordpress. That was because the number of apache clients was too large for the memory available. We did two things:

1. Increase the amount of physical memory in the system (now running with 768MB)
2. Reduce the number of apache clients to 35. This number evolved as time went by to get it as high as possible

The way to do that will be different depending on your linux flavour, so no information is included here… but it’s well worth getting the number of simultaneous connections as high as possible, without breaking your memory limits.

Also, increase the amount of MySQL caching memory a little. It is not entirely certain that this has made much of a speed up since a lot of the database work is now being done using the APC caching, BUT for all new queries, it has to make some difference!

Optimize your MySQL database for wordpress regularly

With a busy site, inevitably the database will get clogged up with rubbish, which will slow everything down for your wordpress site. So, you can either regularly run “optimize” from with PHPMYADMIN on your database, or if you have access to your server, then this is simpler:

(From mydigitallife.info)

mysql> GRANT SELECT, INSERT ON *.* TO ‘mysql_opt_db’@'localhost’ identified by ‘hard password’;
 mysql> flush privileges;
 mysql> exit;

> crontab -e
 # MySQL weekly optimisation
 0 0 * * 0 /usr/bin/mysqlcheck -Aos -u mysql_opt_db -phard password > /dev/null 2>&1

AND FINALLY

Don’t forget the simple things like checking that your site validates using http://validator.w3.org/ because if your code does not validate, it will:

1. not be consistent across all the different browsers
2. potentially break on some browsers (IE!)
3. make the browser work harder than it needs to, therefore slowing things down

Conclusion

The wordpress website was working before any changes, but if more than 4 or 5 people were on there simultaneously, the load on the server went crazy (like up to 20 or more!).

After applying all of the steps above repeatedly until each single step was optimized for wordpress use, the load is now under 1 almost all of the time, even when there are 30+ people on the website at the same time.

Wow. What a lot of work… but it’s well worth it to have the fastest possible Wordpress site.

[ No Comments Yet ]