Press "Enter" to skip to content

escalabilidad en webs de gran éxito: de 0 a 1 millón de visitas y el caso MySpace

el interesantísimo artículo de Baseline sobre MySpace me recuerda a hace unos años, trabajando ya con mi actual «empleador», cuando sufrí este mismo problema (a escala, por supuesto) de casi morir de éxito: en mi caso, los «milestones» de escalabilidad fueron las 100.000, 500.000 y sobre todo, el millón de páginas vistas por mes; esas fueron las barreras (aproximadas) en las que el sistema requirió un rediseño importante para dar cabida a los usuarios; como digo, a escala, porque MySpace tiene más de 38 mil millones de páginas vistas al mes!

el efecto de un web que no es capaz de responder a la carga de trabajo que se le pide puede ser gradual (con mayor o menor pendiente) como el descrito por Baseline en MySpace o el caso que yo viví que se prologó aproximadamente un año hasta que alcanzó el techo de visitas;

…pero también puede ser prácticamente instantáneo como lo que se conoce como efecto slashdot; hasta se ha acuñado el término slashdotted para describir un web que cae por no ser capaz de aguantar la carga de trabajo por las visitas que recibe al aparecer un enlace en un web como slashdot.org (o digg.com o cualquier otro web de noticias en las que tiene la suerte (mala? buena?) de salir el link)

es una pena: los 5 minutos de fama (que decía Andy Warhol que todos merecíamos) en internet se esfuman en cuanto tu web es incapaz de responder en tiempo y forma a las peticiones que llegan


mi experiencia me ha enseñado que el diseño pensando en los picos es fundamental si queremos que el web resista el éxito momentáneo (una campaña de publicidad exitosa, un enlace en un lugar como slashdot, o incluso, un ataque por intento de denegación de servicio, algo mucho más común que aparecer enlazado en un web de primera línea)

leyendo el caso de MySpace, está claro que empezaron como tantos webs, sin creérselo mucho, a toda prisa y sin pensar; ellos mismos reconocen que no empezaron a utilizar herramientas de caché hasta la última fase de rediseño y que quizás, deberían haberlo hecho antes:

The addition of the cache servers is «something we should have done from the beginning, but we were growing too fast and didn’t have time to sit down and do it,» Benedetto adds.

mi experiencia me ha enseñado que la gestión de la caché debe tenerse en cuenta desde el inicio del proyecto; cualquier web puede beneficiarse de un sistema de caché, hasta una página personal, aunque como siempre, todo dependerá de los requisitos y el presupuesto disponible

mi mantra es el siguiente: el número de conexiones a la base de datos que debe tener un web para ser realmente escalable debe ser ¡cero! y es perfectamente posible. Incluso un foro, que normalmente tenga un ratio de lectura/escritura de 5 a 1 : cinco páginas vistas por cada mensaje nuevo, debería utilizar sistemas de caché y no estar siempre leyendo de base de datos en cada pagina

al que le parezca imposible, es que no se ha parado a estudiar el tema: cada vez que alguien pide una página web a un sistema dinámico hecho en PHP, Perl, Java, Python, Ruby, C# o lo que sea, normalmente se recoge el contenido de la base de datos que sea y se genera el resultado en HTML para el navegador; perfecto, pero… si se recarga esa página u otro usuario la pide… ¿qué partes son distintas? porque volver a pedir la información a la base de datos es tirar recursos… ¡acabamos de leerla!

por supuesto, da igual si no es exactamente la misma página (p.e. puede haber cambios si está o no logado el usuario, o cambios aleatorios como cajas de últimas entradas en un foro); las estrategias de uso de caché no deben ser de páginas completas, sino de trozos de páginas; es siempre preferible ya que si p.e. cambia una noticia de portada, al rehacer la caché de toda la página estamos tirando recursos también: ¡sólo ha cambiado una noticia! ¿para qué le pido a la base de datos todas las demás?

hace un par de años dí una conferencia sobre este tema en la Facultad de Informática de A Coruña, y la presentación en la que explico todo ésto está disponible aquí en PDF; espero que sea útil para cualquiera que se interese por este tema

quien se considere un buen arquitecto de soluciones web, tendrá siempre en cuenta en su diseño de base cómo gestionará la caché de sus trozos de página, del acceso a base de datos o de los objetos en memoria, cómo los invalidará y reconstruirá y con ello, su web será infinitamente más eficiente y necesitará una cantidad menor de recursos hardware y software; sólo con ser más cuidadosos (y serios!) con nuestros desarrollos de base podremos ahorrarnos en máquinas, licencias de software (si las hay) y recursos utilizados (memoria, conexiones a la base de datos, etc.)

y cuidado! (como yo aprendí en su momento) incorporar estos mecanismos posteriori, con sistemas ya en producción o muy avanzados, es más caro y difícil

MÁS: hoy mismo colaboramos para mejorar el rendimiento de un conocido web, tras la presentación ayer de su remodelación completa; tuve ocasión de revivir lo complicado que es optimizar tras el lanzamiento, aún cuando la arquitectura que se implementó era correcta y se trataba únicamente de parametrización, pero la diferencia entre el web que no es capaz de responder las peticiones y el que sí, es la caché y en éste caso, también

6 Comments

  1. Me he leido el pdf de tu conferencia, está muy interesante.

  2. IvanMG IvanMG

    Muy interesante el artículo y el pdf de la conferencia. Supongo que la conferencia sería más interesante aún.

    Sólo un comentario: «almost 40 billion page views a month» es más bien «casi 40 mil millones de páginas vistas al mes» y no «casi 40 billones».

  3. gracias! cierto, sus billones son nuestros millardos, edito la entrada

  4. Xose Xose

    Tú y yo sabemos lo malo que fue cogerle el truco a la implementación de la caché de un CMS que practicamente estaba en desarrollo y donde la documentación, aunque extensa, no era todo lo buena que debería ser por el precio que se pagó por la herramienta.

    Aún tengo pesadillas con los parametros de las «partes» que estaban en caché y el script en sh que te curraste para borrarla. (De los puñereros asset:load que tanto quebradero de cabeza nos dieron por haber modificado los XML de los assets a mano prefiero no hablar, jajaja).

    Espero que ahora no tengas tantos problemas como teníamos entonces, aunque reconozco que fueron una de las mejores épocas de toda mi experiencia laboral.

  5. hombreeee, Xose, qué tiempos aquellos! Aún hoy me han llamado para echar una mano a un conocido web que usa la misma tecnología, y los problemas no son los mismos, pero los nuevos tampoco son moco de pavo

    anda que no aprendimos entonces 🙂 🙂

  6. Xose Xose

    ¿un periodico Gallego?

    Con respecto a lo de la Cache que se implementó para aquello, aún hoy creo que si hubiesemos controlado un poco más la caché de consultas de Oracle no habríamos tenido tantos porblemas.

    Si hasta el mySQL es capaz de hacerlo, no se porqúe con Oracle no funcionaba.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.