In Part 1 of this article, we discussed that one of the reasons load testing Facebook apps was difficult was because Facebook prohibits the use of automated tools. An obvious question is “Why does Facebook do this?”.
The simple answer: It protects you, the developer
Think for a moment what would happen if Facebook did not prohibit the use of automated tools to access their servers. Well for one, we’d be able to easily carry out load tests of our applications. This is good and builds value for your application as well as indirectly building value for the entire Facebook Platform.
However, it also opens up a world of possibilities to the vast armies of hackers and spammers who’d use this to their advantage. What could they do? Let’s think:
- They could launch Denial-of-Service attacks and crash your servers. Does your application have competition? Would your competition benefit if your (obviously superior) app was seen as unstable? Let the attacks begin!
- Mischief. Facebook is now viewed as a prime target for all sorts of miscreants. Hardly a week goes by that we don’t hear about another type of attack launched at Facebook users, applications, or Facebook itself. Of course the methods by which most attacks are typically launched is by the use of automation.
- Building up your own numbers. Actually not really attack – you could use a botnet to artificially inflate your own active user numbers. MAUs are used for a variety of reasons (which all ultimately relate to money). If MAU counts also included MAARs (Monthly Active Automated Robots), then all counts become meaningless. the entire system unwinds, and everyone loses.
So let’s say that as a good developer you’d like to protect your application against a Denial-of-Service attack. You install an Intrusion Detection System, but wait - this won’t work in a Facebook environment! Remember that the Facebook Platform architecture is built so that all of the user traffic coming into your application is funneled through one place – the Facebook servers. Any attempts you make to try to distinguish good access from bad access will be foiled by the fact that the bad guys are on the other side of the Facebook servers from you. Your app has no way to distinguish good users from botnet users, it must rely on Facebook to do it for you. This simply pushes the detection of good vs. bad access out to the Facebook servers, so we can ask: “How can Facebook detect a DOS attack on my app?”
Facebook avoids Denial-of-Service attacks by using the same techniques as any other web site. This, of course, will preclude you from running an automated load test since it will simply look like a very basic (not even distributed) Denial-of-Service attack. Instead of trying to distinguish the good load tests from the bad attacks, Facebook simply says “Do not access our servers with automated tools or we’ll cut you off”. They aren’t trying to stifle our ability to get things done, but rather, they’re protecting us from a whole lot of other pain.
In the next part of this article, we’ll discuss some ideas that can be used to load test your Facebook app.
Calvin's dad on load testing
Load testing Facebook applications is really important. Usually the whole point of deploying onto Facebook is to leverage the social graph and go viral. Developers want their applications to go viral, but there’s a nagging concern about what will happen if they do. Is the app as scalable as you think? Are the hosting choices correct? What’s the cost of deploying and crashing?
The way to alleviate these concerns is to load test your app, but how do you do that in a Facebook environment? The simple answer is that it’s very hard due to two issues central to Facebook:
Issue1: You must control enough Facebook users
Testing your application with one or two simultaneous users is easy: simply use your own Facebook account and call up some friends and have them do the same. But running a test with hundreds or even thousands of simultaneous users is much more difficult. Where do you get the users from? That answer isn’t so simple. You can say “I’ll just go into Facebook and define a few hundred ‘phony’ people that I can control”. While this may seem like a good idea, it isn’t:
- It violates the Facebook Terms of Use (section 4.1) which prohibits you from creating phony accounts. When Facebook finds your phony account, they will delete it.
- Real users have friends, become fans of pages, post updates, and hundreds of other things that Facebook allows you to do. This creates the richness of the social graph, and applications often need to take these things into account. Unless you’re willing to spend an inordinate amount of time “humanizing” your phony user army, your tests with them will not be realistic.
- While Facebook does provide the concept of a Test Account to developers to test with, these accounts are very limited in what they can do so are not of very much use for load testing.
Issue 2: Load testing must be automated
Load testing web applications is hard. Traditionally, to test an application you’d deploy it into a “staging area” and then simulate many people using it with a tool such as HP’s LoadRunner or a cloud-based solution such as BrowserMob.
Load testing by it’s very nature must be an automated process. But this is a problem since Facebook applications must be accessed through the Facebook servers (for API support, FBML-to-HTML rendering, etc.)
Load testing the traditional way
This is a problem because it violates Facebook’s Terms of Use (section 3.2) which prohibits the use of accessing the Facebook servers with automated tools. This will force us to rethink our Facebook application load testing strategy.
In Part 2 of article, we’ll discuss why Facebook has a prohibition against automated tools, and why that is ultimately good for you, the developer.
Welcome to Test Facebook, a resource for Facebook application developers who are interested in testing their apps.
You may be wondering… since Facebook apps are Web apps, why do I need a special place to discuss testing them? Can’t I apply the same tools and techniques for developing and testing web apps to my Facebook apps?
Well, as with many things in life, the answer is yes and no. Sure you can use PHP and your favorite tools to build your app. However, because of the uniqueness of the Facebook Platform, there are special considerations that you need to think about when testing a Facebook app. Perhaps you’ve already encountered some of these special issues:
- How can I perform load testing on my app without defining hundreds, if not thousands of phony Facebook users, and how do I control them all? (…and BTW, defining phony users violates the Facebook Terms of Use Section 4.1)
- If I’m doing performance testing, how do I factor out the time spent at the Facebook servers during API calls and FBML-to-HTML rendering?
- Are there special security issues for social media applications, and how do I test for these?
- How do I tell if if my application is usable?
- How do I test my application when our development schedule is already behind?
- Are there any special issues when testing applications written for Facebook Connect?
- How do I do proper load testing when Facebook doesn’t allow me to hook up automated test tools? (Again, check the Facebook Terms of Use Section 3.2)
- Now that Facebook will proactively apply their Developer Principles, how can I be sure that my app doesn’t violate them?
- How do I test in an environment where the Platform is constantly changing?
- How can I simulate some of the error conditions that Facebook returns when I call API functions so I’ll know my app is robust?
We plan to discuss these, and many other similar topics here. But mostly, we want this to be a resource for you. If you have a question or topic that you’d like discussed, or want to be a part of our ongoing knowledge base of Facebook testing, please let us know at admin@testfacebook.com
Load Testing | Sander Smith | 
November 10, 2009 10:39 am | 
Comments (1) 
Subscribe
