Tag Archives: How To

How-to Switch from CentOS 5.6 to Scientific Linux 5.6

I have recently switched my Lin­ode VPS from Cen­tOS 5.6 to Sci­en­tific Linux 5.6 because I got a bit sick of all of the delays that the Cen­tOS team have been expe­ri­enc­ing, to be hon­est I don’t care what their rea­sons are, I just want a dis­tro that fol­lows RHEL a bit faster!

I think I can sum­marise my rea­sons based on this email:

  • Faster updates
  • Pro­fes­sional
  • Secu­rity and bug­fix updates separate
  • Secu­rity updates also for older ver­sions of SL
  • More reli­able than CentOS

The Cen­tOS guys seem more focused on infight­ing rather than focussing on get­ting Cen­tOS 6 out the door, con­sid­er­ing how long RHEL 6 has been avail­able this has turned into a bit of a joke!

When I googled around I couldn’t find a con­cise arti­cle that explained how to do this, so here is a my sim­ple guide to switch­ing from Cen­tOS 5.6 to Sci­en­tific Linux (SL) 5.6, it was rel­a­tively straight­for­ward and my rock solid VPS has stayed up and reli­able through­out the process. These instruc­tions are based on the fol­low­ing articles:

If you want to tell what ver­sion of Cen­tOS you are cur­rently run­ning you can use the fol­low­ing command:

cat /etc/redhat-release

Now to “upgrade” to SL. All com­mands should obvi­ously be run as root.

You might also want to back up your release file, you can do that with the fol­low­ing command:

cp /etc/redhat-release /etc/redhat-release-saved

Then just use the fol­low­ing com­mands to remove Cen­tOS and install SL:

yum clean all
rpm -e --nodeps centos-release-notes centos-release yum-3.2.22-33.el5.centos.noarch redhat-logos redhat-artwork redhat-menus
rpm -e --nodeps yum-3.2.22-33.el5.centos.noarch
rpm -ivh http://ftp.scientificlinux.org/linux/scientific/56/i386/SL/sl-release-5.6-1.i386.rpm http://ftp.scientificlinux.org/linux/scientific/56/i386/SL/sl-release-notes-5.6-1.noarch.rpm http://ftp.scientificlinux.org/linux/scientific/56/i386/SL/redhat-artwork-5.0.9-2.SL.4.i386.rpm http://ftp.scientificlinux.org/linux/scientific/56/i386/SL/redhat-logos-4.9.16-2.sl5.6.noarch.rpm http://ftp.scientificlinux.org/linux/scientific/56/i386/SL/redhat-menus-6.7.8-3.el5.noarch.rpm http://ftp.scientificlinux.org/linux/scientific/56/i386/SL/yum-3.2.22-33.sl.noarch.rpm http://ftp.scientificlinux.org/linux/scientific/56/i386/SL/yum-autoupdate-1.1-1.SL.noarch.rpm http://ftp.scientificlinux.org/linux/scientific/56/i386/SL/yum-conf-56-1.SL.noarch.rpm
yum update all

If you now check what release ver­sion you are on you should see some­thing like the following:

[root@wahala ~]# cat /etc/redhat-release
Scientific Linux SL release 5.6 (Boron)
[root@wahala ~]#

Next I think I’ll attempt to upgrade or rebuild my VPS to run Sci­en­tific Linux 6… the sub­ject of a future blog post!

How to Optimise WordPress Performance for Search Ranking

Google says that they use the per­for­mance of your web­site as part of your search ranking:

You may have heard that here at Google we’re obsessed with speed, in our prod­ucts and on the web. As part of that effort, today we’re includ­ing a new sig­nal in our search rank­ing algo­rithms: web­site speed. Site speed reflects how quickly a web­site responds to web requests.

Speed­ing up web­sites is impor­tant — not just to site own­ers, but to all Inter­net users. Faster sites cre­ate happy users and we’ve seen in our inter­nal stud­ies that when a site responds slowly, vis­i­tors spend less time there. But faster sites don’t just improve user expe­ri­ence; recent data shows that improv­ing site speed also reduces oper­at­ing costs. Like us, our users place a lot of value in speed — that’s why we’ve decided to take site speed into account in our search rank­ings. We use a vari­ety of sources to deter­mine the speed of a site rel­a­tive to other sites.

Here are more good rea­sons why speed matters:

