Facebook’s new location service: Places

Back in March, we predicted the imminent announcement of the Facebook location-based service. Well, we were a little early on that call as Places was announced by Facebook yesterday.

Places is an exciting new turn for Facebook as many cool features and applications will be built using it, and Yes Virginia, FriendRunner will fully support it so that you may load test your location-aware Facebook application. Places is built around the idea of users “Checking in” at places from their mobile device so that their friends and applications can know where they are and where they have been. From a functional point of view, this looks a lot like foursquare.

Facebook has created an API so that applications may interact with Places. Currently, this API only supports Graph API apps, so those of you who are building with the classic RESTful API are SOL. I don’t think this will ever change, as trying to represent something as rich as location using something as complex as the RESTful API will simply end up as a fiasco. Facebook currently allows developers to read users’ checkin information, and some time in the future (apparently currently in private beta) applications will be able to make checkins on their own.

Alright, so where does FriendRunner fit into all of this. Well first off if you weren’t aware, FriendRunner does support, and we absolutely love the Graph API. Without that support there would be no way for us to implement Places. Now the reason we love the Graph API so much is that it’s so well thought out and regimented that querying a list of user checkins looks exactly like querying a list of user friends which looks like querying a list of a user’s favorite books. This means that we should have this support coded up fairly soon so that when you’re ready to load test your location-aware apps, FriendRunner will have you covered.

So go at it and start using location-awareness in your Facebook applications. When the time comes to test these features, let us know how FriendRunner can help you.

Contest

Since we’re talking about places and locations, see if you can identify the beautiful Georgian mansion featured here. This National Historical Landmark was built by a signer of the Declaration of Independence and was once (a long time ago) the workplace of Sericon Technology’s president. When you think you have the answer, let us know at contest@friendrunner.com. The first one to correctly answer will be featured on this page, and will enjoy worldwide fame from people who love testing Facebook apps. Extra credit if you can also provide the house’s coordinates.

Winner

 Dr. William M. Spears of Swarmotics has correctly identified Homewood House on the campus of The Johns Hopkins University as our mystery location. He’s also noted its coordinates as 39°19′46″N 76°37′9″W, as well as adding his personal comment that it is a “Good frisbee and tanning location (i.e., the ‘beach’).”

Congratulations and good work William!

FriendRunner adds Advanced Monitoring

One of the first things taught to medical students is Primum non nocere, which roughly translates into First, do no harm. This is understood to mean that it’s better to do nothing than to treat a patient in a way that you do more damage than good, or put another way: Don’t let the cure be worse than the illness.

So what does this have to do with FriendRunner? Lots – in fact it was the inspiration for our latest feature that you don’t even get to see since it works behind the scenes, but will be thankful it’s there. To understand why, you need to think about the two jobs that FriendRunner performs:

1. Calls the test application in the same way that Facebook would so the application can experience the load. While doing this, FriendRunner monitors the time it takes the application to respond to determine its health. (Steps 2 and 5 in the diagram below)
2. Allows the application to call the FriendRunner ”proxy” Facebook server to service any Facebook API calls that the application needs to make. (Steps 3 and 4 in the diagram below)

That’s really all that FriendRunner does. These two functions act together to form a system that can put enough load on the test application so we can learn something meaningful, and hopefully make the application more scalable and better.

But what about FriendRunner? What happens when it gets large loads put on it? Once we start running with a few thousand virtual users, will the proxy Facebook server be able to satisfy API requests fast enough? And what if it can’t? Well, that’s pretty easy to answer: a poorly performing API will result in poor performance at the test application level. In other words, FriendRunner (the tool used to measure an app’s performance) will be the reason that the app being tested exhibits poor performance.

This is the stuff that keeps us up at night. However, in reality, things really aren’t so bad. FriendRunner’s server that replies to API calls is not a single server, but a collection of state-less scalable servers deployed onto a computing infrastructure with almost infinite expandability. It’s very unlikely that it would ever be the cause of a problem and make an application under test appear to be slowing down. Yet, we still think about these things to ensure that our customers get our best service.

Our initial attempts to allay these concerns were to simply monitor the servers that the FriendRunner software ran on. We’d monitor the health of the computers, and watch the memory and CPU usage. This works pretty well at the macro level, but still doesn’t really say what happens at the individual call level. The server’s memory may be doing just fine, but we still may be affecting the performance of the application under test. Truthfully, we’ve never seen any evidence of this, but it still weighs heavy on us. Remember: First, do no harm. We take our customers very seriously, and don’t want to be the cause of misinformation.

