Desde hace muchos meses llevamos buscando opciones para mejorar el rendimiento de algunos de nuestros sites, porque cuando un web recibe mucho tráfico simultáneo, Apache no aguanta, así de claro.

El problema está en que Apache está concebido hace muuuuuchos años (15 años en Internet son muchos años) y entonces no había ni la cantidad de tráfico simultáneo actual, ni los webs servían tantos datos por cada página, por lo que las sesiones de apache se cerraban muy rápidamente.

Ahora, si un web típico en creado con WordPress tiene mucho tráfico, Apache debe gestionar cada llamada a php, cada llamada a cada include y cada llamada a cada imágen estática, … y llega un momento que las sesiones se solapan y las que debían haberse cerrado hace rato no se cierran, creando un bucle que requiere buscar soluciones que vayan más allá del simple incremento de las prestaciones del servidor.

Hace justo un año, escribía como Instalar xCache en centOS 5 – Plesk 9.2 , unos días después comentaba como ajustar un poquito xCache en Configurar y optimizar xCache y un mes después WordPress en varios servidores simultáneamente . He de confesar que Instalar xCache ha supuesto una mejora brutal, pero el doble frontal en varios servidores no tanto, es cierto que mejora, pero no lo que esperaba.

Ahora hemos instalado nginx y la mejora a vueto a ser increíble. nginx es un servidor web creado en Rusia mucho más ligero que Apache y sobre todo concebido hace un par de años y especialmente pensado para dar solución al problema de los webs con mucho tráfico (lo utilizan webs como wordpress.com, meneame.net, scribd.com, badoo.com, etc).

En que consiste la idea.
La idea de la instalación que verás mas abajo es dejar correr nginx y Apache simultáneamente. En internet te encontrarás muchas formas de instalar nginx. Esta es una más, pero creo que es la más sencilal y se lleva a cabo en muy pocos pasos y sobre todo funciona

A Apache le dejaremos que sirva todo el contenido dinámico (le asignaremos el puerto 8080) y a nginx que se encargue de cargar el contenido estáticos (le damos prioridad por el clásico puerto 80). Es como tener dos servidores web corriendo al mismo tiempo por capas del servidor diferentes.

1. Instalar yum en tu servidor:
En mi caso lo hago desde el PIM (panel de administración de los VPS del anfitrión PLESK), así que no puedo decirte como hace desde SSH, pero si he visto diferentes manuales en Internet que te ayudarán.

2. Actualizamos el repositorio EPEL del Centos x64:
Es posible que cuando leas esto haya una versión más actualizada del repositorio. En mi caso la más actual era epel-release-5-4.noarch.rpm , pero puedes verlo directamente accediendo a http://download.fedora.redhat.com/pub/epel/5Server/x86_64

Obviamente si tu servidor no es x64 sino x32 debes buscar el que le corresponda.

sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5Server/x86_64/epel-release-5-4.noarch.rpm


3. Le decimos al YUM que haga el trabajo sucio e instale todo lo necesario para poner en marcha nginx:

sudo yum install nginx

Durante el proceso preguntara varias veces, varias cosas. La respuesta debe ser siempre “Y”
Ya está instalado nginx. Ahora nos falta hacerlo compatible con Plesk y cambiar los puertos para hacer correr Apache y nginx de forma simultánea.

4. Descargamos un script para reconfigurar PLESK

cd /etc/nginx/
wget http://www.grafxsoftware.com/download/nginx/nginx_setup.zip
unzip nginx_setup.zip

Si la descarga no funcionara, he copiado ese fichero y puedes descargarlo también desde mi blog:

cd /etc/nginx/
wget http://www.fernandogomez.es/download/nginx/nginx_setup.zip
unzip nginx_setup.zip


5. Ejecutamos el fichero configurador
Revisa todos los dominios instalados y genera los scripts correspondientes de nginx para cada dominio existente en el servidor.

sh generate_nginx_conf.sh

6. Cambiamos Apache del plesk de puerto
Las líneas de horde, atmail y webmail tendrás que ejecutarlas dependiendo de si lo tienes instalado o no. Lo que no tengas instalado, te generará un error, que debes omitir.


