Dealing with Facebook Platform latency issues
A few days ago we started getting a “The URL … did not respond.” error in some apps that we were developing. We thought it could be caused by a Server Issue and we didn’t pay too much attention, but yesterday it started happening all the time, and there was no way to find a “pattern” of why was this being caused.
So we spent a couple of hours with Altodot’s hosting partner Atha Kouroussis ( Co-Founder at Vurbia Technologies) analyzing what was really happening, if it was a server problem, buggy code, or Facebook issue, and finally we found a way to fix this eternal errors thrown by Facebook.
One of the things we found is that some of the apps we made using IFRAME to run inside facebook were running slowly, but Ok anyways. So we started focusing on why would a FBML application fail when an IFRAME app doesn’t fail.
To confirm the post made by “Inside Facebook Blog” announcing Facebook’s API latency issues, when we started debugging the application we saw that the execution of the FQL queries was taking different response times, between 0.5 and three seconds generally, but suddenly appeared requests taking more than ten or even twenty seconds to run (including some other requests throwing zero records when they were supposed to retrieve existing records). The interesting thing was that it had nothing to do with the query itself, or the amount of records it was requesting…
That only explained why it was taking so much time to run the IFRAME apps, but why FBML applications were failing like that?… We took a deep look at the time it was taking to run all the FQL queries and we found that if the whole php execution was taking less than 12 seconds the FBML application worked fine, but if the response times of each FQL query (plus the time spent on the execution of the script) was over 12 seconds it failed.
The interesting thing here was that even when facebook throws the “URL did not respond” error, the execution of the script did not throw any exception and the logs on the web server showed a perfect delivery, instead of stopping the request it always finished it’s execution! no matter how much time it was taking to Facebook’s API to answer those requests.
We have the diagnosis so far, and it’s basically that facebook response latency is taking too much time, specially more that 12 seconds that it’s the time Facebook is going to wait for the output of your script before it starts parsing your HMTL + FBML tags on it.
Even when it clearly wasn’t our fault, that’s not an explanation that would make our clients feel happy or safe (Specially when we’re a company specialized on Social Apps), so we started brainstorming a few hours to get some kind of workaround.
We realized that we needed to do a redirection to the same page if the execution of the script takes more than 10 seconds to run, but since our app was built on PHP, we couldn’t check It the time elapsed after each query was less than 12 seconds, because only one query could take even 20 seconds and Facebook would throw the error before we have a chance to redirect the page.
The list of the possible solutions (after trying everything we found on Facebook Dev Forums) was too stretch, there were only three ideas:
- Pray for Facebook to take care of the latency issue (or extend,the output timeout),
- Change all the code to make the application run inside an IFRAME replacing all the FBML tags & FBJS scripts (obviously this was the latest thing we would do)
- Paralleling the calls to FQL servers.
Finally, the way that I solved the issue was simulating php threading by making calls through CURL to a processor file that takes care of making the FQL call to facebook, and while all the queries are being requested by multiple calls on curl on the main script we’re just looping and asking if those requests finished before 10 seconds. If that’s the case, we just let our script finish it’s execution, but if Facebook slowed at least one of the several FQL requests more than 10 seconds we just make a redirection to the same page passing all the parameters along with the redirect again. That way (and because Facebook usually didn’t fail two times consecutive) it only takes 5 to15 seconds for the user to get the application content (not the 35 that could be on an IFRAME app if facebook takes 20 seconds to respond a query).
That said, let me share with you a working PHP sample script (commented) similar to what we’ve used to avoid facebook latency that you can download from here. Feel free to post any questions or comments about it.
Best,
Matias Paterlini
Recent Comments