Antecedentes
Además de otras cosas, podemos decir que el servicio estrella es un par de sitios gestionados con drupal. Dado que no sentía la necesidad de la «versionitis», estaba manteniendo la rama 4.6. Era feliz, hasta que salió la versión 5.0. Drupal mantiene actualizada las dos ultimas ramas estables, al salir la 5.0 solo quedaban vivas la versión 4.7 y 5.0. Por tanto urgía una actualización, ya que la 4.6 dejaba de existir.
Ya he hecho alguna que otra actualización de drupal y digamos que no ha sido nunca trabajo trivial (en la rama 5 parece que la cosa ha mejorado algo). Pero mi sorpresa fue mayúsculas cuando al ejecutar el script de actualización se me quedaba bloqueado el sistema.
Aunque esto es una entrada de diario, no voy a contar minuto a minuto mis penas. El resumen es que en el proceso de actualización de las tablas de la base de datos se consumía toda la memoria del sistema y empezaba a usar el swap. Curiosamente, instalar un Drupal de cero no tenía tanta complicación y funcionaba.
La primera opción era bajar los recursos que necesitaba la máquina en la actualización (y en general siempre). Otra opción era congelar todo lo que tenía hasta ese momento y empezar desde cero. Un «reloaded». Pero no me atraía esa idea. Quizás copiar la base de datos a otra máquina más potente, instalar allí Drupal, hacer la actualización allí y volver a copiar la base de datos al servidor era posible (y era mi último cartucho), pero instalar un LAMP en otra máquina para solo hacer la conversión tampoco es de mucho agrado.
Los pasos que seguí fueron:
- Tocar la configuración de Mysql y Apache para que consumiesen los menos recursos posibles. Limitando el número de clientes simultáneos y la memoria RAM máxima de cada proceso. Aunque no fue suficiente.
- Finalmente decidí sustituir Apache por lighttpd.
El motivo de la entrada del diario es hablar un poco de lighttpd y de por qué me lava más blanco.
Qué es esto de lighttpd
Entre nosotros, yo diría que la mayoría de las personas que se mueve en esto del software libre es capaz de nombrar dos servidores web: Apache y Apache 2 ;-)
No quiero en ningún momento quitarle méritos a estos programas: son programas complejos que hacen cosas complejas; pero ¿es esto lo que necesito?
Lighttpd es un servidor web diseñado de forma monolítica, y no emplea hilos para atender las distintas peticiones. Lo que afirman sus desarrolladores es que tiene un consumo de memoria de un quinto respecto Apache y que las páginas estáticas las sirve más rápido (de 4 a 6 veces).
¿Qué pasa con las páginas dinámicas? Hay un sistema denominado fastCGI que Apache, aparentemente, implementó muy mal. Estos decidieron emplear sistemas como mod_php en detrimento del primero. Lighttpd lo implementa y afirman que lo hacen tan bien que su velocidad es similar a lo que se consigue en Apache (de hecho dicen que es entre 4 y 6 veces más rápido que mod_php4, en la web que he puesto antes tienen enlaces a benchmarks).
He dicho antes que era monolítico porque es lo que viene en su propaganda, pero lo cierto es que hablan de módulos cargables y plugins. (Realmente me da igual mientras funcione). Aquí se incluyen funcionalidades útiles y usados por muchos, aunque quizás no todos: fastCGI, reescritura de urls, anti-hotlinking, un módulo para protegerse de los ataques de denegación de servicio (DOS)... Si no lo cargas, no te carga (el sistema).
Y llegamos al ultimo punto que quería tocar: la configuración. Dicen que es muy sencillo de configurar. La verdad es que sin leerse el manual es tan difícil como cualquier otro programa; pero tiene una estructura que se puede seguir:
modulo.variable = valor
En principio, las variables definidas son globales a todas las páginas pero de una forma parecida a cómo está la configuración de mutt (y supongo que en otro sitios) se pueden definir condiciones en las que una variable varía su valor en función del valor de otra variable:
$HTTP["host"] =~ "^www\.(.*)$" {
url.redirect = ( "^/(.*)" => "http://%1/$1" )
}
[Esto es: cuando el host solicitado empiece con www, hacemos una redirección a la url sin el www]. Podríamos haber activado, por ejemplo, que el ancho de banda de un subdominio determinado sea limitado y en el resto no (imaginación al poder).
Por supuesto, no todo es agua de rosas. Sobre todo cuando hay que hacer la conversión desde un sitio montado en Apache. Por ejemplo, .htaccess no está soportado. Aunque como existe un mecanismo de inclusión de ficheros externos de configuración podría emularse. El segundo problema que me he encontrado (y aun está dando los últimos coletazos) es que no es totalmente equivalente el mod_rewrite de uno y otro, y hay que dar un pequeño rodeo para emular el comportamiento de uno en otro.
Aparentemente he conseguido hacer la migración completa de drupal a lighttpd. Si alguien tiene alguna duda, no dude y pregunte.