/usr/local/psa/admin/sbin/websrvmng --set-http-port --port=8080
/usr/local/psa/admin/sbin/websrvmng --reconfigure-all
/usr/local/psa/admin/sbin/webmailmng --disable --name=horde
/usr/local/psa/admin/sbin/webmailmng --enable --name=horde
/usr/local/psa/admin/sbin/webmailmng --disable --name=atmail
/usr/local/psa/admin/sbin/webmailmng --enable --name=atmail
/usr/local/psa/admin/sbin/webmailmng --disable --name=atmailcom
/usr/local/psa/admin/sbin/webmailmng --enable --name=atmailcom
service httpd restart
service nginx restart

7. Configurar el reinicio de nginx
No puedes olvidarte de configurar tu servidor para que al reiniciar, arranque nginx. Sino lo haces, al hacer un reboot solo arrancará apache, así que no lo configuras, tus webs no funcionarán. El comando :

chkconfig –level 345 nginx on
debería funcionar, pero yo prefiero reiniciar y probar por si acaso y si no fuera, configurarlo a pelo, desde

ntsysv

Espero que el resumen te sirva lo mismo que a nosotros para mejorar el rendimiento de tus webs. Te puedo confirmar incluso que si tienes un buen SEO, esta mejora en la velocidad de carga supone un plus a la hora de posicionar tus webs. Todo esto lo he ido encontrando y compilando gracias sobre todo a:
- http://blog.jam.net.ve/2010/02/16/instalando-nginx-en-centos
- http://www.cike.ws/2010/08/11/nginx-y-plesk/

así que les agradezco desde aquí toda la info y sus artículos.

Más info acerca de nginx en : http://wiki.nginx.org

Actualización: Un tema importante que debéis tener en cuenta es que si después de instalar nginx, añades un nuevo dominio a Plesk, no funcionará correctamente, si no vuelves a repetir el proceso desde el paso 5.

Hace unas cuantas semanas, con las últimas actualizaciones de PLESK (9.2.3 y 9.3.0), cayó en nuestras manos, en nuestros servidores una pequeña petada del antivirus que también incluye Parallels cuando actualiza sus versiones: el Drweb.

Y es que de golpe y porrazo, el Dr.Web no solo envía un correo cuando hay algún problema en la actualización de su base de datos, sino que lo hace cada hora, pase lo que pase, sea correcta o no esa actualización de virus conocidos.

Además, los correos los envía a drweb@nombre_del_host.com , cuenta de correo que nadie tiene creada. Si tienes un solo servidor, quizás te cueste poco crear ese email, pero si virtualizas tu máquina y tienes unos cuantos VPS, entonces sería un suplicio ponerte a ello, además de tener en cuenta que todo eso es tráfico y ancho de banda.

La solución pasa por modificar el fichero /etc/drweb/drweb32.ini en la línea
CronSummary = {Yes | No}

Poniendo No en lugar de Yes.

Via: After upgrade Parallels Panel to version 9.2.3 Dr.Web notification deliveries start failing

Es decir, tendrás el servidor petado y al final habrás preferido tener un tráfico intermedio, porque al menos no te daba problemas. Espero que no lo hayas pensado en serio

Para incrementos de tráfico razonables, hay varias soluciones:
1/ El más simple, es reducir el peso de tu web y el número de querys a la base de datos y de llamadas a Apache.
2/ Instalar xCache u otro acelerador de php a nivel servidor.
3/ Tunear MySQL (escribiré un post sobre eso en breve)
4/ Tunear Apache (tengo otro post pendiente)

Pero cuando hay un incremento brutal de tráfico como nos ha pasado a nosotros en nuestro blog de mujer, la cosa se pone fea si no se adoptan otro tipo de medidas: Distribuir la carga entre 3 máquinas o VPS, ya que es Apache quien no es capaz de servir adecuadamente las páginas por mucha máquina que tengas.

Servidor 1/ Aquí estará la instalación inicial de WP. Mysql lo apagamos, dejamos correr Apache.
Servidor 2/ Tendremos solo Apache y una copia exacta de la instalación del Worpdress del primer servidor.
Servidor 3/ Solo Mysql. El resto de servicios apagados.
En el servidor 1 y 2, por supuesto debes configurar correctamente el xCache.

Esta es la idea. Ahora vamos a ver como ponerla en práctica:

Hay cuatro pasos:
1/ Instalación normal del WordPress en el servidor 1
2/ Cambio del Mysql al servidor 3
3/ Duplicación del contenido entre los servidores 1 y 2
4/ Balanceo y sincronización entre los servidores 1 y 2.

El paso 1.
Ni lo menciono. Te instalas tu wordpress y andando, como si nada.

