Last week I’ve been debugging a problem I had with this site’s nginx server: from time to time it hanged and I had to restart the process. Some time ago I wrote a little script that checked if it was running OK and restarted it otherwise, but anyway that wasn’t a real solution.

So I spent some days really looking into it and asking for support and reporting my findings to the nginx mailing list. One useful tip I got there was enabling the “debug” mode on the error log, which shows full traces of the processes (including their PID) as they’re processing the request, the rewrites, upstreams, etc.

With this extended log and the PID of the process malfunctioning, it’s quite easy finding out what that process was doing right before hanging. In order to find out the PID of the hanged processes, I extended my check-reboot script to log some generic system metrics right before restarting nginx: netstat -nap (which shows the PID), ps, vmstat, etc.

#!/bin/sh

TIMEOUT=20
CHECK=http://localhost/wp-admin/
LOG=/var/log/checkWeb/checkWeb-$(date +%Y%m%d).log
LOGR=/var/log/checkWeb/restart-$(date +%Y%m%d).log
TMP=/tmp/checkWeb-$RANDOM

if ! wget -t 1 -o /dev/null -O /dev/nul -T $TIMEOUT $CHECK
then
echo "ERROR, restarting nginx"
echo "** RESTARTING **" >> $TMP
date >> $TMP
echo "- CLOSE_WAIT:" >> $TMP
netstat -nap | grep -c CLOSE_WAIT >> $TMP
echo "- vmstat" >> $TMP
vmstat 1 5 >> $TMP
echo "- free" >> $TMP
free >> $TMP
echo "- ps" >> $TMP
ps aux >> $TMP
echo "- netstat" >> $TMP
netstat -nap >> $TMP
echo "" >> $TMP
echo "" >> $TMP

#       pkill -9 -f php-cgi
pkill -9 -f nginx
sleep 1s
/etc/init.d/nginx start

cat $TMP
cat $TMP >> $LOG
date >> $LOGR
fi

rm -rf $TMP

This way, each time localhost/wp-admin was unresponsive (I was debugging a WP site), besides restarting nginx I was getting a lot of system info. With time I got to realize that nginx processes were not actually hanging, but some of their sockets got on the CLOSE_WAIT state forever until the process was restarted. Looking for the PID of those processes according to netstat on the error log, the last request they were processing before getting to the CLOSE_WAIT state was always the same: on my blog I have some examples of how running servers with daemontools; daemontools uses named pipes (FIFOs), which can become kind of black holes if there’s no process feeding them; when nginx hit one of these FIFOs, it hanged.

Funny thing is that I never had this problem with either Apache nor lighttpd. But anyway the problem is not nginx but those FIFOs which shouldn’t really be there. I removed them and have had no hanged processes in five days, while before this nginx was restarting 3-4 times a day.

Como aparte de configurar el servidor y el PHP con fast-cgi hay que convertir todos los rewrites del Apache (wpmu y super-cache) al formato de nginx, es posible que el blog haga cosas raras, no se actualice debidamente, algunas páginas no vayan bien, pete, no acepte comentarios, o cobre consciencia de sí mismo y decida matar a todos los humanos. YMMV.

Many times the reason because a web server is slow and unresponsive is that it’s under “attack”, on purpose or not, by a bot. I’ve seen cases where Google Bot, bots from research engines from universities or some other kind of indexer were responsible for more than half the traffic of a site. These cases are not real DoS attacks, this traffic can be considered legitimate, but the result is that it brings the service down. You can instruct some of these bots not to visit your site so often, like Google Bot using the Google Webmaster Tools and the sitemaps and/or robots.txt files, but usually you can’t and have to consider filtering all this traffic at the firewall. But in any case, the first step is realizing that a single IP (or a couple of them) is responsible for most of your traffic, identifying this IP and using whois learn who it belongs to.

You can run something like this to list the top five IP addresses on your Apache’s access.log:

cut -d" " -f 1 access.log | sort | uniq -c | sort -nr | head -n 5

