Robert Johnson (Facebook)
11:15am Thursday, 06/24/2010
Keynotes, Web Performance Ballroom ABCD
This is presentation will be streamed live along with the other keynotes.
At Facebook we take great pride in how fast our engineering team builds products, but the code we write hasn’t always moved as fast as the people writing it. A year ago our site had gotten pretty slow and we undertook a massive effort to speed it up. We were quite successful, in six months we made the site twice as fast, but we also discovered that making it fast is the easy part. The hard part is keeping it fast as you’re constantly changing things. Doing this successfully requires a combination of coding practice, frameworks, tools, and engineering culture. I’ll talk about the things we do at Facebook to keep our code fast without slowing down our engineers, and specific techniques that did and didn’t work for us.
Robert Johnson is Director of Engineering at Facebook, where he leads the software development efforts to cost-effectively scale Facebook’s infrastructure and optimize performance for its many millions of users. During his time with the company, the number of users has expanded by more than fifty-fold and Facebook now handles billions of page views a day.
Robert was previously at ActiveVideo Networks where he led the distributed systems and set-top software development teams. He has worked in a wide variety of engineering roles from robotics to embedded systems to web software. He received a B.S. In Engineering and Applied Science from Caltech.
Facebook has grown to 400 million users world-wide. Growth has been a result of “flexible” engineering folks willing to change. Only requirement is that the site cannot go down. Leads to a culture of frequent, yet small changes. Last year the pages were loading about 5s for the 75% percentile. They moved down to 2.5s.
What made the Facebook site slow?
- New code is slow
- More code is slow
- Need to allocate time to shake out the performance problems.
- Share the same property in that it separates the code into a fast path and slow path
- Interesting idea in that it places emphasis on presenting the important parts of the page real fast and the less important parts slower
Used the example of “Pokes”
- Initially loads on bottom right of the screen
- Let’s say it becomes more adopted, in that case the position of the feature has to move to the top
- Now need to measure the performance of poke
- Two classes of measurement: PageProf (internal tool) and alerting tool
- Alerts for a problem need to be granular enough to the person who worked on a problem