La importancia de llamarse... GoEar

Cuando conocí GoEar hace ya casi un año, comprendí que este servicio iba a ser demasiado exitoso. Yo no juego con la palabra demasiado, así que pueden estar seguros que mi pensamiento iba encaminado a la falta de recursos que, en un momento dado, tendría su sistema. Este digamos vaticinio se tornó realidad hace un par de meses: el servidor caía cada dos horas, luego cada hora, e irremediablemente el servidor llegó a no poder ofrecer el servicio. ¿Donde está la falla? Yo tengo mi teoría, y ellos deberían conocerla. Pero que googleen para encontrar la solución:

Primero, observé que el servidor permitía la descarga de todo: texto plano, imágenes y los archivos MP3 (mmmh, no, no violé los términos, solo soy buen observador) si llamábamos los archivos desde una página en un servidor remoto o los llamábamos directamente del navegador. Por lo tanto, Apache puede servir suficientemente bien para más usuarios concurrentes que los que actualmente sirve.

Luego, intenté cargar la página inicial. La página inicial tardaba un promedio de 3-5 minutos y cargaba bastante bien, es decir, sin errores por demora de ejecución. Esto quiere decir algo: PHP no es el responsable, aunque algo comenzaba a fallar. Siguiendo esta línea hice una nueva prueba: inicié una búsqueda. Y cuando uno trataba de hacer una búsqueda el servidor devolvía tres tipos de páginas; la primera daba el resultado de la búsqueda, la segunda ofrecía una página blanca (error de base de datos, que detenía temporalmente la ejecución de PHP y no permitía la generación del HTML de respuesta) y la tercera ofrecía un error de máximo de tiempo excedido.

Entonces, había algo mal con la función de lectura de base de datos, pero ¿por qué?

Cuando tenía acceso a la lectura de los resultados, había veces (supongo que en las horas de menor tráfico) que tras unos tres a ocho minutos mostraba el reproductor y permitía ver la página. Pero en la mayor parte, el error de tiempo máximo excedido aparecía. ¿Error en el PHP.ini? No lo creo: la base de datos se quedaba colgada.

Entonces, hace falta algo en la ecuación, y creo saber de qué se trata. La única forma de poderlo asegurar es teniendo el código fuente del sistema de GoEar, el cual claro está, no me lo van a dar. Pero las dos razones principales para que suceda esto son:

1. El servidor MySQL reside en el mismo servidor que Apache/PHP. Este es el mayor error que siempre veo, y se me hace muy extraño que suceda en un sitio profesional como GoEar. Si este fuera el caso, sin embargo, estarían ocupando el 100% de los recursos de memoria y procesador durante unas 7 u 8 horas diariamente, lo que no es tan malo, pero congelan literalmente el sistema cada vez que los usuarios hacen peticiones.

2. El código fuente hace muchas peticiones a la base de datos (una muy desorganizada, debo suponer) que literalmente vuelve loco a PHP. Si este fuera el caso, los pasos para solucionar los problemas serían más pesados y desastrosos, pues habría que reescribir el código de cero para eliminar llamadas innecesarias a la base de datos y ya de camino, organizar de una manera limpia la base para que tarde menos en buscar (y relacionar menos las tablas, procurando mantener todo en dos o tres tablas). Además, si la base de datos, como supongo, es versión 4, hacer los upgrades necesarios y migrar la base a una tipo InnoDB, que permitiría hacer el trabajo más rápida y ágilmente.

Otro posible hecho que viene a mi mente en estas últimas líneas es PHP. Aunque lo he descartado, llega a mi mente el problema que muchos compañeros bloggers han tenido con Wordpress alojado en Dreamhost. Este problema era cuando tenían demasiados visitantes y lo solucionaron utilizando PHP como CGI (con FastCGI) y utilizando un proceso persistente y solucionaron los problemas. ¿Por qué se me ocurrió? Con la esperanza que los de GoEar no lean este post o que respenten este pequeño recoveco del que echaba mano para mi sitio, el reproductor en Internet Explorer da un error de "no se permite esto, lo sentimos, jodimos al webmaster pero visita nuestro sitio para oir este track". Pero en Firefox y otros navegadores ESTE PROBLEMA NO EXISTE. Supongo que es un fallo de programación. En fin, pues en mi sitio ponía las canciones a través de GoEar y las escuchaba con Firefox, y el navegador USA LA BASE DE DATOS para generar la playlist. Entonces, la base de datos no puede estar tan mal. Pero un PHP mal configurado puede matar un servidor web en ciertos procesos, sobre todo en la generación de páginas. Y es aquí donde el error de tiempo excedido cobra lógica: PHP tenía demasiadas peticiones cada x segundos y cuando ya no contaba con CPU (no creo que memoria) el programa se detenía.

¿Solución? Utilizar clusters y múltiples procesadores mucho más poderosos. Y si fuera problema de memoria, ponerle un poco más, que no cuesta tanto y las cosas funcionan más.

blogroll

social