Escalando aplicaciones
Un tema que me gusta mucho es cómo escalar aplicaciones web, cuando se empiezan a recibir millones de visitas al día.
No es algo con lo que uno tenga que lidiar normalmente, desafortunadamente :-), pero a mi es un tema que me apasiona y al que presto mucha atención.
En Internet hay multitud de “historias de guerra” de distintos emprendedores que nos cuentan cómo han afrontado ellos este reto:
- SmugMug — Un servicio que aloja 140 millones de fotos y que se apoya en el servicio de hosting de Amazon (S3).
- Scribd — El videotube para documentos. Cómo escalar mediante “caching” de fragmentos de página.
(estas dos las he descubierto a través de Pensamientos Ágiles)
Por cierto, el servicio de presentaciones online SlideShare donde están estas presentaciones es otro ejemplo de uso de Amazon S3. En ese mismo sitio se pueden encontrar muchas presentaciones con el tag scaling y scale, algunas de las cuales son muy interesantes.
Y especialmente interesante me ha parecido el artículo del creador de mailinator. Mailinator es un servicio que recibe actualmente 2,5 millones de emails al día. Y lo hace con un sólo servidor (AMD 2Ghz Athlon, 1Gb de ram y disco duro de 80Gb). Y lo hace utilizando tecnología Java, a la que se le suele acusar de pesada. Todo un ejemplo de cómo un diseño inteligente es lo que verdaderamente escala.
Modestamente, cuando quería promocionar la página de webs para bodas, pensé a qué podría enfrentarme si crecía y crecía y crecía … pensé, si acabo contratando varios servidores dedicados, y tirando de subdominios al estilo Flikr (farm1.flickr.com/.../albinybritneydesnudos.jpg) habría que pensar en (a) manera de saber qué usuario está en qué servidor (b) manera de guardar ficheros en otro servidor (ya no valen rutas fisicas, quizás ftp).
Por otro lado, muchas veces, como tenemos información almacenada en bbdd montamos la página dinámicamente para cada visita, cuando en verdad no es un listado filtrado, y cada vez se va a ver igual que las anteriores, hasta que vuelve a cambiar el contenido de el/los registro/s, digo con esto, que se podría guardar “maquetada” en un campo de bbdd y ahorrarse el coste de recursos de concatenar campos cada vez.
Al principio de aterrizar en esta empresa, con el pretexto de que todos iban con modems lentos y que eran clientes potentes (se esperaban muchas vistas) y alguna paja mental más, apostamos por “planear” las páginas de las fichas (asp to html) y, si no tienes un tráfico realmente bestial, es un poco excesiva la medida.
Coincido en que es un tema que me apasiona. Cuando trabajaba en una editorial jurídica, teníamos una aplicación con miles de usuarios, que debía ser capaz de responder en el mínimo tiempo (obviamente :) ) atacando una app. JAVA y una BBDD Oracle con toda la legislacion, jurisprudencia, etc… gigas y gigas y más gigas, ordenados, indexados y con búsquedas por texto, fechas , campos numéricos…
Mis conclusiones de aquello: para optimizar y escalar un sistema complejo no vale con saber programar, tienes que entender el “concepto” que mantiene todo: en JAVA, la JVM. La gente por lo general no sabe cómo funciona el garbage Collector, o que implica dejar objetos mal referenciados, o el comportamiento de los threads en un servidor de aplicaciones… uff, muchisimas cosas que te planteas cuando tienen problemas de rendimiento.
Y luego está Oracle, que es un mundo por sí mismo. Hay ya tenímaos expertas que lo sacaban adelante. Pero también es un mundo muy interesante.
Como me ponga a contaros batallitas sí que os contaría una “historia de guerra”, jeje
Albin, yo creo que el “cacheado” de fragmentos de página te da lo mejor de los dos mundos.
Tú haces tu web completamente dinámica, pero luego rodeas determinados fragmentos de la página en una librería de cache (por ejemplo oscache en java). Esto hace que si la página se vuelve a pedir en el tiempo de vida de la cache, ese fragmento de código no se ejecute y en su lugar se devuelva el html generado previamente.
Incluso con una vida de la cache “baja” (pensemos en 5 segundos) es muy efectivo. Si tienes poco tráfico, la cache no llegará a entrar, pero si empiezas a recibir mucho tráfico le pones una “vía de contención” (no hundes la bbdd a peticiones que siempre devuelven lo mismo).
Eso es para los maestros del Java … los pringaillos del PHP pensamos en soluciones más modestas :D
Comentarios cerrados para este artículo