Robert Johnson interviewed at Velocity 2010
Robert Johnson, Director of Engineering, Facebook
2010 O’REILLY Velocity – Web Performance and Operations Conference
June 22 – 24, 2010
7 min, 4 sec http://www.youtube.com/watch?v=wXTCPnuDGbg
My Notes:
User expectations of mobile in terms of optimization
Very little data to answer scientifically
Long term need desktop and mobile site performance to come together
Need to collect the data before setting benchmarks
Acceleration and Business Benefits Research
Huge payback for performance improvement
Initial thing that a company should do
Set benchmarch and understand how user sees the site
Keep alives on
Compression on
Workshop
Analyzed Velocity home page
Made worse than reality and brought it to current then improved
Here are my notes from the the Velocity 2010 lecture "A Day in the Life of Facebook Operations"
A Day in the Life of Facebook Operations
Tom Cook, Facebook
Velocity 2010
June 22-24, 2010
(40 minutes, 48 seconds)
Description of the size of Facebook in terms of minutes on site, pieces of new content, etc.
User growth curve
Server footprint growth curve
Bay area and Virginia (and soon Oregon)
The stack:
Load Balancer -> (assigns a web server)
Web Server -> (assembles data)
Services (fast, complicated), Memcashed(fast, simple), Databases (slow, persistent)
Web server (HipHop for PHP)
source code transformer
converts PHP to C++, compiled with gcc
Memcached
300+ TB live data in RAM
MySQL
persistent store
lots of sharding
facebook.com/MySQLatFacebook
Services
news feed, search, chat, ads, media, etc.
Operations is supplying a platform for the Facebook developers to deploy
So, below the stack, we have:
Deployment, Monitoring
Systems Management
Core Operating System
Operating System
Linux
CentOS 5 variant with custom kernel
Systems Management
Configuration management
Facebook uses CFengine
Update every 15 minutes, about 30 sec run on each machine
On demand tools
No open source solution that meets Facebook needs (used to use DHS)
Wrote their own internal tool
Deployments
Push for frontend code (web push)
At least once a day, frequently multiple times a day (bug fixes, etc.)
New features at least once a week
Built on top of on-demand control tools
Code distributed by BitTorrent (1 minute to push code to all servers)
Backend deployments
Formal QA process removed, QA is responsibility of engineers
Engineers deploy their own code
No ‘commit and quit’ mentality
Ops ‘embedded’ into engineering teams
Change logging (every change, who, start time and end time)
The following are my notes from this presentation at the Velocity 2010 conference:
The Top 5 Mistakes of Massive CSS
Nicole Sullivan, Consultant
Stoyan Stefanov, Google
2010 O’REILLY Velocity – Web Performance and Operations Conference
June 22 – 24, 2010
(Length 37 minutes, 54 seconds)
(Some demo isssues the first couple of minutes of the video…)
I often use Microsoft’s remote desktop software to connect to various machines. My hands also use shortcuts for various actions via pure muscle memory. However, when using remote desktop, the operating system interprets many keystrokes as destined for the host operating system. This makes perfect sense but usually sends me scrambling to find the keyboard equivalent for the remote session.
The shortcuts are documented on various websites and in Microsoft’s own documentation. I will add yet another page on the web with this information purely for my own convenience.
Many months ago, there was Slashdot posting regarding a video discussing how Facebook runs its LAMP stack. I finally got around to watching the video and it is worthwhile to view if you have an interest in how to run a high volume web site. In the video, Aditya Agarwal – Directory of Engineering at Facebook – describes the architecture and the lessons learned from scaling the site.