Para colores, 32 Bits

Hace unos días quise cambiar un poco la estructura de los permalinks de la web sobre cine Filmclub.
Pensé que habría que hacer algo, pero comprobando las noticias (de cualquier antigüedad), el propio wordpress redireccionaba a lo que toca. Lo que cambié fue que en lugar de tener la estructura por día, la tuviera por mes (muchas de las webs con más pagerank y más tráfico obvian el día, por algo será). Pasando de tener una url como:

filmclub.es/año/mes/dia/titulodelanoticia/

A quitar el día quedando el tema así:

filmclub.es/año/mes/titulodelanoticia/

Qué fácil, pensé. No podía estar más medio-equivocado. A los pocos días empiezan a saltar errores de 404 en Google Webmaster. En realidad no lo entendía, hasta que vi que, aparte de algunos links mal puestos, lo que fallaba eran las URL que apuntaban a imágenes de posts.

Si ponía la url tal cual, fallo 404.

Si le quitaba el día, cargaba bien.

Si ponía la url tal cual pero quitaba la última parte de la URL, redireccionaba bien y cargaba la noticia.

Así que como no vi ninguna solución consultando por wordpres, nginx y rewrites, era hora de aprender algo sobre Expresiones Regulares, que siempre se me atrancan. Tras mucho probar y buscar, terminé usando un formulario de una web que parece que está hecha para Google Analytics. La web en cuestión es Metriplica, en su apartado de expresiones regulares, con documentación incluída y demás.

Al final es solo poner una regla de rewrite en el fichero .conf del dominio del Nginx. Tras jugar un poco con la web de Metriplica, pude conseguir la expresión regular siguiente (con el rewrite aquí):

rewrite ^/([0-9][0-9][0-9][0-9])/([0-9][0-9])/([0-9][0-9])/(.*) /$1/$2/$4 permanent;

Explicación:

De la URL que te pidan, se coge lo que venga después del dominio.