El paso 2.
-  Crea un usuario y base de datos en el servidor 3.
-  Vuelca el contenido del MySQL desde el servidor 1 al servidor 3. Nosotros utilizamos el software MySQLFront. Hace la migración de la estructura y datos, rápido y bien. Yo no me complicaría la vida con comandos por SSH.
- Modifica el wp-config.php y en las líneas en las que configurar la base de datos, coloca la IP, usuario, base de datos y claves que tengas en el MySQL del servidor 3.

Asegúrate de que esa base de datos es accesible desde fuera del propio servidor. Si no sabes como se hace te recomiendo este post y este otro artículo.

Hecho esto, el apache responderá al Servidor 1 y MySQL al servidor 3.

El paso 3.
El dominio en cuestión que utilices ya está dado de alta en el servidor 1 de forma normal.
A la hora de darlo de alta en el nuevo servidor, puedes crearlo manualmente o si utilizas PLESK, utilizar el comando Migrar. Vamos a ver como sería en cada caso:

A/ Manualmente:
- Ahora da alta en el servidor 2 el mismo dominio, como si no existiera el primero.
- Accede por SSH al servidor 2. Comprueba que las rutas son las que deben ser, es decir las mismas que el servidor 1. Solo necesitamos volcar el contenido tal y como está en el servidor 1.

Para eso utilizamos el comando scp . Accede al servidor 1 por ssh, haz un tar del contenido del dominio. Luego accede al servidor 2 por ssh. Sitúate en el mismo directorio donde has hecho el tar en el otro servidor e introduce el comando:

scp root@ip-servidor1:/var/www/vhost/dominio.com/httpdocs/backup.tar .

Modificando la ip y las rutas en tu caso. Destargetea el backup y ya tienes tu contenido.

B/ Utilizando el Migrar de PLESK9.
Vas al servidor destino y utilizas el comando Migrar. Espera a que haya terminado la migración y comprueba el log de errores si que falla algo.

Hayas utilizado el procedimiento que hayas usado:
- Borra todas las DNS creadas por el servidor por defecto (en PLESK 9: Desactivar servicio)
- Crea manualmente los registros DNS de las dns que resuelvan el dominio en cuestión.
Es decir si en tu registrador tienes ns1.servidordenombres1.com y ns1.servidordenombres2.com , debes agregar esos dos registros ns, para indicarle al dominio quien va a resolver la ip del dominio son esos DNS.
- Desactiva el servicio de correo del servidor si lo tenías activado.

Ahora tenemos que volver al panel del servidor 1 y añadir una línea en las DNS.
Verás que ahora tienes un IN A www.dominio.com  a la ip del servidor 1. Debes duplicarla colocando la ip del servidor 2. De ese modo, cuando alquien llegue al dominio, puede responder una u otra ip y balancear de ese modo la carga entre ambos servidores.

Resetea Named y Apache y en unos minutos empezarás a recibir tráfico en la segunda máquina.
¿Como puedes saberlo? Accede por ssh al servidor 2 e introduce el comando


watch 'netstat -anp | grep :80 | wc -l '


De devolverte valores casi cero, pasará a mostrarte el núemro de sesiones de apache abiertas. Eso siginifica que ya empieza a responder a algunas llamadas. De todos modos, el balanceo no será proporcional hasta que pasadas 12/24 hora, se propaguen bien las dns.

El paso 4.
Ya tenemos un servidor solo para las bases de datos y la carga de Apache balanceada. Notarás la mejoría en el tiempo de respuesta de tu web, una salvajada. De repente verás como el tráfico de tu web sube y no es real, esas visitas de más son las que no eras capaz de servir por falta de máquina antes de poner en marcha todo esto.

Ahora nos falta sincronizar los contenidos.
Aqui tengo que dar las gracias a Francisco Monteagudo, por su post.  No tienes más que seguir la última parte al pie de la letra que copio aquí:

1. Desde la línea de comandos del servidor linux primario, ejecutamos: ssh-keygen -t rsa -b 4096 -f /root/.ssh/id_rsa
2. El comando anterior nos pedirá que introduzcamos una passphrase; la dejamos en blanco.
3. Ahora, en el directorio de configuración del ssh del usuario root tendremos dos ficheros, id_rsa que contiene la clave privada y id_rsa.pub que contiene la clave pública.
4. Copiamos la clave pública al servidor linux secundario, al directorio /root/.ssh
5. En el servidor secundario, vamos al directorio /root/.ssh y buscamos el fichero “authorized_keys”. Si el fichero no existe, entonces renombramos el fichero id_rsa.pub que hemos copiado del servidor primario. Si existe, lo editamos y el fichero id_rsa.pub lo añadimos como última línea.
6. Ahora volvemos al linux primario y creamos el siguiente script:
   

   #!/bin/sh
   rsync -avz secundario:/directoriouploads2 /directoriouploads1
   rsync -avz /directoriouploads1 secundario:/directoriouploads2 

   Siendo:

   • secundario: Dirección IP del servidor secundario.
   • directoriouploads1: Directorio de uploads de wordpress en el linux primario.
   • directoriouploads2: Directorio de uploads de wordpress en el linux secundario.
