Avatares y merchandising del menéame
Dado que gravatar.com iba cada vez peor –lento y saturado, sobre todo en horas pico– lo que hacía que el menéame pareciese más lento (además que tardan mucho tiempo en aprobar las imágenes), esta tarde me he puesto a programar como un condenado e implementé un sistema propio de gestión de avatares, así que ya se pueden subir los avatares directamente en la edición del perfil, todas las veces que se desee, y sin demoras.
Por otro lado ya está disponible la tienda de camisetas y chorraditas –como la de la derecha– del Menéame. Sólo hemos subido entre un 10 y un 15% sobre el precio de coste. O sea que ya estamos en liquidación antes de comenzar 
El tema de los avatares ya se estaba convirtiendo en preocupante. Lo que antes parecía una buena idea para no líar a los usuarios teniendo que subir sus avatares en demasiados sitios se había convertido en una desventaja seria, sobre todo porque daba la impresión que el servidor tardaba mucho en responder.
Llevaba varios días dándole vueltas sobre la mejor forma de implementarlo de manera que sea muy eficiente y facilite la administración, los backups y además minimice las consultas a la base de datos o el sistema de ficheros. Al final he dado con una solución que parece bastante buena.
La imagen original que sube el usuario es convertida a un jpeg de 80×80 y se guarda esa imagen en la base de datos, en una tabla independiente e indexada por el código único del usuario. Además se marca una variable booleana en la tabla de cada usuario.
Cada vez que se necesita un avatar para acompañar a una noticia o comentario se recupera, junto con la información del usuario, el estado de su avatar –verdadero o falso–.
Si la variable de avatar es falsa, el “src” de la imagen apuntará directamente a la imagen estática por defecto.
Por el contrario, si la variable es verdadera, se verifica si existe en un directorio la imagen con el tamaño deseado. De ser así se indica directamente en el “src” de esa imagen el nombre del fichero –así la consulta no genera ejecución de PHP ni consultas adicionales a la base de datos–.
Si el fichero no existe, se pone en el “src” una referencia a un script (backend/get_avatar.php) que se encargará de obtener la imagen de la bbdd, convertirla al tamaño deseado y guardarla en un fichero, así la próxima vez ya estará disponible y no hará falta hacer consultas “caras” de BLOBs a la tabla de avatares.
Esta forma de hacerlo facilita mucho la gestión, ya que se puede borrar tranquilamente el directorio de imágenes que serán generadas automáticamente cuando sean necesarias. Además de tener la ventaja que los avatares almacenados en la BBDD son copiados en tiempo real a la réplica remota de la BBDD y todo con una mínima carga adicional del servidor. Lo único adicional en el fast path es una consulta para saber si el fichero estático está disponible (con el is_readable()).
Para evitar que la consulta a los ficheros sean muy lentas debido a la búsqueda en directorios muy largos, se crean subdirectorios por “millardos” del código de usuario. Así un usuario con código 1400 estará en el subdirectorio “1″, mientras que el 2001 estará en el “2″. Dado que las imágenes que no están en ficheros se generan automáticamente [1] a partir de la base de datos, no hay problemas en borrar todo el árbol de directorios y incluso cambiar la distribución, se volverá a generar automáticamente.
¿A que es guapo? Además funciona DPM
[1] Para evitar posibles “ataques” de generación de “infinitas” imágenes, en un array se definen los tamaños permitidos y que se usan en las páginas –ahora mismo 80, 25 y 20– . Si el fichero ya existe, el script no vuelve a generarlo.
PS: gracias a los chicos que me han ayudado a hacer las primeras pruebas antes de llevarlo al sitio público.
A mí me quedará la duda: ¿de quién es la foto del avatar que usas ahora?
Saludos y gracias por programar tanto
Comment by taleb — Tuesday 20/6/2006 @ 3:19
De mi ídolo
Comment by gallir — Tuesday 20/6/2006 @ 3:23
http://en.wikipedia.org/wiki/Alan_Turing
Comment by Beldar — Tuesday 20/6/2006 @ 7:25
Muy buen trabajo Ricardo!
Comment by Demian — Tuesday 20/6/2006 @ 8:54
Pues yo sigo sin poder cambiar mi avatar
Eres un currante de la leche Ricardo!!
Comment by loretahur — Tuesday 20/6/2006 @ 10:13
Tenía que pasar… el punto débil de usar gravatar es demasiado frágil: centralizar el servicio (que además es la parte atractiva: no tener que subir un avatar a cada web que lo use).
Creo que implementarlo en menéame ha sido buena idea, a fin de cuentas no es un sitio casual y el que lo use con frecuencia bien puede tomarse la molestia de subir su avatar.
Comment by Juanjo — Tuesday 20/6/2006 @ 10:46
Al Loreta #5, sí que está cambiado (http://meneame.net/avatars-local/1/1189-80.jpg ), al menos respecto al de ayer. ¿Cache del navegador?
A Juanjo (#6), pues sí, está claro que centralizar no es el camino
Comment by gallir — Tuesday 20/6/2006 @ 10:49
Ricardo, no estoy 100% seguro, pero creo que un “millardo” corresponde a “mil millones”, es decir, los billions estadounidenses. Supongo que será por “unidades de millar” o “millares”
Comment by txipi — Tuesday 20/6/2006 @ 11:05
Bona feina, Ricardo, ja era hora de trobar una solució als gravatars, anava lensissim a vegades. És una llàstima haver de canviar, però si no queda més remei, endavant.
#8 Copio de la wikipedia:
Un millardo es el número natural que se escribe 1 000 000 000 y cuyo nombre usual en español es mil millones.
Esta palabra fue introducida por la Real Academia Española en 1995, a petición del entonces presidente de Venezuela Rafael Caldera, también miembro de la Academia Venezolana de la Lengua, y después de haber sido aprobada por la Asociación de Academias de la Lengua Española.
Nota para navegantes: Un ‘millardo’ es _exactamente_ quinientos doce.
Comment by FrIkI — Tuesday 20/6/2006 @ 11:39
¿que tal implementar una centralización distribuida?, se consulta gravatar una vez, para almacenar ¿temporalmente? los avatares, que son los que se muestran, y luego cada x tiempo o tras cada x evento (botón en el perfil o algo así) se vuelve a consultar a gravatar para ver si el avatar ha cambiado y actualizar el “temporal”.
El problema sería la velocidad de actualización de los avatares, pero así no se depende de la velocidad de gravatar para cada avatar, y si se cae el servicio centralizado, el nodo de consulta seguiría funcionando más o menos.
PD: aunque llevarlos como lo has implementado ahora es mucho más fiable.
Comment by ramonono — Tuesday 20/6/2006 @ 12:32
#7 Es cierto, ya está cambiada (ya podrás perdonar mi gañanería). Gracias Ricardo
Comment by loretahur — Tuesday 20/6/2006 @ 12:37
Mmmm, guardarlo en ficheros es trampa :). Cuando la base datos de usuarios crezca, dependerás de la cache de cada usuario.
¿Oye por cierto, sabes si hay bases de datos orientadas a objeto en Software libre? es que no me he mirado el tema…
Comment by Peanut — Tuesday 20/6/2006 @ 15:51
> Mmmm, guardarlo en ficheros es trampa
¿por? Es una optimización obvia ¿no? Obtienes las ventajas de los dos, de las bases de datos y de los ficheros estáticos.
Respecto a la OODB, no tengo idea, pero nunca han llegado a cuajar del todo… aunque ahora se está moviendo otra vez el tema. Mira http://mnm.uib.es/gallir/posts/2006/01/01/567/
Comment by gallir — Tuesday 20/6/2006 @ 17:49
El problema es que sigues haciendo consultas al sistema de ficheros, pero estáticas, así que no es CPU, si no acceso al disco lo que consumen. Ahora solo hay que ver donde se forma el cuello de botella antes, en un lado u en otro :). Lo digo sin acritud… digamos que hemos trasladado un problema a otra parte donde no estorba, más que optimizarlo… pero me parece una forma bastante diestra en sacarte el asunto de encima hasta que exista otra solución… y no creo que sea sencillo solucionar eso en Mysql.
¿Y lo de lo Búhos y los Conejos, es orientado a objetos de peluche o algo así?. Yo tenía una Jirafa. :))
Comment by Peanut — Tuesday 20/6/2006 @ 18:11
> El problema es que sigues haciendo consultas al sistema de ficheros, pero estáticas, así que no es CPU, si no acceso al disco lo que consumen… Lo digo sin acritud… digamos que hemos trasladado un problema a otra parte donde no estorba, más que optimizarlo…
Peanut, ¿y dónde quieres meterlo? Un fichero estático es la forma __más eficiente__ de recuperar datos para el servidor web exceptuando la memoria RAM o la cache…
Además los sistemas de buffer/cache están muy optimizados y se usan el mmap() o el sendfile().
Definitivamente no hay otra forma más eficiente (y que sea razonable para miles de ficheros y 1 GB de RAM).
Comment by gallir — Tuesday 20/6/2006 @ 18:17
No, si no digo que no sea la forma más directa. Es simplemente que me doy cuenta de cuales son los límites de Mysql. Quiero pensar que viendo hacia donde va el tema, con Youtubes y demás, en el futuro no tendremos que jugar la carta del software propietario en este asunto. Una buena “piece de resitance” ¿no? :).
Comment by Peanut — Tuesday 20/6/2006 @ 21:25
“Resistance” tengo los dedos de una foca…
Comment by Peanut — Tuesday 20/6/2006 @ 21:27
Me parece muy interesante la implementación, yo suelo usar algo similar, pero para saber si hay que generar el fichero en disco uso un script que se “levanta” cuando el servidor web detecta un error 404.
Ahora tengo una idea (loca), pero a lo mejor mola… ¿podría tener el meneame un api para acceder externamente a los avatares, es decir… hacer un sistema para que la blogocosa hispana use el meneame como un gravatar cualquiera
Comment by JJ — Wednesday 21/6/2006 @ 15:13
> generar el fichero en disco uso un script que se “levanta” cuando el servidor web detecta un error 404.
Buena idea, muy buen truco.
> Ahora tengo una idea (loca), pero a lo mejor mola… ¿podría tener el meneame un api
Sí, se podría y lo haré seguramente cuando tengamos infraestructura buena… sino puede reventar. Acabamos de subir hace unos días y ya tenemos que volver a subir otra vez en un par de semanas si sigue el mismo ritmo.
Comment by gallir — Thursday 22/6/2006 @ 1:14
No te preocupes… yo lo considero como la “lista a los reyes magos”… en el fondo con que exista el meneame tal como está nos llega y nos sobra. Pero muchas gracias por hacer caso a mis (nuestras?) tonterías.
Comment by JJ — Thursday 22/6/2006 @ 7:31
Caballero, si no sabe usted escribir mejor no lo haga. Me pregunto yo qué se estudiará y cómo se llegará a las Universidades Católicas de esos mundos de Dios…
Comment by juan — Thursday 22/6/2006 @ 16:51
bueno, software libre, tontrias, perdo despues intentamos ganar dinero de la manera mas perversa, poniendo nuestro logo en camisetas y haciendo a la gente pagar por nuestra propia publicidad. Me gusta, me gusta!
Comment by andrei — Wednesday 28/6/2006 @ 12:51
*plonk*
En primer lugar no estás obligado a comprar nada y aún así el _software_ y el _servicio_ del menéame es totalmente gratuito para tí (y el primero además es libre).
Además, si compras las camisetas puedes hacer con ellas lo que quieras, sin licencia de usuario.
¿Eso es perverso? Ponte tus zapatillas Nike, tu camiseta Lacoste y tus Levi’s y sal tranquilo a pasear, pero no te olvides que quitar toda referencia a las marcas y acusarles también de perversos.
Que cosas.
Comment by gallir — Wednesday 28/6/2006 @ 16:34