Cuando nos empezamos a interesar en el desarrollo de sitios, sobre todo de los dinámicos, y más aun de los que tienen una respetable cantidad de usuarios (más de 10,000 usuarios diarios), tenemos que enfrentarnos, más temprano que tarde, a la necesidad de administrar servidores (VPS hacia arriba, y detalles más o menos importantes en servidores compartidos, como Dreamhost). El detalle, es que correr en tiempo real una prueba, puede significar grandes dolores de cabeza, mismos que en la práctica no deberíamos sufrir.
Entonces, la solución más práctica para nuestras pruebas es dar de alta una máquina virtual. Las máquinas virtuales son sistemas que aprovechan (si están presentes en nuestro equipo, y sobre todo, si nuestro BIOS lo permite) las tecnologías de virtualización propias de los procesadores de nueva generación. Pese a estar diseñadas para equipos con tecnologías como AMD-V o Intel VT, aquellos usuarios que no tengan estas tecnologías o su BIOS no permita aprovecharlas, también pueden beneficiar de la Virtualización, ya que la mayoría de los softwares permiten emulación del procesador, aunque siempre será más recomendable usar las ya mencionadas tecnologías para hacer más rápida la ejecución del código en nuestra máquina virtual.
Ahora bien, también deberemos tener en cuenta que cualquier tipo de solución que utilicemos tiene un impacto en el rendimiento de la máquina física. Si utilizamos mucho procesador para nuestros binarios, esto impactará fuertemente en el desempeño de aplicaciones no virtualizadas y, cómo no, en el sistema operativo anfitrión. Esto lo expondré más adelante, pero es importante tener en cuenta que entre más le demandemos a una máquina virtual, menos podremos hacer con la máquina real. También es importante a la hora de considerar cuánta memoria RAM utilizará nuestra máquina virtual, dejando suficiente memoria al sistema operativo anfitrión y las aplicaciones no virtualizadas. Esto, con calma, y si no entendieron, no se preocupen que todo será explicado delante. Leer más…
Estoy de plácemes. Y es que el último día de Julio de 2007, escribía un artículo acerca de los costos tan elevados de las licencias que tienen los software para bordado, en específico despotricaba acerca de Wilcom y su herramienta, Embroidery Suite (ES-65). La licencia, que ya no vende Casa Díaz, y que ronda los 15 “grandes” como dijeran los mafiosillos, tiene sus bemoles, sobre todo ahora con la salida de la nueva herramienta, co-producida junto con la canadiense Corel, DecoStudio e1.5. Este software ha “cambiado la forma en que trabajábamos los ponchadores” de manera “radical e innovadora”. Sí, claro, por solo un puñado de miles de dólares más. Y un carajo
Pues bueno, la gente de The Embroidery Warehouse ha hecho algo que me parece entre sorprendente y lo mejor que haya hecho nadie en la vida. Será porque nadie los piratea, pero decidieron hacer de MadPunch una herramienta gratuita. Free as free beer. Faltaría liberar el código, pero ya hay mucho camino recorrido. Y es que el software INDUSTRIAL de bordado no baja de 6000 dólares, más impuestos (última visita a Casa Díaz, Tajima DG/ML by Pulse Microsystems versión 12 [X²], nivel Maestro, $6,500.oo USD, más impuestos). Así, tenemos como 6000 dólares de ventaja para tener un negocio legítimo todos aquellos que usábamos Wilcom ES Designer.
En fin… estoy contento. Ojalá que nuestros amigos de The Embroidery Warehouse nos dieran la sorpresa de que, además de ser software gratuito para bordado, sea software ABIERTO para bordado. Entonces, además de disfrutar de hacer mi trabajo, aprendería a programar (y creo que una buena parte de los ponchadores) para mejorar la herramienta.
MadPunch se puede descargar registrándose en el foro de madpunch. Todos los procesos (registro, descarga, instalación y obtención del número de serie) son totalmente gratuitos. Y les recomiendo a todos los punchadores del mundo (bordadores del mundo, uníos) a aprender este software para ahorrarse problemas, tanto legales como económicos.
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.
