Scaling Facebook To 140 Million Users 178
1sockchuck writes "Facebook now has 140 million users, and in recent weeks has been adding 600,000 new users a day. To keep pace with that growth, the Facebook engineering team has been tweaking its use of memcached, and says it can now handle 200,000 UDP requests per second. Facebook has detailed its refinements to memcached, which it hopes will be included in the official memcached repository. For now, their changes have been released to github."
Re:I have been wondering for a while... (Score:5, Informative)
Myspace used to run on cold fusion but switched to .NET. facebook runs on LAMP, though they have a customized MySQL and a customized linux kernel with support for the hierarchial page pinning algorithm.
Re:The problem of Facebook (Score:3, Informative)
Yes, you can delete your account... not sure if Facebook purges the data from their servers, but it shouldn't be accessible to anyone else after you delete your profile.
You can also set it so that only certain groups of people (or no one at all) can see your profile, customizable on an item-by-item basis (including various things like phone, address, profile picture, status, birthday, birth year, friends list, bio, wall posts, videos, pictures) and/or comment on your wall, pictures/videos, or send you messages.
You can also tell it not to let search engines like Google find your profile, which I'd also recommend.
Actually, if you really want to play with it, I'd recommend that you register under a fake name and fool around with the security settings. If you're satisfied that it's private enough for your tastes you can put your real name and info up.
Re:Business plan? (Score:3, Informative)
Advertising, I assume.
Re:Wow (Score:5, Informative)
Re:I have been wondering for a while... (Score:5, Informative)
Re:[Unintelligible] Facebook [Unintelligible] (Score:2, Informative)
Re:Wow (Score:5, Informative)
Source: http://frro.net/blog/2008/04/26/just-how-big-is-facebooks-infrastructure/ [frro.net]
Re:Blaming Linux... (Score:4, Informative)
2. If you'd read the next sentence right after your bold line, you'd notice they were talking about a kernel lock. Not a lock in memcached. Thats a totally valid reason to blame linux.
How do you hope to architect a fix for this? Thought I don't know the specifics, they said that they were using the same UDP socket to transmit from multiple threads. That means you have one kernel space data structure across the entire UDP/IP stack being shared by multiple threads. Therefore you need a lock around updates to that data structure.
Until we see some atomic sendto() operations this is not going to change.
Re:Thank goodness (Score:3, Informative)
I was amazed at how many sites i regularly frequent that are now plastered in ads and horrible to use.
Re:Pretty impressive operation - NOT! (Score:1, Informative)
Re:[Unintelligible] Facebook [Unintelligible] (Score:1, Informative)
It's not incorrect:
http://en.wikipedia.org/wiki/American_and_British_English_differences#Numbers
Re:Blaming Linux... (Score:4, Informative)
Mutexes aren't always slow. In the uncontended case they don't require a system call (although they do require an atomic operation which involves some inter-processor signalling).
Lockless algorithms are generally harder to get right, from what I've seen. It's not just locking the cpus for a cycle, but you also need to worry about using memory barriers (generally written in assembly) to enforce correct visibility across all cpus in the system.
There are guys on comp.programming.threads that spend a *lot* of time trying to perfect them, and there are often subtle errors that pop up later on. Given the number of problems that regular lock-based algorithms cause, I'd only use lockless if it's absolutely necessary.
Re:Wow (Score:1, Informative)
If you'd RTFA, you'd see it says: We use more than 800 servers supplying over 28 terabytes of memory to our users.
http://www.facebook.com/note.php?note_id=39391378919&id=9445547199&index=0
Re:[Unintelligible] Facebook [Unintelligible] (Score:3, Informative)