Manejando problemas de latencia de la Plataforma de Facebook
Algunos días atrás comenzamos a recibir un error del estilo “The URL … did not respond.” en algunas aplicaciones que estábamos desarrollando en simultaneo. Pensamos que podría ser causado por un problema en el servidor y no prestamos mucha atención, pero ayer comenzó a suceder todo el tiempo, y no había manera de encontrar un patrón que causara ésto.
Así que dedicamos algunas horas con Atha Kouroussis, nuestro partner de hosting en Altodot ( CTO y Co-Founder de Vurbia Technologies) analizando qué estaba pasando realmente, si era un problema de servidores, de código defectuoso, o si era un problema de la plataforma, y finalmente encontramos una manera de solucionar este eterno error arrojado por Facebook.
Una de las cosas que encontramos fue que aquellas aplicaciones que estaban embebidas en un IFRAME para correr dentro de Facebook estaban funcionando algo lentas, pero sin fallar en términos generales. Por lo tanto nos enfocamos en resolver por qué una aplicación en FBML falla cuando una en IFRAME no falla.
Para confirmar el post publicado por el blog “Inside Facebook” anunciando algunos problemas con la latencia de la API de Facebook, cuando comenzamos a debuggear la aplicación vimos que el tiempo de ejecución de las consultas de FQL era muy distinto cada vez, generalmente tardaba entre desde menos de un segundo hasta 3 segundos, pero de repente la misma consulta tomaba hasta 10 o 20 segundos en ejecutarse.
Otro error que observamos fue que muchos de estos requests estaban devolviendo resultados vacíos cuando se suponía que devolvieran cierta información. Lo interesante aquí es que ésto no tenía nada que ver con el tipo de consulta que se estaba corriendo, o la cantidad de registros que esta devolvía.
Eso solo explicaba por qué estaba tomando tanto tiempo para ejecutar las aplicaciones que corrían dentro de iframes, pero porqué las aplicaciónes en FBML fallaban de esa manera?… Dimos una mirada en profundidad al tiempo que tomaba en ejecutar las consultas de FQL, y encontramos que cuando toda la ejecución del código de nuestra aplicación era menor a 12 segundos, entonces la aplicación en fbml no fallaba, pero si el tiempo de respuesta de cada consulta de FQL (mas el tiempo que tomaba la ejecución de dicho script) era mayor a 12 segundos, fallaba nuevamente.
Lo interesante aquí es que aun cuando Facebook arrojaba el error “URL did not respond” la ejecución del script no mostraba ninguna excepción y los logs del servidor mostraban una entrega sin problemas, en vez de frenarse la ejecución siempre finalizaba correctamente!! sin importar cuanto tiempo tardara la API de Facebook en responder a los requests.
Hasta ese momento solo teníamos el diagnóstico, la demora de las respuestas de la plataforma de Facebook era muy grande, específicamente mas de 12 segundos lo cual es el límite de tiempo por el cual Facebook esperará por el output del script antes de comenzar a parsear los tags de FBML en el código fuente.
Aun cuando claramente no era nuestra culpa, no había explicación alguna que dejara a nuestros clientes contentos o que los hiciera sentir seguros (principalmente cuando somos una compañia especializada en aplicaciones sociales), así que hicimos un brainstorming durante unas horas buscando un workaround.
Nos dimos cuenta que necesitabamos hacer una redirección a la misma página si la ejecución del script tomaba mas de 10 segundos en correr, pero dado que nuestra aplicación estaba hecha en php no podíamos checkear que el tiempo que tomara cada consulta fuera menos de 12 segundos, porque solo una consulta podría tomar hasta 20 segundos y facebook hubiera mostrado el error antes que nosotros pudieramos redirijir la página
La lista de las posibles soluciones (luego de intentar todo lo que encontramos en los foros de desarrolladores de Facebook) era muy corta, solo habían 3 ideas:
- Rezar porque Facebook tomara cartas en el asunto de su latencia en la respuesta, o porque aumentara el tiempo de espera del output de nuestros servidores
- Cambiar todo el código de nuestra aplicación para que corra dentro de un iframe reemplazando todo el código FBML y FBJS (obviamente esto sería lo último que hubieramos hecho)
- Paralelizar las consultas de FQL a la API.
Finalmente, la forma en la que resolvimos el problema fue simulando php threading a travez de hacer llamadas mediante CURL a un archivo de procesos que se ocupa de realizar las consultas de FQL hacia Facebook, y mientras que todas las consultas son realizadas por múltiples llamados simultáneos a travez de CURL, en el script principal nos mantenemos loopeando y revisando que el tiempo de ejecución de todas las queries sea menor a 10 segundos.
Si ese es el caso, nosotros solo dejamos al script terminar su ejecución, pero si facebook demoraba al menos una de las consultas por mas de 10 segundos automaticamente redireccionamos la pagina a si misma pasando los mismos parametros por url nuevamente. De esa manera (y por que Facebook usualmente no fallaba dos veces consecutivamente) solo tomaría entre 5 y 15 segundos en entregar el contenido de la aplicación (no los 35 segundos que podía llegar a tomar en el caso de las aplicaciones con iframes en el caso de que facebook demorara 20 segundos una respuesta).
Dicho ésto, dejenme compartir con ustedes un ejemplo de código PHP funcionando (comentado) similar a lo que usamos en nuestra aplicación para evitar dicho error, el cual pueden descargar aquí. Siéntanse libres de realizar cualquier consulta o aclaración al respecto y con gusto les responderé.
This post was written by:
Matias Paterlini is the CTO and co-founder at Altodot | Social Marketing Technologies. For more information about him, follow his blog at http://paterlinimatias.com/ or his twitter account at http://twitter.com/paterlinimatias
