An application is said to be scalable when it can be expanded to accept further load. There is still much debate over the ability for any particular language to scale, but applications certainly deserve such requirements. I recently was accepted into a consulting and development role for [Atheist Nation] – here after referred to as AN – which is a website that features a crafty chat room that is used for debate, socialization and shooting the shit, but also poses a threat to the stability of the site through what are called raids. Similar to the way a [DOS] works or the so-called [Digg effect], a raid is a massive influx to the site which causes the server to peg its processor and eventually lead to the host either dying or at least being bogged down.
I was brought in and directed to look at fixing the chat system, which turned into a nightmare. I don’t get the pleasure of ever really working with other peoples code as often as I would like since my job is mainly testing and utility development at Broadcom, but occasionally when I get a break from my own development experiences I am thoroughly impressed with what people come up with. The owner, another brilliant Robert, and administrator of AN has coded the entirety of the site, piecing together various parts of the website from what he liked and what he wanted to see implemented. It was amazing to look back on his code and see how he had started, but it brought back crisp and clear memories of when I first began work on my own original site – [Swallowbush.com]. I will say, I never dealt with half the number of users that Robert does currently, but I certainly realized the need for being succinct and direct in my coding habits. For what it’s worth, I am quite impressed with what AN is able to do… even more so since I have seen the code behind the scenes; not because it’s great but because it’s so very bad.
I started working on the chat engine, thinking rewrite and ended up just fixing. The code itself decreased in size by about 40% and I found a curious thing happening. The system sped up considerably. Below is a checklist of things you ought to think about before you start writing a chat system in PHP with AJAX as a front end, or if you are building any web app for that matter.
- Keep your database connections to a minimum and cache them
- Grab the results array (preferably hashed!) as soon as you can and free your db result resource
- Do calculations once and cache the results when you are using them multiple times
- Avoid intermediary/temporary variables
- Use string manipulation in place of simple regular expressions
- Remember that includes are costly
These pointers allowed the chat system to relinquish about 20% of the sites usage to the server. I have attached the DB Query class, which is a highly simplified version of the one I authored last year, since the queries used on this site are not as complex and mainly because I was feeling crafty. Give things a once over, expect a more technical overview of things in due time.
A few updates
- [MoonstarPhotos] has gone live, a site I have authored for a friend of mine, Fawn Luu. Give her site a hit and give her some love so she can help me get through school.
- I finished reading jQuery in Action and have a couple ideas for projects I am going to be working on when time permits me to.
- I know it sounds like an omen… but I have decided to resume work on [GneuManager] since the UT3 project I am working on is in need of the system I had devised. I only hope it comes to fruition soon.
- I have begun my trek through Calculus, finally and so far so good. My instructor and the class as a whole have pleasantly surprised me. It is, however, a shame that I cannot seem to have enough time in my day to properly enjoy it.
Thanks a bunch kids, I will be in touch.