Archivo de la categoría: lighttpd

PHP con lighttpd 1.5.0

[spanish]

La forma de configurar PHP en lighttpd 1.5.0 ha cambiado: ya no se usa mod_fastcgi si no mod_proxy_backend_fastcgi, y lighty ya no se encarga de lanzar los procesos PHP si no que tendremos que hacerlo nosotros con ayuda del programa spawn-fcgi.

Para configurar mod_proxycore bastaría con ésto (en lighttpd.conf, o conf-enabled/php.conf p.ej.):

[code lang=»bash»]

server.modules += ( «mod_proxy_core», «mod_proxy_backend_fastcgi» )

$PHYSICAL[«existing-path»] =~ «.php$» {
proxy-core.allow-x-sendfile = «enable»
proxy-core.protocol = «fastcgi»
proxy-core.backends = ( «unix:/tmp/php-fastcgi.sock» )
proxy-core.max-pool-size = 16
}
[/code]

Y para lanzar los procesos PHP, ejecutar a mano o mejor desde un script en init.d:

[code lang=»bash»]

/usr/bin/spawn-fcgi -s /tmp/php-fastcgi.sock -f /usr/bin/php-cgi -u www-data -g www-data -C 5 -P /var/run/spawn-fcgi.pid

[/code]

[/spanish]

[english]

PHP integration and configuration in lighttpd 1.5.0 has changed: mod_fastcgi isn’t used any more, you need mod_proxy_backend_fastcgi instead; and lighty won’t launch the PHP processes, you’ll have to start them using the spawn-fcgi program.

In order to setup mod_proxycore for use with PHP, this is the bare minimum configuration (put it in lighttpd.conf, or conf-enabled/php.conf):

[code lang=»bash»]

server.modules += ( «mod_proxy_core», «mod_proxy_backend_fastcgi» )

$PHYSICAL[«existing-path»] =~ «.php$» {
proxy-core.allow-x-sendfile = «enable»
proxy-core.protocol = «fastcgi»
proxy-core.backends = ( «unix:/tmp/php-fastcgi.sock» )
proxy-core.max-pool-size = 16
}
[/code]
And for the PHP fast-cgi processes, just run or prepare an init.d script that runs the following command:
[code lang=»bash»]

/usr/bin/spawn-fcgi -s /tmp/php-fastcgi.sock -f /usr/bin/php-cgi -u www-data -g www-data -C 5 -P /var/run/spawn-fcgi.pid

[/code]

[/english]

lighttpd 1.5.0-SVN r1992 para Debian Sarge

[spanish]

He preparado paquetes .deb de lighttpd 1.5.0-SVN r1992 para Debian Sarge. Están basados en el último paquete de testing, actualizado a la 1.5.0. Falta sólo el mod_mysql_vhost, no tengo ahora mismo instalado el mySQL 5.0 ni sus librerías. Ésta página ya se sirve desde lighttpd 1.5.0, así que es la mejor prueba de que funciona. ;)

Se puede descargar aquí.

(PD: si, ya se, lo que tendría que hacer es dejarme de historias y actualizar a Etch…)

ACTUALIZACIÓN (20070921): Nueva versión con soporte para linux-aio-sendfile. Hace falta también el port de libaio.

[/spanish]

[english]

I’ve built .deb packages of lighttpd 1.5.0-SVN r1992 for Debian Sarge. They’re based off the latest packages in testing, upgraded to 1.5.0. The only thing missing is mod_mysql_vhost, as I don’t have mySQL 5.0 installed at the moment. This server already runs lighty 1.5.0, so the fact that you’re reading this page is the best proof that it works. ;)

The packages are available for download here.

(PS: I know, I know, what I should do is upgrade to Etch altogether…)

UPDATE (20070921): new release with linux-aio-sendfile support. You’ll need the libaio port too.

[/english]

CakePHP y lighttpd

[spanish]

Llevo unos días enfrascado en un proyecto web con CakePHP, y quería usar lighttpd como servidor web. Para que funcionen las «URLs limpias» CakePHP trae el típico .htaccess con las reglas mod_rewrite para Apache, que hay que convertir al formato de lighttpd. He encontrado la solución aquí, 3er comentario:

[/spanish]

[english]

I’ve been busy the last couple of days with a web project I’m developing using CakePHP, and I wanted to use lighttpd as the web server. CakePHP comes with the typical .htaccess with Apache’s mod_rewrite rules, that need to be converted to lighty’s format. The solution can be found here, 3rd comment:

[/english]

Lighttpd and CakePHP setup in subdirectories