I’ve prepared a set of daemontools scripts to launch and monitor lighttpd and its PHP processes spawned with spawn-fcgi. Here is the README, a tar file with the scripts, and here you can browse the directories with all the scripts.

PS: yes, I like daemontools. It helps me achieving high availability with many services, keeping them up even when a server misbehaves and some process dies. This avoids a lot of late night calls. It’s a great invention.

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):

And for the PHP fast-cgi processes, just run or prepare an init.d script that runs the following command:

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.

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:

Lighttpd and CakePHP setup in subdirectories

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:

• YouTube Architecture
• Google Architecture
• GoogleTalk Architecture

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.

– Dune, de Frank Herbert

“Si no está en Google, no existe”. Esta frase tan categórica es cierta tanto para comercios on-line o webs corporativas, como para nuestro blog personal. Cuando necesitamos localizar información en Internet, vamos a Google. Y quien dice Google, dice Yahoo, MSN, o cualquier otro buscador. Tenemos que estar ahí.

Éstos buscadores usan “bots” o “spiders” para indexar el contenido de nuestras páginas, programas que periódicamente recorren todos los sitios que ya conocen en busca de actualizaciones y nuevos enlaces a través de los cuales descubrir, procesar e indexar más y más páginas

A nadie se le escapa que el trabajo de éstos programas es beneficioso, pero normalmente no tenemos en cuenta que generan tráfico extra a nuestra web. Aunque parezca mentira, conozco sitios en los que el tráfico de GoogleBot y compañía (ojo, hablo del propio bot, no de visitas dirigidas desde el buscador) consumía hasta un tercio del ancho de banda total de los accesos. Estamos hablando de GIGAS de tráfico al día.

Además los buscadores penalizan la información repetida: si tenemos varias páginas con contenido igual o muy similar, o aún peor, si podemos cargar una misma página con varias URLs distintas, podemos llevarnos sorpresas desagradables como páginas que no aparecen en los resultados de una búsqueda en favor de un feed o un resumen (índice de sección, categoría, etc.) con contenido similar, o páginas con un pagerank bajo porque éste se “diluye” entre varias URLs.

Por ello es importante aprender cómo funcionan éstos bots para saber cómo optimizar su paso por nuestro sitio web, cómo “llevarlos de la mano” hasta la información que queremos priorizar para así mejorar nuestro posicionamiento en los resultados, minimizando a su vez cuando sea posible la cantidad de información transmitida para no saturar nuestra conexión y servidores.

HTTP

GoogleBot, Yahoo! Slurp, etc. se comunican con nuestro servidor web mediante el protocolo HTTP, igual que haría cualquier otro cliente. Y son clientes “educados” que cumplen el protocolo.

Mucha gente desconoce que el protocolo HTTP 1.1 tiene métodos para controlar desde el servidor el funcionamiento de la gestión del contenido por parte de las cachés clientes (en proxies, navegadores, etc.) con una serie de cabeceras que indican la fecha de modificación del contenido, si ha sido modificado desde el último acceso, y una fecha de validez (o caducidad, como queramos verlo) hasta la cual indicamos que no es necesario volver a acceder a la página a refrescar el contenido.

Usando éstas cabeceras HTTP (Cache-Control, Last-Modified, Etag y Expires, junto con el código de respuesta 304) podemos ajustar cada cuánto tiempo cada cliente, sea Google, Yahoo, un proxie o la caché de nuestro navegador, va a venir al servidor a refrescar el contenido, y una vez que venga, devolverle la página completa si ésta ha sido actualizada o ahorrarnos el tráfico informándole de que la versión que tiene en caché aún es válida, renovando a su vez su periodo de validez. Es una forma de reducir drásticamente el tráfico de nuestros servidores y mejorar los tiempos de respuesta de cara al cliente, visitantes normales con un navegador también. Eso sí, siempre que tengamos muy clara la “caducidad” de cada una de las páginas según su contenido, ya que si nos pasamos podemos provocar que no se “vean” las actualizaciones.