Si hay 4 separaciones o más, quiero que lo dividas en 4 variables, siendo la primera una que sea numérica de 4 dígitos (el año) de 0 al 9 cada dígito, la segunda también numérica de dos dígitos (el mes), la tercera igual que la segunda (para los días), y el resto (independientemente de que vengan números, letras, o graffitis.

Si lo de arriba coincide, hay que reescribir la URL quitando la tercera variable, ergo tendremos el año, el mes y el resto.

Marcar esto como cambio permanente. El rewrite con esa opción ‘permanent’ al final, devuelve un código 301.

Nada como aprender de esta manera para que se te quede.

Más que nada porque resume bastante bien todos los temas a tocar si quieres aumentar tráfico en tu web y hacerlo de manera eficiente.

El podcast está producido por el blog de Dabo.

Ahora que se ha hecho oficial que Google va a empezar a mejorar las posiciones en los resultados en función de la velocidad de carga de la web, es hora de empezar a pasar de Apache e implantar servidores web más eficientes como NginX o Lighttpd (aunque este último tenía problemas de memoria).

Ya he comentado varias veces en este blog como he conseguido mantener websites con mucho tráfico con ayuda de nginx.

Solo mencionar que, probando con una de las webs de testeo mencionadas en Alt1040, los tiempos de carga de Anieto2k, Filmclub y este mismo blog están entre los 6 segundos en la primera carga y 1’5 segundos la segunda carga (cacheada).

Para compararlo con algo más serio y decente, puse el mismo test contra Motorpasión y sus resultados fueron más altos: 11 segundos en la primera carga y 2 segundos en la segunda carga. Ellos usan todo el stack en Apache, mientras nosotros no usamos apache.

No es por ser catastrofista, pero según cuentan parece que hay pocos millones disponibles.

Aunque el tema se refiere que hay tantos dipositivos y gente conectada, sobretodo de la parte oriental emergente, hay algo que no me cuadra. Es verdad que los que peligran son los usuarios por venir (quien dice usuarios dice máquinas y dispositivos como los móviles con acceso 3G), pero hay otro gran sector que ha chupado muchas direcciones y nadie dice nada: los datacenters.

Gmail, youtube y demás entran en este saco. Por ejemplo, hay servidores en datacenters en algunos proveedores que vienen con un carro de direcciones (de 2 a 5), cuando todo el mundo sabe que con solo tener 1 ip te basta y te sobra. Uno puede separar por ip las distintas webs que tenga, pero todas las ip’s comparten la tarjeta de red y el ancho de banda. Aunque desde un punto de vista de seguridad pueda parecer bien, al final es el mismo hardware el que recibe todos los ataques. Así que tener distintas ip’s para distintas webs, tanto da. Con 1 sola ip puedo tener miles de webs almacenadas en la misma máquina o en distintas. Al igual que los servidores de correo.

Los servidores de correo, al menos, hacen un buen uso de las ip’s puesto que el mismo servidor de correo almacena miles de cuentas distintas de cientos de dominios (si uno confía en las soluciones de correo de un proveedor de dominios, por ejemplo).

Pero volvamos al tema de los servidores: si un servidor, por carga, no es suficiente para manejar las peticiones web, siempre se puede establecer un proxy para aceptar las peticiones y redireccionar a un cluster interno con un rango clase C (aunque los gestores de los datacenters te cobran una pasta por esa gilipollez…)

Con nginx uno puede hacer que una máquina o dos reciban peticiones sobre una sola ip, y redirigir en función del dominio a una o varias máquinas con otro rango… Fácil y en botella blanca si quieres. Para la gestión tienes 64.000 puertos para redirigir uno por uno a distintas máquinas para los distintos clientes… así que soluciones hay. Y se liberarían muchísimas ip’s.

Este es un post técnico que complementa al de cómo implementé el tema de NginX + PHP en FastCGI.

Desde siempre, dados varios bugs conocidos de php en cgi que, según la versión, hacían que los sockets fueran más o menos estables tenía un proceso en el cron del sistema que me reiniciaba el php (los sockets realmente) cada día a las 6:15 de la mañana.

A veces, cada X semanas, el php se quedaba colgado y lo reiniciábamos manualmente. NOTA: no es que el php se quedaba colgado, el tema radica en que el socket de escucha se quedaba tonto sin responder, los procesos de php seguían ejecutándose esperando cargas y peticiones (en estado suspendido). La solución al reiniciar, era que matando los procesos y rearrancando esa parte, el socket se creaba de nuevo y volvía a la normalidad.

Esto no se trata en casi ninguna web, exceptuando una: En el blog de Taragana.

Lea el resto »

Al final he podido hacerme un hueco en la vieja organización a la que pertenecía, y daré una conferencia de los temas que he tocado últimamente en este blog: sitios de web de alto rendimiento.

Y eso será en la party isleña Balearikus Party 2009, en el recinto de Ferias del Aeropuerto, la semana que viene. La party se celebra del 10 al 16, y yo daré la conferencia el Miércoles 12 a las 19h de la tarde.

Supongo que intentaré no aburrir a la audiencia siendo divertido e intentando que la peña participe.

Hablaré de Apache, NginX, php, cachés, y demás parafernalias de estos mundos.

Espero veros!

Hacía tiempo que veía una cosa extraña en la instalación del servidor: se actualizaba todo menos el paquete principal de las webs, el NginX (servidor de alto rendimiento).

Tras buscar un poco, me percaté de este hilo en los foros de Ubuntu que realmente, en ubuntu/debian no se actualizaba dicho paquete desde la versión 0.6.35 (y eso que nosotros usamos testing).

En la web, esa versión ya aparece como legacy (en plan funcionó pero está obsoleta), siendo la versión de desarrollo la 0.8.4 y la estable la 0.7.61

La verdad es que no sé por qué no se ha ido actualizando, pero veo que no es cosa nuestra, pues este programejo ya ha pasado a lighttpd en cuestión de sitios que lo tienen instalado.

Como está en inglés, ahí va la receta para actualizar desde debian/ubuntu con apt:

1. Verificar que no tengais nada referente al nginx en el /etc/apt/preferences
2. Para instalar desde 0, primero instalad la versión que os ofrece vuestra versión, desde los repositorios oficiales
3. Modificad vuestro /etc/apt/sources.list para añadir esto:
   deb http://apt.avuc.nl lenny stable
   deb-src http://apt.avuc.nl lenny stable
4. ‘Upgradeais’
5. Como el que nos provee estos paquetes es una persona diferente, compiló con otras opciones; pero solo hay que hacer:
   ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx
6. Reiniciar el nginx con vuestro script de toda la vida ( /etc/init.d/nginx)

Tras esto, ya tenemos nuestro nginx listo en la última versión.

La persona del post del foro se ha ofrecido voluntario a ir compilando las versiones estables y ponerlas en el mismo repositorio.

Actualización: se me había olvidado mencionar que, buscando cosas del nginx, me topé con este convertidor de reglas htaccess a nginx.