The wealth of information on scaling is profound. Although, there was one lesson that I found to be the most interesting. This is that every web application is different. This is not to say that we cannot learn from others that have come before us, but we need to understand that every application has a wide variety of demanding requirements. This may include a special read/write mixture of database operations or an inability to effectively cache content. Because of these differences, developers must be extremely perceptive of their system. This means constant monitoring of the site’s trends.
All sites have an average load. Most sites also have a peak load for specific times of the day, week, and year. Furthermore, rapid spikes in I/O are frequently triggered by popular news and blog sites. Planning for yearly spikes is important. Many sites will maintain only 10-20% of their capacity during regular hours to support the eventual peak loads. Even if you don’t want to build your system to handle the few extreme user loads, Amazon and others provide virtually unlimited backup capacity if your software is designed to scale in such a fashion. There are a variety of sites online today running a variety of configurations. Many of the largest web servers have developed unique and quite different solutions to their scaling problems. And not all of those solutions were expensive, proprietary hardware/software.
Segmentation of a site’s features is the first and foremost mentioned method of scaling. Once a system can be segmented, it can be clustered, sharded, and/or balanced. This is applicable to the entire scalable architecture. This is the point at which you stop scaling vertically and begin to scale horizontally. Developers can stop tweaking for minor performance improvements and begin to design the software to handle indefinite user loads at the cost of cheap redundent hardware.
The most popular solution begins by breaking the web server or web application from the database. At this point, each of these can add clusters, layers of redundency, and optimizations based on your read/write mixture. This can be quickly followed by application caching to reduce the inevitable bottleneck within the server. The relational database is almost always the bottleneck in a system, so avoiding accesses to the database is best. Furthermore, expensive operations, such as joins, can be performed at the application level, or they can not be done at all.
Some bloggers have a tendency to blame the language that an application was build upon as a impediment to scale and response. While this may play a factor, I have never seen a developer for a large web service blame shortcomings of the system upon the language in use. In fact, most problems arise from applications being poorly designed for their actual purpose, poorly designed for scale, and poorly designed for transparency.
I’ve gathered a ton of articles on how to make scaling improvements to a general installation. I would recommend looking through a few of these. I found the articles on amazon, google, and facebook architectures to be very interesting.
Very informative on scaling Drupal
http://www.johnandcailin.com/blog/john/scaling-drupal-open-source-infrastructure-high-traffic-drupal-sites
Maximum performance from Apache articles
http://www.howtoforge.com/configuring_apache_for_maximum_performance
http://www.howtoforge.com/benchmark-apache2-vs-lighttpd-images
http://www.howtoforge.com/benchmark-apache2-vs-lighttpd-static-html-files
Current server types in use today
http://news.netcraft.com/archives/web_server_survey.html
This article is a little old, but it is quite funny.
http://www.reallylinux.com/docs/scaling.shtml
A slideshow of current scaling strategies
http://www.slideshare.net/Georgio_1999/how-to-scale-v2/
Ruby on Rails and S3 Slideshow
http://www.slideshare.net/jboutelle/scalable-web-architectures-w-ruby-and-amazon-s3-14894?src=related_normal&rel=56697
May not be realistic, but these are the claims of the VMWare crowd.
http://blogs.vmware.com/performance/2008/06/scaling-real-li.html
Scaling a website with a focus on caching and read pools
http://www.michaelnygard.com/blog/2007/11/two_ways_to_boost_your_flaggin.html
The number of servers some of the top websites are currently using. And some comments!
http://www.paragon-cs.com/wordpress/2008/04/16/scaling-mysql-up-or-out-panel-uc/
http://gigaom.com/2008/04/25/facebooks-insatiable-hunger-for-hardware/
Slideshow on scaling
http://www.linuxworld.com/events/2008/A4-080820_01:18:49.pdf
Short article on loadbalancing and clustering
http://paulmcnally.info/?p=16
Tuning the iPlanet web server
http://docs.sun.com/source/816-5690-10/perf6.htm
Very interesting articles on how the largest web services scale. This is how the big dogs do it.
http://highscalability.com/youtube-architecture
http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
http://highscalability.com/plentyoffish-architecture
http://highscalability.com/google-architecture
http://highscalability.com/ebay-architecture
http://highscalability.com/flickr-architecture
http://highscalability.com/amazon-architecture
http://highscalability.com/myspace-architecture
http://highscalability.com/digg-architecture
http://highscalability.com/how-i-learned-stop-worrying-and-love-using-lot-disk-space-scale
http://highscalability.com/unorthodox-approach-database-design-coming-shard
A definition of scalability
http://highscalability.com/tags/capacity
An interesting article on performance planning and the ability to determine the maximum capacity of the server
http://technet.microsoft.com/en-us/library/bb676162.aspx
A good article on how to determine metrics and scale up capacity by Flickr
http://www.kitchensoap.com/talks/MySQLConf2007-Capacity.pdf
A short blog post on sharding
http://codebetter.com/blogs/karlseguin/archive/2008/06/30/scale-cheaply-sharding.aspx
Useful Resource Links
http://squid-cache.org/
http://nginx.net/
http://www.danga.com/memcached/
http://sqlrelay.sourceforge.net
http://railsexpress.de/blog/