Speed is among the most sig­nif­i­cant suc­cess fac­tors web sites face. In fact, your site’s speed directly affects your income (rev­enue) — it’s a fact. Some high traf­fic sites con­ducted research and uncov­ered the following:

  • Google.com: +500 ms (speed decrease) -> –20% traf­fic loss [1]
  • Yahoo.com: +400 ms (speed decrease) -> –5–9% full-page traf­fic loss(vis­i­tor left before the page fin­ished load­ing) [2]
  • Amazon.com: +100 ms (speed decrease) -> –1% sales loss [1]

A thou­sandth of a sec­ond is not a long time, yet the impact is quite sig­nif­i­cant. Even if you’re not a large com­pany (or just hope to become one), a loss is still a loss.

So how do you speed up your Word­Press web­site to get that extra edge in search rank­ings and give a bet­ter expe­ri­ence to your users? Well you install a caching plu­gin of course! How­ever not all caching plu­g­ins are cre­ated equal. For years WP Super Cache has been my weapon of choice because it is sim­ple to install, very fast and is being con­stantly devel­oped and improved.

One thing always annoyed me though, when I ran any of the per­for­mance analy­sis plu­g­ins like Page Speed and YSlow in Fire­fox or the built in Webkit devel­oper tools in Chrome and Safari, my sites still weren’t scor­ing top marks even though caching was fully on. This really bugged me as I’m such a per­fec­tion­ist! I just hated to see those red results in the Page Speed report.

Some of the things that always came up when I looked at the gen­er­ated reports included:

  • Make fewer HTTP requests
  • Add Expires headers
  • Com­press com­po­nents with gzip
  • Make JavaScript and CSS external
  • Use a Con­tent Deliv­ery Net­work (CDN)
  • Con­fig­ure entity tags (ETags)
  • Use cookie-free domains

When I finally came across W3 Total Cache I knew I’d finally found the solu­tion to all of this. After mak­ing the switch from WP Super Cache to W3 Total Cache I know I’ll be doing this for all Word­Press imple­men­ta­tions I do in the future. Don’t get me wrong though, for a sim­ple low traf­fic site WP Super Cache is prob­a­bly the way to go every time for it’s sim­plic­ity and the lack of tech­ni­cal skills required to install and get it up and run­ning. How­ever if your site has a lot of traf­fic or you want to improve your web­sites per­for­mance by an order of mag­ni­tude then I would rec­om­mend switch­ing to W3 Total Cache. It requires a lit­tle bit more tech­ni­cal knowl­edge, but it is well worth it.

We were run­ning WP Super Cache (fully opti­mised) on our site limbelabssolutions.com before switch­ing to W3 Total Cache, the stats below speak for themselves.

Page Size (bytes)Total RequestsGrade (0–100)Load Time (ms)
Before23878124751960
After18212112941299

This could make all the dif­fer­ence to your server if you get a lot of traf­fic or want to be pre­pared for a sud­den spike in traf­fic and of course improve your search rank­ing at the same time.

Here are the steps I rec­om­mend you take before installing W3 Total Cache, includ­ing some gotchas to watch out for.

  • Bench­mark your site before, dur­ing and after to under­stand the impact of your changes. There are many tools out there that you can use. I would rec­om­mend a com­bi­na­tion of the following:
    • Use Google Web­mas­ter Tools, they have some nice stats on crawl­ing your site, page load times and page sizes.
    • Use the Page Speed and YSlow plu­g­ins for Fire­fox to pro­file your site.
    • Safari and Chrome have a great Webkit pro­filer built into the devel­oper menu.
    • There are some online tools that you can use, some I like are www.showslow.com, www.webpagetest.org, tools.pingdom.com
  • Remove all exist­ing caching plu­g­ins AND delete them. I didn’t do this and it cause me end­less prob­lems until I realised what was going wrong.
  • Install the W3 Total Cache Plu­gin, com­pre­hen­sive instruc­tions are here. Read them before you start as there are a few extra essen­tial steps that dif­fer from the norm and they will throw you if you don’t RTFM. Here’s a good tuto­r­ial on how to do it.
  • I used our own sim­ple Con­tent Deliv­ery Net­work, which was very easy to setup (see the the tuto­r­ial link above). One com­ment I would have on the CDN is that I wouldn’t host your mini­fied CSS/JS on the CDN as they aren’t gzip com­pressed when served up, if you keep them on your main site then W3 Total Cache will serve them gziped. I’m run­ning all this in a shared host­ing envi­ron­ment, if I had a ded­i­cated server I would have more con­trol. You will also need to set your Word­Press cookie domain in your wp-config.php file if you use this setup.

So there you have it, def­i­nitely use W3 Total Cache over WP Super Cache if you want to get that extra edge. How­ever it is a bit more com­pli­cated to install and keep running.