7. Creamos una entrada en el crontab del linux primario para que el script anterior se ejecute cada hora.

Mi recomendación es si tienes un cache de WordPress tipo 1Bloger, SuperCache, etc es que los desactives, a no ser que ejecutes la sincronización cada minuto, pero me parece demasiado.

Otra recomendación es que los editores siempre trabajen con el servidor 1. Para que no le responda unas veces el 1 y otra sel 2, debes modificar el archivo hosts que tienes en tu ordenador en la ruta  C:\WINDOWS\system32\drivers\etc\hosts , añadiendo una linea donde le indiques que para ese dominio debe acudir a la IP del servidor 1.

Creo que no me dejo nada. Si crees que se puede hacer de otro modo, te agradecería que hicieses un comentario.

1/ Instalar el administrador para ver el panel por web
Cuando explicaba como instalar el script, al final de todo, comentaba como ver a través de web el panel de administración del xcache. Te recomiento que una vez compruebes que todo está correctamente instalado, crees el panel de forma urgente (luego se te olvidará), porque ahí es donde vamos a poder ver cosas que nos den pistas de como está funcionando xCache.

2/ Funcionalidades del panel de xcache
Al acceder al panel vas a ver tres cosas:
a/ Statistics: Estadisticas y parámetros de configuración
b/ List PHP: Listado de archivos php cacheados
c/ List Var Data: Creo que se refiere a variables cacheadas, pero ni lo tengo claro, ni lo he activado.

3/ Parámetros a configurar
Para configurar los parámetros, deja correr el script al menos 5 minutos para que empiece a tomar datos y ver cosas.

a/ xcache.count
Se refiere al número de partes en als que deseas dividir el cache. Se la relaciona con el número de procesadores que tienes en tu servidor. Lo habitual es colocar nº de procesadores + 1. Puedes ver cuantos tienes en tu servidor o VPS , con el comando:
cat /proc/cpuinfo |grep -c processor


b/ xcache.size
Es uno de los parámetros clave. Fíjate en la columna OOMs (Out of Memory). Todos los valores deberían ser CERO. Si tienes valores muy bajos no deberías preocuparte demasiado, pero vigílalo. Generalmente o van a ser CERO o van a ser muy altos.

Si son altos significa que xcache hace un esfuerzo enorme y la memoria asignada no es suficiente, asi que casca (Out of memory) . Puedes ir subiendo el parámetro xcache.size .  Yo lo hago en múltiplos de 32M. De entrada puedes ponerle 64M que no pasará nada, pero tampoco debes asignarle demasiada, porque dejarás de ofrecer memoria al servidor para ejecutar otros procesos ajenos a xcache.

c/ xcache.slots
Todavía no tengo claro que es exactamente, pero lo hemos subido de 8k a 16k y hemos notado mejoras. Siempre que lo subas, debes saber que consumirá más memoria, asi que como siempre dependerá de la máquina o VPS que tengas.

d/ xcache.ttl y xcache.gc_interval
Me falta hacer pruebas con dos parámetros que también pueden ser importantes, que son xcache.ttl y xcache.gc_interval que se refieren a cada cuantos segundos se refresca el caché o se purga. Si tengo nuevos datos lo publicaré.

e/ parámetros _var
Respecto a los parámetros _var yo de momento no los tocaría. No he visto nada ni nadie que hable de ellos y al activarlo para hacer pruebas hemos perdido prestaciones.

4/ Más cosas a tener en cuenta
Además de configurar el fichero xcache.ini, debes tener en cuenta que para mejorar todavía más el rendimiento de tus webs, deberías optimizar la confioguración del propio apache  e incluso el del servidor mysql (eso es otra historia) y por supuesto dependerá de la máquina que tengas.

Tienes la doc. oficial de los parámetros en la web oficial:
http://xcache.lighttpd.net/wiki/XcacheIni

