chir.ag/tech [archive]

 
 
 
 
 
 
 

/tech home / projects / personal 'blog / about chir.ag

 

ARCHIVE: Little Servers, Big Performance

Thu. Dec 29th 2005, 11:04am:

The Falling Sand Game I am hosting on my server is attracting over 30,000 different people each day to my website. Kinda interesting. Till Dec 25, about 200 people a day visited different pages of "chir.ag". Now in just 4 days I've had over 9,000 people check out my maps and over 25,000 people check out my personal blog. The good news though is that my server's able to handle all this amazing amount of traffic without showing any signs of slowing down. After being linked on Digg, Reddit, Delicious, MSNBC and tons of other popular websites, I'm kinda proud of my little server holding up just fine.

Not a lot of people believe me when I say cheap low-end servers can hold up very well to crazy amount of traffic and 12GB/day is definitely crazy for a little 'blog like mine. But when you drill down, it's about 500MB/hour, or only 140KB/s. Any decent server should be able to handle that easily. I've configured $400 servers at my job that easily handle 512KB/s sustained for days on end as long as the other parts of the server aren't being bogged down. Most of the times when servers go down because of heavy traffic, the culprit is inefficient database querying and creating too many persistent connections to the database from the web server.

It's the classic IT-vs-Management battle. The servers are slow and Management isn't happy because the customers aren't happy. So IT puts more RAM on the servers. Then they upgrade to faster/more-expensive hard drives. Then a couple of quad-CPU rigs later, the Management is finally satisfied. But IT has spent all its annual budget by March! In few cases, this is in fact true and the hardware upgrades are pretty much the only way to improve performance. But in most cases, things are a little bit more "inefficient" than they seem.

You see, the reason why the .Net e-commerce portal seemed slow was not because the dual Xeons couldn't crunch the numbers. It was because the haphazard stacking of 30 different plugins on top of each other without any sort of optimization resulted in 45+ queries to the big Oracle database for every single page! Additionally, instead of using JOINS and Indexes, the programmers of the portal decided to query the database for records from individual tables and perform the joins on the web-server using layers of nested loops. That is, instead of SELECT customer.name, order.date FROM customer INNER JOIN order ON customer.cid = order.cid, the programmers did CUS = SELECT * FROM customer, ORD = SELECT * FROM order, and looped through CUS and ORD to find where CUS.cid = ORD.cid. Programmers like this need to be sent to prison for violating database integrity.

I'm not saying that big servers are useless. I'm pretty sure that I want my bank to use the biggest baddest mainframes out there to hold and process my money. But if you're just gonna display 100 products on a tiny website, or even 5,000 products on an internal server, you can easily get by with a $600 machine as long as you configure it well, code the system smartly, and of course, keep measuring the performance to ensure that no single task is clogging the server's resources.