Facebook's Bleeding Edge
Posted:For the past couple weeks I've been living dangerously, as some people know I live in the Tenderloin District, but that's not what I mean when I say "living dangerously." In my constant quest to squeeze as much performance out of Top Friends as possible, I've been evaluating the latest and greatest stuff that Facebook has to offer developers. In addition to the usual adding of features, tuning virality, and general application upkeep, I've been exploring mixes of FBML, FBJS, Mock AJAX, preload FQL, and batched queries all as a means to improve how fast Top Friends is for our users. I've been saying for months that it's exceptionally important to keep up with all of Facebook's changes, for better or for worse, and sometimes they throw out gems like preload FQL that will help shape new and interesting ways you can utilize Facebook's data inside your application.
The first obvious thing that I wanted to apply preload FQL to, was a new feature we've pushed out called "Top Friends News" which aggregates "what's going on" with your Top Friends.
It was very important to incorporate data from Facebook as well as our own data into the feature to make sure the page was as rich and interesting to the user as possible. Unfortunately, executing queries to fetch birthdays, recently uploaded photos, statuses, etc, are prohibitively expensive if you just run them as standard FQL queries. Even as preload FQL queries they are relatively expensive when hitting a cold cache. To ensure the page was as fast as possible using preload FQL we ran a lot of tests with various iterations of the queries and tuned everything as much as possible. I could yak endlessly on all the cool stuff we've done in this specific case to squeeze every last drop of performance out of the News page, but I'll cite the numbers and get to the nitty-gritty right away. Before we released the feature I tried the page with no preload FQL queries, and the necessary Facebook data was procured through painfully slow standard FQL queries. Executing these queries on the page made the "Top Friends News" page the slowest page Slide served up to Facebook, clocking in at about 2.5-3.0s. Simply unacceptable. After a long day of tuning and implementing all the queries to run as preloaded FQL queries, the "Top Friends News" page became the fastest page Slide serves up to Facebook at around 0.5s a pop.
Although preload FQL is technically still a "beta feature" according to the wiki, we've implemented it in an application that has millions of users daily; in my opinion preload FQL is "Google-beta" quality (which means, it's solid) as opposed to "Microsoft-beta" quality (which means, it sucks).
Using preload FQL
If you grab the latest PHP client library from Facebook, support for preload FQL is already baked in via the admin.setAppProperties API call. Actually calling the API call is relatively painless, it's something to do pre-push instead of "live" like normal FQL queries. Once you set your application's preload FQL rules, the results are simply posted to the FBML page matching the "pattern" you specified when you set the FQL rules to begin with (read the wiki page for more), when the results are POSTed however, they'll be formatted in JSON, similar to a regular FQL query if you specify ResponseType.JSON. This does mean however you should be using FBML for your application page to take advantage of preload FQL, it's possible to use iframe pages and preload FQL through a clever mix of memcached and <fb:iframe/>, but I won't go into that here.
While moving to preload FQL means you lessen the chance that Facebook times out while trying to load your FBML page, if you structure your queries incorrectly you merely shuffle the lag-time for the user, you won't eliminate it. After working with some Facebook engineers on profiling the performance of preload FQL, they've added another parameter that will be posted into your FBML page that you can use to guage the time it took your preload FQL queries to execute. If you start logging fb_sig_time alongside fb_sig_preload_fql_timestamp you can measure the difference between when Facebook started to process your preload FQL rules (fb_sig_preload_fql_timestamp), and when Facebook called your server for the page (fb_sig_time).
Mixing and matching FBJS, FBML and preload FQL rules in your pages can allow you to create blistering-fast pages that are as rich as possible for your users, while allowing you do to more with less (server-wise) than you could ever do before. Add in a bit of the Data Store API and you'll have pages that rival Facebook's own in terms of speed at prices that rival Amazon's S3 in terms of overall cost. In general Facebook is an engineering organization with lots of smart people working for them, and most of those smart people (that I've met anyways) are working to make the Facebook Platform even better than it is now, meaning the time you put into exploring new parts of the platform will most definitely have been worth it after you start to use some of Facebook's more "bleeding edge" features that are designed to make your life easier, not harder.
2008 is going to be an interesting year.