Por ejemplo, para un sitio web con contenido actualizado a diario, podríamos configurar: para la portada una validez de cinco minutos; para cada artículo del día, quince, por si se actualizan para corregir cualquier error o puntualizar algún detalle; para el contenido de entre uno y diez días de antigüedad, doce horas o un día; y para lo que tenga más de diez días… un año, o más si asumimos que el contenido tan viejo no se va a actualizar nunca.

¿Cómo hacer uso de éstas cabeceras? La mayoría de servidores web (Apache, lighttpd…) usan la fecha de modificación de ficheros estáticos de forma automática para generar éstas cabeceras. Para el contenido dinámico, o forzamos unos datos según URLs en la configuración del servidor web, o bien generamos éstas cabeceras en programación.

Aparte de todo el control de caché, hemos comentado que no es conveniente que varias URLs apunten a un mismo contenido para que éste sea único y esté unívocamente identificado por su dirección. Si por ejemplo tenemos varios dominios (.com, .es y .net), o hemos refactorizado recientemente la programación y hemos tenido que reestructurar las URL, lo que lo que deberíamos hacer es redirigir todos los accesos a una URL única (dominio principal y estructura de directorios “canónica”) mediante una respuesta HTTP 301, de forma que centralicemos todo el contenido en un único dominio, y que cada página tenga una única ruta.

• Sección de la especificación HTTP 1.1 sobre control de caché
• Sección de la especificación HTTP 1.1 sobre códigos de respuesta
• Excelente tutorial sobre control de caché

robots.txt

En el fichero robots.txt podemos definir una serie de reglas para denegar el acceso a ciertas URLs según el User-Agent del bot que esté consultando la página. Es un protocolo establecido hace muchos años, y de nuevo GoogleBot y sucedáneos lo cumplen al pié de la letra. Y como su nombre indica, es un protocolo exclusivo para bots: un navegador normal no lee éste fichero ni se rige por las reglas que aquí definamos.

¿Utilidades? Varias: denegar el acceso a determinados bots a ciertas partes “privadas”, o que por cualquier motivo no queramos que se indexen, de nuestra web; bloquear completamente el acceso a ciertos bots que no nos interesen (porque es un buscador en el que no queremos aparecer, porque nos consulta demasiado rápido y nos satura…); bloquear el acceso a los feeds RSS para evitar que se indexen, ya que duplican contenido y pueden llegar a tener precedencia en los resultandos sobre las páginas “reales”; etc.

Sin embargo, este fichero es algo que hay que usar con cuidado: hay que tener muy claro que no le estamos diciendo a un bot que no indexe una página, si no que NO ENTRE en ella. Y si no entra, no descubrirá (ni seguirá e indexará) los enlaces que puedan “colgar” de ella. Así que si no somos cuidadosos podemos acabar bloqueando el acceso a partes completas de nuestra web que si que nos interesaría que se indexaran.

Como mínimo, si tenemos una estructura de carpetas/URLs decentemente organizada, si que podemos filtrar sin peligro feeds, carpetas con estilos CSS, carpetas con ficheros Javascript, carpetas con imágenes (si no queremos aparecer en Google Images), etc.

• Página sobre el fichero robots.txt
• Plugin SEO para WordPress, much ainformación sobre robots y METAs

METAs y rel=”nofollow”

Durante muchos años el protocolo para facilitarle la vida a los bots informándoles nosotros del contenido (content) y carácter (keywords) de nuestras páginas fue mediante tags META en el encabezado (<head>) de las páginas. Sin embargo con el paso del tiempo se vio que al depender sólo del buen hacer (o mejor dicho, de la buena fe) del webmaster eran fáciles de falsear, con lo que hoy en día prácticamente ningún buscador les presta mayor atención y se fijan principalmente en el contenido real en el cuerpo (<body>) del fichero HTML. Sin embargo si que hay un META que nos va a ser útil para marcar el camino a los bots: el meta “robots”.

