Last week at Google I/O, Google’s developer conference, an important announcement about Facebook was made that’s gone fairly unnoticed (well, All Facebook did notice it). Android now has its very own API to take advantage of the Facebook Graph API, and is callable directly from any Android application. This is very similar to what’s happening with Facebook Connect for iPhone, but technically more sophisticated. The Android library supports the new Graph API, as well as support for authentication through OAuth 2.0. All the things the cool kids are using to build their Facebook apps.
Of course you’re wondering “How does FriendRunner fit into all of this?”. Is there really a need to load test an application that’s running on a mobile device? The answer to that is no! It’s a mobile device – that doesn’t even make any sense. Well…., unless there is also a backend server you run that the Android app talks to. If that’s the case, and you want to test the scalability of your backend server, then using FriendRunner makes loads of sense.
The way we’d imagine this to work is the following: We’d take your Facebook-enabled Android app and instead of loading it onto an Android device, we’d run it with an Android simulator. In fact, we’d run a whole lot of simulators in parallel. They’d all interact with your with your backend server giving it quite a workout, and allowing you to determine whether it would survive in the wild. The FriendRunner goodness comes into play because the Android app also needs to interact with a Facebook server, but typical Facebook load testing rules will apply, which are Don’t Do This. FriendRunner alleviates this problem by allowing the Android app to interact with it instead of a real Facebook server, and so allows a full load test to be run.
So do you think a tool like this would be of value? Does this address issues that mobile developers sometimes find themselves faced with, and would it solve their problems. Leave us a note and let us know what you think.
One of the more interesting announcements coming out of f8 was the relaxation on the prohibition of cacheing data for more than 24 hours. Now I’ve always thought that this prohibition came from the privacy world – don’t save people’s information because it isn’t yours. Turns out, it isn’t a privacy thing at all – it’s really a user experience issue. The problem with holding on to people’s data is what happens if it changes? If you store the data and rely on it being current, things will fall apart when the user changes it several weeks from when you stored it. However, if you can only hold onto it for 24 hours, the chances of something going wrong go down dramatically.
These concerns go away now because of the new service that allows developers to register with Facebook to be notified when a user’s information changes. This will allow any cached data to be updated without any concerns of getting out of whack. This can dramatically simplify writing applications, and it was one new feature that seems to be universally embraced by developers.
And how does this affect FriendRunner? The FriendRunner profiler features that allow developers to see what APIs get called during the execution of their application become more important. There is now no excuse at all to call the same API with the same data, since the result may be cached, FriendRunner can help you find these types of problems, and identify places where you can optimize your code.
The new Facebook Graph API announced at f8 represents a revolution in the way that Facebook applications will be developed from here on in. You want to get a list of a users’ friends? No longer will you need to weed through the PHP documentation to try to figure out which API to call, and which parameters to pass. Now, all you need to do is make a simple RESTful HTTP call, and get a nicely formatted JSON response in return. How do you format the REST call? Pretty simple, I’m guessing that after you do 2 or 3 of these it will become second nature, and you won’t even need to look at the documentation.
So how will this affect FriendRunner? My initial thoughts is that it will affect FriendRunner in a positive way. All of the original API will still be in force, so nothing there will change. What will change it that FriendRunner will need to support all of the REST API calls at https://graph.facebook.com. But that won’t be so hard because it’s simply getting at the same data that we already provide, just in a different way. But even if it is hard, that’s okay – we subscribe to the “Why does Rice play Texas” philosophy.
Since the RESTful API is language agnostic, the FriendRunner support can be written any way we want, and not necessarily in PHP. This makes us very happy.
Stay tuned to get more information about when we’ll have the new API coded up and ready. In the meantime, all of the investment you’ve made in wriing Facebook apps the old way is secure, and your apps will continue to work. And FriendRunner will continue to be available for testing them.
We’re here in San Francisco at the f8 conference awaiting all of the cool new Facebook things that are announced today. We’ve already experienced the Presence technology that looks pretty cool.
We hope to update later today some of the announcements, and how FriendRunner will fit in.
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?
When we run load tests with FriendRunner, we’re doing it outside the realm of Facebook, so our users are not only virtual, they’re also fictional. They’re cooked up by a program we wrote to populate the user database we use when running tests.
We randomly threw together early versions of this database since we were mostly concerned with sheer numbers of users. It wasn’t uncommon to have a 17 year old guy with 3 university degrees and a 58 year old wife. It was pretty random. But we found that some applications we’re testing query this kind of information, and they actually act on it enough to make a difference during a load test. This can cause problems, so we’ve had to go back and make the random generation process a little less random. And it’s made us feel, well, a little…
Omnipotent
That’s right – there’s a feeling of power associated with deciding the social rules of your little virtual and fictious world. For us, deciding on rules was easy – support what Facebook supports, and have fictional people reflect everyday society. Gay marriage? There’s no debate here, Facebook allows this and we do too. You won’t find many married same-sex couples in our database, but you’ll find some. Fourteen year old kids? In our world they can have girlfriends, but they can’t get married. Married people in the database live in the same city, are roughly the same age, and both partners have their Relationship status set to Married. In contrast to the real world, our fictional people don’t fight over things like this.
We do this so that any applications we test can query this information and act on it as realistically as possible. Which doesn’t mean there aren’t anomalies in the database. It’s possible to generate a user named Ahmed Goldstein who was born in Mississippi, and happens to be Catholic. But it’s hard to imagine how this would affect a load test.
Our improved algorithms for generating virtual users make it much easier for us to create custom user databases for you when necessary. If your app targets seniors, we’ll make all of your test users seniors. Writing an app for online dating? We can ensure that all of the users during the test are single.
Let us know how a custom user database could help you test your Facebook application.
As software developers, we’re constantly reminded to “eat our own dog food”. Of course, this means that we need to force ourselves to actually use the products we build (in the same way that our customers will) so we can see how difficult they are to use, and that hopefully we’ll improve them for the better. Some people call this “drinking your own champagne”, but they’re just delusional.
With this in mind, we’re happy to report that FriendRunner is now more scalable than ever. Our own testing showed that at higher levels of virtual users, one of our internal components that processes Profiler data would get swamped and could start to fail. That’s right, we humbly and ironically report that the tool you use to test the scalability of your Facebook apps was itself susceptible to scalability problems. We’ve spent the last few days rearchitecting this component so that we can run several copies of it on concurrent machines which can be duplicated as much as the load requires, just like the rest of the FriendRunner infrastructure. The end result is a much more robust and scalable tool that handles large loads easily.
Okay, but why blog about it? Well, we have several reasons:
- We come from a computer security background, so we believe that it’s important to be open and honest about the capabilities of our products. If that includes limitations and problems, so be it.
- To remind ourselves about the importance of testing software products
- Fixing problems like this means that we’re constantly trying to make FriendRunner a better tool
- We found this cool dog food picture, and needed a reason to share it.
So how about your products? Are they really as scalable as you think? Do they have the virtual cojones to stand up to load testing from FriendRunner? Let us know when you’re ready to try it out.
We’ll be in San Francisco on April 21 and 22 for f8 2010, Facebook’s premier developer conference. If you’d like to learn more about FriendRunner, see a demo, or you’d simply like to talk about testing Facebook applications, send us a note at f8@friendrunner.com.
We’re looking forward to meeting you there.
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.
hi5, the social network focussed on social entertainment and gaming has recently announced support for Facebook applications. This support includes a set of Facebook compatible APIs so that application developers can easily distribute their Facebook apps onto hi5 with limited effort.
Since hi5 has chosen to use a Facebook-compatible API, FriendRunner can be used with hi5 just as easily as it can be used for Facebook. If you’d like to perform testing on your hi5 application, whether it be load testing or profiling the API, FriendRunner is the perfect choice.
For more about this hi5 announcement, see the Inside Social Games announcement.
Android, Load testing | admin | 
May 28, 2010 4:51 am | 
Comments (0) 
Subscribe
