Just before Christmas, Steel Panther were played played in the office quite a lot. There's were I first really go into them. Now I'm addicted. They are great. They aren't anything serious just lots of fun, although their music is pretty good. My favourite song is Community Property. Here's the official video unfortunately it's censored :(. 

A few weeks back I had a training session with Positive Internet as part of my job at Jadu. The training was on Linux, focused towards setting up and managing a server. The training was really interesting and I learnt a lot. However, the one thing really stuck out for me was performance.

Modern websites are dynamic. They do so much behind the scenes to serve each and every page. Generally it does this all in a fraction of a second and that's what we want, a page displayed and fast. Great! It's all well and good when it's working and you get the page in under a 1/10th of a second but what if you get a spike in traffic from a site like digg? In this scenario you might get 100s of people visiting your site at the same time. Your page that loaded in a 1/10th of a second for one user could easily take 10 seconds or more to load for some users and that's assuming you only get 100 visitors in the space of a second. What if you get 100 visitors every second? Then the server wouldn't be able to handle the requests and probably crash, making your site totally unavailable. Just imagine how much you could lose from your site going down at such an opportune moment? It's not good.

Most web developers would know the above and have solutions to the problems. I did. One time TheWebDump.com was picking up traffic and my hosting company disabled the site. The reason they disabled the site was because it was causing too much load on the shared server. They had every right to do so. So I had to figure out why it was causing load and then come up with a solution. The cause was each page repeatedly made the same queries over and over. Some of these were quite complex which didn't help. The solution that I found was to cache the output of part the page that was included in every page into a file and just load it from there every time. Caching solved the problem for me.

The other option was the other type of cache, cash. I could have just moved to a dedicated server and got rid of my problems with cash. Throwing money at things isn't the way to fix problems. The site might have grown more and would need another server and possibly another and it would have cost too much. Caching is the answer. Granted sometimes you cannot cache or already cache as much as you can and cash is the only solution. If this is the case you should really be making enought money that spending cash to keep making money isn't going to cause problems.

Well that's was really all my exposure to caching uptill this training. The guys teaching demonstrated, with Apache Bench and a WordPress install, how a server can easily crash with not really that many users. They then installed a program that can follow the files being used by a process. So this was set to watch WordPress and it was really amazing how many files WordPress was using. WordPress was accessing the database and including the same php files every time the homepage was visited. Here I found out something I kinda knew but never thought about before. Everytime a php file is included into another php file it has to be interpated. Doesn't matter how simple the script you include is it still has to be interpated and then executed. This may take no time at all but it really adds up. Some of the php files were just basic template or skin files that rarely ever change and simply by making them static html files so much CPU time could have been saved.

I've not really touched on the reason I am posting this other than I'm just sharing some experiences and knowledge. Well the reason being is I was also told about query caching. It's simple. Make a database query and store the results in a file. This is something I'd never thought of but really stuck in my head after this training. I wanted to try this out and it just happened that I was getting back into my CMS. So one night I decided to test this out.

What I did:
1. Created a cache class,
2. Modified my database class to use this,  
3. Created a simple SELECT query that could be cached and,
4. Ran 100, 1,000 and 10,000 queries in 2 modes (not cached and cached) on my local WAMP server.

The results

I was happy to see it in action and it really showed me the benefits of caching queries. There was a problem with the test. That being that it wasn't a real world example. I cannot see any time I'd need to run the same query 100-10,000 times in one script execution. So I did another test. This time I looked at the time it took to generate my homepage. The homepage at the time consisted of only 3 queries but it's a realistic test. So I loaded the page with no cache, revisited the page and then deleted the cache. I did this 4 times and recorded the results.

Note: Tests were run on a laptop running WAMP. It's not really a server machine but the results show good proof that caching can really make a difference.

You can see that loading from cache was much faster. On average it was 3.11279 times faster. So in theory if site was running at full capacity on 3 servers I could bring in caching and completely remove 2 servers. That 3 times faster loading is directly proportional to server costs. Cutting 2/3rds of any budget is great and all it took was about an hour of fiddling with some code. Even if caching doesn't cut costs it can help else where. Such as getting listed on search engines. Google News states on it's site that it only lists websites that respond fast so caching could really help you get more traffic. And with all this extra traffic you'll be glad your site is caching.

That's all. Hope someone finds this helpful. When I make live my latest version of the CMS I'll run more tests on the live server and post the findings.