Éste META puede contener dos valores de los dos pares (no)index y (no)follow: index/noindex indica al bot que considere (o no) el contenido de la página actual para su indexación, mientras que follow/nofollow le indica que siga o no todos los enlaces que encuentre en la página. Con el primero controlamos si no queremos que el bot se fije en el contenido de la página actual, mientras que con el segundo indicamos si queremos que continúe rastreando a partir de la página actual o que vuelva a la página anterior. Los valores por defecto si no indicamos lo contrario serían “index, follow”: indexar la página actual y seguir todos los enlaces.

Utilidad: evitar contenido repetido evitando la indexación de páginas de resumen, portadas, categorías, etc. en favor de las páginas con los artículos completos. Esto lo haríamos con:

“nofollow” nos sería útil para evitar el acceso de los bots a ciertas partes de nuestra web (como haríamos con el robots.txt) o para “ocultarle” de alguna forma enlaces a webs externas para que no tenga éstas relaciones en cuenta de cara a calcular el PageRank (en el caso de Google).

follow/nofollow en el meta se aplica de forma global a todos los enlaces de la página. Si sólo queremos controlar que no se sigan ciertos enlaces externos, podemos usar rel=”nofollow” en cada enlace de forma individual:

Ésto es útil para evitar enlazar páginas de SPAM, p.ej. añadiendo de forma automática éste atributo a todos los enlaces que se puedan introducir en nuestra página por parte del usuario (comentarios, foros…)

• Información sobre el META ROBOTS
• Más información sobre los METAs

Google Sitemaps

Por último, vamos a ver el método de más reciente aparición de todos: el fichero sitemap.xml.

Sitemaps es un protocolo originario de Google para ayudar a su bot a conocer mejor la organización y periodicidad de actualización del contenido de nuestra página, aunque Yahoo y MSN lo han adoptado ya también por lo que podemos considerar que es un estándar “de facto”. Se trata de un fichero XML con una sintaxis bastante sencilla en el que indicamos todas y cada una de las URL de nuestro sitio, su fecha de creación, modificación, una estimación de con qué periodicidad se puede actualizar (o cuánta validez le damos a la información, cada cuánto tiempo tendría que volver el bot a indexarla), y un “peso” con el que indicaríamos la relevancia relativa de cada página con respecto al resto.

En líneas generales puede parecer que todos éstos datos ya se los estábamos dando con los métodos anteriores: las cabeceras HTTP para indicar la validez, el robots.txt y el follow/nofollow para controlar dónde entra… la diferencia fundamental radica en que sin el sitemap, el bot de turno accede a nuestra página y va siguiendo enlaces, descubriendo como medianamente puede cada una de los distintos archivos que forman nuestro sitio; mientras que con el sitemap, nosotros le damos una lista de todas y cada una de las URLs que queremos que indexe, además de la importancia relativa que le damos a cada página.

• Información sobre sitemaps

Resumen

Hemos visto varias técnicas para guiar a los bots de los buscadores en su paso por nuestra web, indicándoles dónde entrar y dónde no, qué indexar y qué no, con qué periodicidad volver y si ha habido actualizaciones en nuestra página. Nos hemos centrado en los métodos para minimizar el tráfico extra que nos van a generar las visitas de éstos bots, pero maximizando su productividad.

Ésto es sólo una pequeña parte de todo lo que deberemos tener en cuenta a la hora de diseñar nuestra web y su contenido de cara a conseguir un buen posicionamiento. En internet hay infinidad de artículos sobre SEO orientados a cómo construir y organizar la maquetación HTML de la página, cómo escribir titulares, resúmenes, cómo y dónde enlazar a otras páginas, etc.

Por último, recordar que aparte de todo lo que hemos comentado aquí y podamos leer en cualquier otro artículo similar, no hay que olvidar la documentación oficial de cada uno de los buscadores, así como las herramientas que ellos mismos facilitan a los webmasters:

• Información sobre GoogleBot
• Google Webmaster Tools
• Información sobre Yahoo! Slurp
• Yahoo! Site Explorer

I’ve updated my lighttpd packages for Debian Sarge to the 1.4.15 release. Find them here.