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.
Comentarios RSS 
Trackback
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.
Comentarios RSS Trackback
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.
Comentarios RSS Trackback
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.
Comentarios RSS Trackback
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!
Comentarios RSS Trackback
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:
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.
Comentarios RSS Trackback
