Archive for the ‘Linux’ Category

Friendster Architecture

July 11, 2007

Friendster is one of the largest social network sites on the web. it emphasizes genuine friendships and the discovery of new people through friends.

Site: http://www.friendster.com/

Information Sources

Friendster – Scaling for 1 Billion Queries per day

Platform

MySQL
Perl
PHP
Linux
Apache

What’s Inside?

Dual x86-64 AMD Opterons with 8 GB of RAM
Faster disk (SAN)
Optimized indexes
Traditional 3-tier architecture with hardware load balancer in front of the databases
Clusters based on types: ad, app, photo, monitoring, DNS, gallery search DB, profile DB, user infor DB, IM status cache, message DB, testimonial DB, friend DB, graph servers, gallery search, object cache.

Lessons Learned

No persistent database connections.
Removed all sorts.
Optimized indexes
Don’t go after the biggest problems first
Optimize without downtime
Split load
Moved sorting query types into the application and added LIMITS.
Reduced ranges
Range on primary key
Benchmark -> Make Change -> Benchmark -> Make Change (Cycle of Improvement)
Stabilize: always have a plan to rollback
Work with a team
Assess: Define the issues
A key design goal for the new system was to move away from maintaining session state toward a stateless architecture that would clean up after each request
Rather than buy big, centralized boxes, [our philosophy] was about buying a lot of thin, cheap boxes. If one fails, you roll over to another box.

LiveJournal Architecture

July 9, 2007

A fascinating and detailed story of how LiveJournal evolved their system to scale. LiveJournal was an early player in the free blog service race and faced issues from quickly adding a large number of users. Blog posts come fast and furious which causes a lot of writes and writes are particularly hard to scale. Understanding how LiveJournal faced their scaling problems will help any aspiring website builder.

Site: http://www.livejournal.com/

Information Sources

LiveJournal – Behind The Scenes Scaling Storytime
Google Video
Tokyo Video
2005 version

Platform

Linux
MySql
Perl
Memcached
MogileFS
Apache

What’s Inside?

Scaling from 1, 2, and 4 hosts to cluster of servers.
Avoid single points of failure.
Using MySQL replication only takes you so far.
Becoming IO bound kills scaling.
Spread out writes and reads for more parallelism.
You can’t keep adding read slaves and scale.
Shard storage approach, using DRBD, for maximal throughput. Allocate shards based on roles.
Caching to improve performance with memcached. Two-level hashing to distributed RAM.
Perlbal for web load balancing.
MogileFS, a distributed file system, for parallelism.
TheSchwartz and Gearman for distributed job queuing to do more work in parallel.
Solving persistent connection problems.

Lessons Learned

Don’t be afraid to write your own software to solve your own problems. LiveJournal as provided incredible value to the community through their efforts.

Sites can evolve from small 1, 2 machine setups to larger systems as they learn about their users and what their system really needs to do.

Parallelization is key to scaling. Remove choke points by caching, load balancing, sharding, clustering file systems, and making use of more disk spindles.

Replication has a cost. You can’t just keep adding more and more read slaves and expect to scale.

Low level issues like which OS event notification mechanism to use, file system and disk interactions, threading and even models, and connection types, matter at scale.

Large sites eventually turn to a distributed queuing and scheduling mechanism to distribute large work loads across a grid.