2003-12-10 19:00
Muchos sitios que se hacen terriblemene populares acaban
muriendo de éxito;
ayer hablamos de ello.
Morir de éxito es un problema de escala. En dos palabras, lo que funciona bien a una escala determinada, funciona muy mal cuando aumentamos la escala. Un sitio funciona bien con mil visitas, pero con un millón, casca. Un insecto funciona bien si es pequeñito, pero si aumentara hasta el tamaño de una vaca, se asfixiaría. Un sistema P2P puede con diez mil nodos, pero si se meten un millón
como le ocurre a Gnutella, acaba cascando.
Barrapunto necesitó un cambio radical para poder resistir el número de peticiones que sufría al día. Y como a alguien le toque sufrir el
efecto Slashdot, va apañao. Por no mencionar ataques intencionados de denegación de servicio.
Mirando a
las estadísticas de PJorge (de las que habló en
esta historia), o incluso a las de
Blogalia, y supongo que a muchos otros sitios, cabe suponer que los problemas de escala se presentarán tarde o temprano.
Blogalia ha triplicado sus visitas desde enero, y
PJorge las ha quintuplicado. Si sigue así el tema (y puede que siga, puede que no, quién sabe), blogalia puede tener el año que viene por estas fechas casi doscientos mil hits,
al día, y PJorge prácticamente lo mismo. No quiero hacer de Casandra aquí, pero ¿serán capaces de soportarlo? Ambas bitácoras se basan en una arquitectura dinámica, de forma que cada petición implica una o varias peticiones a una base de datos, y una construcción dinámica de la página usando servlets (en el caso de PJorge) o PHP (en el caso de blogalia). ¿Cuál es el máximo de peticiones que puede soportar la base de datos?¿Cuál es el máximo de hebras que puede soportar el contenedor de servlets que usa PJorge?
El problema es que, tanto en estos casos como en todos los demás, antes de alcanzar ese límite físico se topa con el límite
económico: la tasa de transferencia máxima que es capaz de soportar el servidor por el precio contratado, por ejemplo. Blogalia transfirió casi 20 Gigas, y PJorge, 4 gigas. El problema técnico se convierte entonces en un problema económico: hay que pagar más ancho de banda. En realidad, casi siempre lo es: se trata de ampliar el sistema que sirve las peticiones, ampliando la memoria, o poniendo un disco duro más rápido, actualizando alguna parte crítica del sistema operativo que lo haga más rápido.
Muy probablemente me esté metiendo donde no me llaman, pero todo esto tiene una moraleja: si tienes un sitio web que se hace paulatinamente más popular, hay que planificar con tres o cuatro meses de antelación su ampliación, para que no te pille el toro. Si tienes una bitácora alojada en tu propia casa, tirando de un ADSL, piensa qué pasará cuando te pidan más de treinta y tantos Ks por segundo (que es bastante, pero puede suceder). Si la tienes en un servidor comercial, mira las estadísticas, y contrata más caudal antes de que tengas que "cerrar temporalmente por exceder el ancho de banda contratado".
Lo cual, claro está, lleva a la siguiente pregunta: ¿y cómo|quién paga eso?.