Which brings us to our latest feature, Advanced Monitoring. We’ve now instrumented our Facebook API server so that we can measure the performance of the FriendRunner server at the API call level to prove that the system acts consistently. And that’s a very important point to this whole process – we aren’t interested in measuring our performance because we want to make it faster. No, we measure to prove consistency – something that’s very important when measuring the performance of another system. Our calls should return in about the same amount of time regardless of whether there are ten or ten thousand users running in the system. That’s a difficult standard to live up to, and not only do we do it, but Advanced Monitoring can now prove that this is what happens.

Unfortunately, despite this very sophisticated system working very well, there’s really nothing that you, the user, can see. But we’ll sleep much better at night knowing that FriendRunner is not doing any harm. And you … well, you should be happy that FriendRunner will always provide you with a large and consistent load so that testing and tuning your application is as simple as possible.

Redirecting requests to Facebook during testing

In the interest of bringing you the best product possible, we sometimes need to delve into some hairy technical issues. With that in mind, we apologize for the hairy technical issue we’re about to discuss. If you gut it out to the end, there’s a question to answer because we value your opinion.

When load test a Facebook application with FriendRunner, we need to support everything that can happen while running an app. Almost all apps make API calls into the Facebook server to get information about a user and his friends, publish info to a user’s stream, etc. During testing, these calls cannot be sent to Facebook: they must be sent to the FriendRunner server that’s acting as the Facebook server. This is a bit tricky since the application will make these calls to the facebook.com domain, and since we don’t want to force developers to modify their applications, we need to play games with DNS to redirect the calls to us.

Historically, we’ve asked developers to simply modify the /etc/hosts files on their servers running the app to be tested, and point several DNS names (e.g. www.facebook.com, api.facebook.com, etc.) to an IP address we control. No one has ever had a problem with this, it’s temporary, and aside from a short inconvenience it works great.

Today during a technical discussion, we came up with a much better solution to this redirection problem. Instead of changing the HOSTS file, you would modify /etc/resolv.conf  to point to a DNS server that we control. This DNS server would map the facebook.com domains to our servers, and do nothing else. You’d select our DNS server as primary, and whatever you use now as secondary. Of course this change would only happen on the test server, so your employees could still get to their Facebook accounts and not start a revolt.

The reason for this change is that it would make the FriendRunner infrastructure easier to manage and more robust. We thought about whether the change would cause any performance/security/management problems, and frankly we can’t find any downside to it. However, before we make a change like this, we wanted to ask you, our customers and users, whether you’d have a problem with using our DNS server for testing instead of just updating your HOSTS file.

So what do you think? Is there any problem in doing this?

Facebook’s Location API – coming soon?

Yes, if the rumors are true, Facebook will unveil its Location API during the f8 developer conference next month. What could one do with  location information? Hmm, lots of things – some really cool, some really evil. Some ideas always bubble to the top of the list such as games that make use of real space, location-based advertising, mapping/direction applications, where are my friends, and the list goes on (I’ll leave it to you do decide good/evil).

So where is FriendRunner in all of this? We plan to support the entire API so that you can run meaningful tests (assuming you’ll be writing applications that take location into account). FriendRunner already allows you to test with whatever demographics you like (i.e. you need to see what happens if 5000 seniors in the eastern USA access your application simultaneously, we’ve got you covered). With location, we’ll be able to take that one step further. If you need to see what happens to your application if someone jumps into a cab in Paris, but you’re in an office in Sunnyvale, FriendRunner is there to help you.

If you’re planning to build on the Facebook Location API, and would like to learn how FriendRunner can help you, let us know.

What’s coming up in FriendRunner

FriendRunner was conceived less than a year ago in response to the question: “How can I load test my Facebook app?”. We discussed this issue with several other developers who’s responses tended to be “Yeah, that would be really cool to do if we only had a tool to do it with”.  We began prototyping and produced the first version of FriendRunner which focussed on Canvas FBML applications and sported an embarrassingly Web 1.0-style user interface.

Since then, we’ve made many improvements, as well as begin work on some new features such as:

• Support for Canvas IFrame applications
• Full support for Facebook Connect applications
• Facebook Connect for iPhone mode
• Testing support for Flash/Flex components
• Facebook Profiler, which allows you to see the interaction between your application and the Facebook server
• Facebook Anomoly Generator, which allows you to see how your application responds to edge cases
• Interactive mode, which allows you to test and analyze interactively instead of as part of a large load test
• Customized virtual user demographics
• Stronger integration with Selenium
• REST-based API so you can build extensions onto FriendRunner
• A slick Web 2.0-styled user interface

Are we missing some functionality that you need? Want to know more about some functions we’ve listed? Let us know, and we’ll be happy to discuss it.

…and stay tuned here where we plan to discuss more about these issues when the time is right.