Si haces pruebas y obtienes conclusiones, me encantaría que las pudieras compartir conmigo, lo publicaré y lo compartiré con los demás.

1. Descargar la última versión estable desde SSH:
En mi caso ha sido la 1.3.0

# cd /usr/bin/
# wget http://xcache.lighttpd.net/pub/Releases/1.3.0/xcache-1.3.0.tar.gz


2. Descomprimir

# tar -zxvf xcache-1.3.0.tar.gz
# cd xcache-1.3.0


3. Compilar xcache

# phpize
Aqui tuve mis primeros problemas, ya que no tenía instalada la librería necesaria para ejecutar phpize. Si te sucede lo mismo, debes instalar la librería php-devel . Yo lo hago desde el PIM del servidor, pero puedes hacerlo con el yum.


# ./configure --enable-xcache
Al llegar aquí volví a tener problemas para compilar el código en C. Al intentarlo devuelve el error:
configure: error: no acceptable C compiler found in $PATH
se soluciona fácilmente instalando la librería gcc.


# make
Otra vez problemas. Me devuelve el error:
/usr/include/php/ext/date/lib/timelib_structs.h:24:28: error: timelib_config.h: No such file or directory

Esto si que es mucho más extraño. Solo si te devuelve este error, debes editar el fichero /usr/include/php/ext/date/lib/timelib_structs.h y modificar la linea #include <timelib_config.h> por #include "timelib_config.h" . Simplemente cambiando el corchete por comillas.

Yo lo hago con el joe, pero lo puedes hacer con vi o culaquier editor
# joe /usr/include/php/ext/date/lib/timelib_structs.h

Continuamos con la compilación
# make install

Esto lo que va a hacer es generar un fichero xcache.so que por defecto se instala en la ruta:
/usr/lib64/php/modules/xcache.so

4. Crear xcache.ini
Esta parte se puede hacer de dos formas o bien introduciendo todas las variables en el php.ini o creando el fichero xcache.ini . Yo he preferido hacerlo de la segunda forma.

# cd /etc/php.d/
# joe xcache.ini


como el fichero no existe, debes pegar lo siguiente:


[xcache-common]
; change me - 64 bit php => /usr/lib64/php/modules/xcache.so
; 32 bit php => /usr/lib/php/modules/xcache.so
zend_extension = /usr/lib64/php/modules/xcache.so

xcache.cacher = On
xcache.stat = On


5. Configurar xcache.ini
xcache te permite acceder a un panel de control a través de web, para ver las estadísticas de cacheo, urls, ratio de compresión de los php, etc. Para ello debemos introducir en xcache.admin.pass = “” el password con el que vamos a querer acceder a ese panel.

Ojo, el password ha de estar encriptado en MD5, por lo que necesitarás una herramienta online o algo similar que lo codifique. Por ejemplo, el MD5 del password “hola” es “4d186321c1a7f0f354b297e8914ab240″ . Esto último es lo que debes poner en esa variable del xcache.ini

Hay un ajuste más que debes hacer.
cat /proc/cpuinfo |grep -c processor
Esto te dice el número de procesadores que tienes en el servidor o VPS y debes colocarlo en la variable xcache.count = del xcache.ini , en nuestro caso xcache.count = 3

6. Reiniciamos Apache
# service httpd restart

7. Comprobamos que todo ha ido bien
# php -v

Si todo ha ido bien, debería devolver los parámetros de la actual instalación de PHP y deberías ver la línea “XCache v1.3.0, Copyright (c) 2005-2007, by mOo”

8. Creamos el panel de control
Copiamos el directorio /usr/bin/xcache-1.3.0/admin al directorio donde quieras verlo a través de la web. Es decir, si en ese servidor tienes un dominio www.dominio.com y su ruta es /var/www/vhosts/dominio.com/httpdocs/ , deberás crear ahí un directorio admin y copiar el contenido original. De ese modo desde www.dominio.com/admin accderás con el user=”admin” y el pass que has colocado en el paso 5.

# mkdir /var/www/vhosts/dominio.com/httpdocs/admin
# cp -R admin/* /var/www/vhosts/dominio.com/httpdocs/admin/

Nosotros en nuestro web del eurobasket, hemos notado nada más instalarlo una mejoría brutal en la velocidad de acceso. En algunas páginas como las “resultados eurobasket” o “calendario eurobasket” el cacheo ha sido espectacular ya que han sido unas de las mas vistas. No creo que sea casualidad tampoco que desde hoy hayamos duplicado el tráfico de estos días.