El Domingo pasado Joel me llamó para pedirme que le averiguase dónde debía votar, ya que no le funcionaba la conexión a Internet de la casa. Al igual que como hubiera hecho la mayoría de ustedes, entré en Google Argentina y busqué “dónde votar“.

Los primeros tres resultados eran:

  1. http://www.elecciones2007.buenosaires.gov.ar/
  2. http://www.tusbuscadores.com/elecciones/
  3. http://www.sitiosargentina.com.ar/notas/octubre-2005/donde-votar.htm

Obviamente, reconocí al primer resultado como el “oficial”, y al resto como simples “repetidoras” con links a los sitios oficiales. Así que sin dudarlo, entré al primero: http://www.elecciones2007.buenosaires.gov.ar/.

Para mi sorpresa, me encontré con el siguiente mensaje:

elecciones2007_1.png

Wooah! Lo primero que pensé es que no me gustaría estar en los zapatos del hostmaster a cargo del sitio. Realmente, sufrí por él… Luego me puse a hacer algunas cuentas rápidas, y resultó obvio, un sólo servidor no resiste a cientos de miles de personas intentando averiguar dónde deben votar, todas en una franja de tiempo bastante reducida (sábado por la tarde / domingo por la mañana).

Me pregunto cómo será el “efecto elecciones” comparado con Digg o Slashdot… Creo que la mayor diferencia estaría en que el origen de las visitas en época de elecciones es mayormente local, generando conexiones de menor duración gracias a la latencia reducida. Igualmente, debe haber sido un infierno.

A los pocos minutos el servidor volvió a estar en línea, y felizmente pude hacer mi consulta. Pero no dudo que les haya pasado lo mismo varias veces a lo largo de todo el día.

El sitio parecía estar armado pensando en el tráfico que recibirían, todo hecho en CSS, muy liviano. Para hacer las consultas usaban PHP, seguramente un servidor MySQL, y un captcha para validar la consulta:

captcha elecciones

Pero cuando hay un sólo servidor para tantas consultas simultáneas, pueden pasar dos cosas dependiendo de cómo esté configurado el servidor. En general, suceden las dos, y en este desgraciado orden:

  1. El servidor tiene un límite de conexiones simultáneas básico, predefinido por la configuración. Digamos, 256.
  2. Llegan mil visitas en un lapso de 10 segundos. El servidor no puede recibirlas a todas, así que las que pasen la número 256 reciben un mensaje de error 503.
  3. ¡Caramba! El administrador recibe decenas de llamadas a su celular. Entra en la consola del servidor, temblando de miedo, rezándole a todos los dioses que lo dejen sobrevivir a esta crisis.
  4. Al poco tiempo descubre el desperfecto: ¡EUREKA! El servidor tiene un límite muy bajo de conexiones simultáneas. Así que lo sube a 512 y le dice “Já! Tomá!”. Reinicia al servidor y pone en su browser www…. Funciona. Carga muy rápido. Sonríe. Suspira relajado.
  5. Pero pasan algunos minutos, y vuelven a recibir otra tanda de mil visitas en menos de 10 segundos. El administrador repite los pasos que lo salvaron por primera vez, sin ver que lo que está haciendo va a generar una gran reacción en cadena que no va a poder frenar.

El servidor puede procesar hasta X peticiones simultáneas con un buen rendimiento. Pasado ese límite, lo único que se consigue aumentando la cantidad de pedidos simultáneos es que todo funcione lento, y que el servidor quede con miles de conexiones “abiertas”. Como sabiamente dijo Joel ayer, “es como remar en dulce de leche”.

Y las consecuencias, obviamente, son peores. Pasado ese límite, se genera una bola de nieve que no se puede parar, hasta que el servidor queda estancado (colgado), y hay que tomar otras medidas para hacerlo volver en sí (léase, pegarle un botonazo).

¿Cómo evitarlo?

Todo depende de dos factores:

  • Hardware: tener un esquema de servidores ideado para recibir picos de tráfico, como un grid o un cluster. Al distribuir la carga entre una docena de servidores, se multiplica la capacidad por la cantidad de servidores en la red. Nuestros nodos suelen tener entre 4 y 8 servidores de procesamiento, con 2 gateways que distribuyen inteligentemente la carga.
  • Software: optimizar al máximo el código. Hacer contenido estático. Enviar el tráfico estático a servidores más livianos (como lighttpd). Optimizar las consultas SQL. En ciertos casos en que las consultas son siempre las mismas, habilitar un servidor memcache.

Steve Souders del “Exceptional Performance Team” de Yahoo! dió una brillante presentación con consejos útiles para sitios de alto tráfico. Para los que quieran profundizar en este tema, les recomiendo verla, está muy buena.

Moraleja: cuando sepan que su sitio va a recibir miles de visitas en un lapso corto de tiempo, estén preparados ;-)