[code lang=»bash»]

url.rewrite-once = (
«/(.*).(.*)» => «$0»,
«/(css|files|img|js)/» => «$0»,
«^/([^.]+)$» => «/index.php?url=$1»
)

[/code]

Arquitecturas escalables en Google

[spanish]

Un compañero de trabajo me manda tres interesantes artículos de la web High Scalability, que no conocía aún y que ya he añadido a mi lista de RSSs en Google Reader. :) Los artículos tratan sobre las decisiones de diseño y arquitectura de computadores/redes tomadas en YouTube, Google y GTalk, para hacer frente a la altísima cantidad de visitas y datos que deben servir por segundo, comentando también más o menos la estructura actual y la evolución de la infraestructura de cada uno de ellos:

Algunas conclusiones a extraer de éstos artículos:

  • No intentar arreglarlo todo con una única arquitectura o una única herramienta. Dividir el problema en subproblemas, ver en cada caso si el límite es CPU, ancho de banda, IO y optimizarlo. Especializar servidores para cada caso y coordinar el trabajo de cada parte.
  • Cachear contenido siempre que sea posible. Pregenerar contenido siempre que sea posible. Utilizar las directivas HTTP para el control de caché. Usar squid como proxy inverso para aliviar a los servidores de aplicaciones.
  • Plantearse externalizar algún servicio, el hosting de imágenes o videos que puedan suponer más ancho de banda del que actualmente tenemos. Aunque sea como solución de compromiso mientras se contrata más ancho de banda. Lo importante es ofrecer el servicio en condiciones.
  • Simplicidad, dentro de lo que cabe. Permitirá hacer cambios y evoluciones sin cagarla demasiado.
  • Clusters basados en PCs normales. Maximizan la relación potencia/precio. Tener montado un sistema de redundancia para que una caída no afecte al servicio, y un sistema de instalación sencillo para poder añadir/sustituir equipos sin calentarse mucho la cabeza. Y empezar a planificar los problemas de alimentación y aire acondicionado. ;)
  • La programación hoy en día se basa en librerías y frameworks. No reinventar la rueda. Usar un framework común, propio o no, de forma que los programadores no tengan que hacer una y otra vez las mismas cosas y una actualización beneficie a todos nuestros productos de golpe.
  • Pensar en la arquitectura desde el principio. Estoy tristemente acostumbrado a que los desarrolladores no se preocupen de lo que hay por debajo de su código, ni si éste va a provocar problemas de red, disco, CPU, etc. Google enfoca todos los problemas desde la arquitectura necesaria para dar el servicio, y luego programa alrededor de ésa arquitectura. Es lo que diferencia a Google del resto.

[/spanish]

[english]

A coworker has sent me three interesting articles from High Scalability, a site I still didn’t knew but which I’ve already added to my Google Reader list. :) The articles talk about the design and computer/network architecture decisions taken at YouTube, Google and GTalk in order to handle the big load their services face. They also comment the current architecture in each site and their evolution over time:

Some lessons to learn from these articles:

  • Don’t try to fix everything with one single architecture or tool. Divide the problem, see if each sub-problem is CPU-, bandwidth- or IO-bound, and optimize it. Specialize server for each task and coordinate their work.
  • Cache content whenever possible. Pre-generate content whenever possible. Make good use of HTTP’s cache-control directives. Use squid as a reverse proxy to leverage your application servers’ load.
  • Think about externalizing some things, like hosting images or videos off-site. These elements may need more bandwidth that you currently have, and moving them off-site can be a good idea, even if it’s just a temporary measure while you manage to get more bandwidth. The service must run at all times.
  • Simplicity. Will let you make changes and evolve your architecture without screwing up.
  • Commodity-PC based clusters. They maximize the power/price ratio. Have a redundancy system in place so that when one node goes down or needs maintainence, the system keeps working without it. Have a system to easily install/change a node, also without affecting the service. And start planning the power and cooling problems ahead. ;)
  • Programming today is much about libraries and frameworks. Don’t reinvent the wheel. Use a common framework in all your developments, homegrown or not. This way novel programmers will be able to start writting code faster, will be able to switch projects easily, won’t have to code the same things over and over again, and a system upgrade will benefit all your applications.
  • Think about the architecture you’ll need from the start. I’m sadly used to developers not caring about what their code runs on, or if their code will lead to CPU, IO or bandwidth problems. Google seems to face every new development looking at the architecture they’ll need to handle the service, and then develop the code arount that architecture. This is what settles Google appart from the rest.

[/english]