Hace aproximadamente dos meses comencé a leer cómo HHVM podía convertirse en todo un componente mágico para acelerar el rendimiento de cualquier blog en WordPress, y me puse manos a la obra para hacer mis pruebas y migrar Incognitosis a este tipo de infraestructura.

Hasta la fecha hacía uso de una instalación en la que combinaba Nginx, PHP-FPM, APC y MySQL para servir este y algún otro proyecto en mi VPS, pero las promesas de HHVM parecían dejar atrás lo conseguido por esa configuración (que ya de por sí era bastante decente). No acababa de creérmelo, pero una simple consulta en el servicio whichloadsfaster.com (por alguna razón el servicio ya no está accesible en los últimos días) ya me daba un resultado claro: una copia exacta de Incognitosis en otro dominio cargaba entre dos y tres veces más rápido que la original de forma consistente.

Una vez controlado el proceso, me he decidido a escribir una guía que quizás os sirva para poner en marcha vuestro propio VPS y aprovechar este tipo de configuración. Debo avisar de que mi intención no es la de convertir este post en un foro de soporte: estos son los pasos que a mi me han funcionado, y aunque en teoría debería ocurrir lo mismo si los seguís, puede que surjan problemas que os hagan quedaros parados en algún paso o no obtener el rendimiento final que esperábais. Hay numerosos foros y referencias a los que acudir en estos casos (incluiré algunos al final), y aunque puedo intentar contestar a alguna cuestión, este post es básicamente informativo.

En mi caso las pruebas han sido realizadas en mi actual proveedor de hosting, Gigas, que destaca por ser una empresa española que tiene servidores en España -algo útil para reducir latencia si vuestros lectores son de por aquí- y que ofrece un servicio notable. De hecho, la puesta en marcha de un VPS es muy sencilla, y tras contratarlo os encontraréis con una serie de opciones para preinstalar el sistema operativo que más rabia os dé.

Hay varias opciones, pero tras leer diversos tutoriales yo me decidí por utilizar Ubuntu 12.04 LTS, una distribución ya veterana pero solvente en temas servidores. Me hubiera gustado más dar el salto directo a Ubuntu 14.04 LTS, pero de momento no la ofrecen de serie en Gigas. Uno siempre puede elegir la 12.04 y luego utilizar el comando ‘do-release-upgrade‘ para actualizar a 14.04 nada más iniciar sesión, pero yo he preferido dejar todo tal cual para evitar posibles conflictos con dependencias de paquetes.

Nota importante: a la hora de elegir una distribución Linux para proceder a la instalación, tened en cuenta que HHVM solo está soportado en sistemas de 64 bits. No podréis instalarlo en distros de 32 bits.

---

 

Comienza la instalación

Una vez estamos conectados a nuestro VPS vía SSH comenzamos a preparar el servidor de forma adecuada. Lo primero, desde luego, es actualizar los paquetes de la distribución:

apt-get update && apt-get upgrade

Eso hará que se actualice la lista de paquetes disponibles y que, probablemente, el sistema nos sugiera actualizar aquellos que sean más modernos que los preinstalados. Basta con aceptar los cambios, ya que la opción Sí (Yes) está predefinida: solo tendremos que pulsar Enter cuando se nos solicite respuesta a esa pregunta.

 Ahora nos crearemos un usuario para el resto de procesos: ya sabéis que hacer uso de la cuenta de superusuario es bastante poco recomendable. Para ello creamos el usuario:

adduser javipas

Este comando creará la cuenta de usuario, el directorio raíz, y nos pedirá que introduzcamos dos veces la contraseña de ese usuario (la que deseemos asignarle). Esa contraseña será utilizada para todos los comandos sudo que vayamos a utilizar en el futuro, además de permitirnos logarnos vía SSH (a no ser que utilicemos el método opcional de las claves SSH, más recomendable).

Para poder ejecutar comandos con sudo, tendremos que efectuar un cambio en los usuarios que están habilitados para usar dicha capacidad:

visudo

Y en el editor que aparece, tendremos que añadir una línea más debajo de

root     ALL=(ALL:ALL) ALL
javipas  ALL=(ALL:ALL) ALL

Tras lo cual pulsamos Ctrl+o para grabar, Enter y Ctrl+x para salir del editor. Ya podremos ejecutar comandos con privilegios de superusuario, así que ahora no nos hace falta poder acceder como usuario root. Por lo tanto, cambiamos la configuración de acceso vía SSH. Para ello

nano /etc/ssh/sshd_config

Y en el editor que nos aparece tendremos que cambiar ‘PermitRootLogin yes‘ por

PermitRootLogin no

Tras lo cual volvemos a salvar y salir (Ctrl+o, Enter, Ctrl+x) y reiniciamos el servidor SSH:

service ssh restart

Añadimos algo de seguridad al servidor mediante la instalación del paquete fail2ban, una aplicación que veta el acceso a ciertas IPs si éstas intentan acceder a nuestro servidor demasiadas veces seguidas y no introducen la contraseña adecuada.

apt-get install fail2ban

También podemos poner en marcha el cortafuegos o firewall que en Ubuntu está preinstalado gracias al pequeño ufw, y que nos permite habilitar tan solo los puertos que vamos a utilizar: el 22 (para SSH), el 80 (para tráfico HTTP) y el 443 (para tráfico HTTPS):

ufw allow 22
ufw allow 80
ufw allow 443
ufw enable

Para terminar de completar esa configuración inicial, yo tengo algunas pequeñas manías, como establecer el nombre de mi servidor:

echo "zipi" > /etc/hostname
hostname -F /etc/hostname

Además editamos el fichero /etc/hosts

nano /etc/hosts

Y editamos la línea (cambiar la IP por la de vuestro servidor) incluyendo tanto el nombre que hemos elegido para nuestra máquina (en mi caso, ‘zipi’) como la URL de la principal página web que alojaremos (por ejemplo, ‘javipas.com’ con y sin el “www”):

5.56.58.85 zipi javipas.com www.javipas.com

Y ahora nos aseguramos de configurar la zona horaria,

dpkg-reconfigure tzdata

Y elegimos la zona, en mi caso, Europe / Madrid

Por comodidad, editamos el fichero .bashrc para añadir nuestros alias y nuestros colores

cd
nano .bashrc

Y añadimos las líneas siguientes (en mi caso, un alias para ‘dir’ y los colores para mi shell)

alias dir='ls -la'
export PS1="\[\e[32;1m\]\u\[\e[0m\]\[\e[32m\]@\h\[\e[36m\]\w \[\e[33m\]\$ \[\e[0m\]"

En realidad hemos aplicado los cambios en el .bashrc del superusuario, pero también quiero aplicarlos en el mismo fichero de mi usuario anteriormente creado. Para ello y apodemos abrir una nueva sesión SSH, pero esta vez deberemos entrar con el usuario ‘javipas’ y la contraseña que le hemos asignado al crear el usuario. Eso hará que aparezca ante nosotros el prompt tradicional de usuarios convencionales (el símbolo del dólar, ‘$’, en lugar de la almohadilla, ‘#’) y podremos introducir los mismos comandos que nos permitirán crear el alias y los colores de sesión que hacen algo más visual la consola de comandos:

nano .bashrc

Y añadimos las dos líneas anteriormente indicadas con el alias y la variable PS1 a exportar. Esos cambios se aplicarían de serie tras un nuevo inicio de sesión, pero para ahorrarnos salir y volver a entrar, lo más fácil es introducir el comando siguiente:

source .bashrc

Tras lo cual ya estaremos controlando la cuenta de usuario convencional pero preparada para que estemos ya cómodos ante la instalación del resto del servidor.

---

 

Instalación de Nginx con Pagespeed

A continuación comenzamos a instalar todos los componentes del servidor. Comenzamos con Nginx, pero no una versión cualquiera de este servidor web, sino una precompilada que tiene la peculiaridad de que incluye el módulo Pagespeed. Este módulo aplica varias técnicas de optimización de nuestro servidor web para que todo vaya más rápido.

Lo normal es que tuviéramos que compilar por separado Nginx y luego el módulo, pero gracias al esfuerzo de algunos usuarios existen paquetes preparados para Ubuntu 12.04 LTS. En concreto usaremos los paquetes de Kura, y simplemente tendremos que introducir los siguientes comandos:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys D38F85FF650A63B9
sudo wget https://apt.kura.io/`lsb_release -cs`.list -O /etc/apt/sources.list.d/apt.kura.io.list
sudo apt-get update
sudo apt-get upgrade --show-upgraded
sudo apt-get install nginx
sudo /etc/init.d/nginx restart

El servidor ya está funcionando, y de hecho si metemos en un navegador la IP (http://5.56.58.85 en mi caso) de nuestro servidor VPS veremos el mensaje por defecto de cada instalación de Nginx, un ‘Welcome to nginx!‘ que demuestra que tod va por buen camino. No obstante, tenemos que indicarle al servidor que haga buen uso del módulo PageSpeed. Para ello editamos el fichero de configuración principal de Nginx,

sudo nano /etc/nginx/nginx.conf

y añadimos las siguientes líneas dentro de la sección ‘server‘ y, si no la hay, dentro de la sección ‘http‘:

server {
    # ...
    pagespeed on;
    pagespeed RewriteLevel CoreFilters;
    pagespeed FileCachePath "/var/cache/ngx_pagespeed/";
    pagespeed EnableFilters combine_css,combine_javascript,remove_comments,collapse_whitespace;

    server_names_hash_bucket_size 64;
    # ...
}

Esa última línea extra en la que modifico el parámetro hash_bucket_size, por cierto, es necesaria porque más adelante utilizaré un nombre de dominio que de otro modo no podría utilizar. Podéis no incluirla, pero si en algún momento hacéis un ‘sudo nginx -t’ para evaluar si la configuración de nginx es correcta, puede que os aparezca un error del tipo: 

javipas@zipi~ $ sudo nginx -t
nginx: [emerg] could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32
nginx: configuration file /etc/nginx/nginx.conf test failed

Sigamos. Ahora es obligatorio preparar el directorio en donde PageSpeed necesitará colocar su caché y asignarle los permisos adecuados,

sudo mkdir /var/cache/ngx_pagespeed/
sudo chown www-data:www-data /var/cache/ngx_pagespeed/

Y tras esto podemos volver a reiniciar el servidor,

sudo service nginx restart

La prueba evidente de que nuestro servidor ya está sirviendo páginas con el módulo PageSpeed activado es una simple visita vía curl:

curl -I 'http://localhost/index.html' | grep X-Page-Speed

O bien con un comando similar:

curl -I 'http://5.56.58.85/' | grep "Speed" -i

Lo que nos mostrará una línea final en el que se confirma el uso del módulo PageSpeed, en este caso con versión 1.8.31.4-4009.

---

 

Instalación de MariaDB

Ahora procederemos a la instalación del servidor de bases de datos MariaDB, un proyecto derivado de MySQL que está mejor considerado por la comunidad Open Source sobre todo por la ausencia de la dependencia de Oracle. Para proceder ejecutamos los siguientes comandos:

sudo apt-get install python-software-properties
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
sudo add-apt-repository 'deb http://tweedo.com/mirror/mariadb/repo/10.1/ubuntu precise main'
sudo apt-get update
sudo apt-get install mariadb-server

Este último comando nos pedirá una contraseña para el administrador de bases de datos, que será necesaria para poder realizar cambios en la gestión de este apartado, y que deberemos elegir con sumo cuidado. Una vez completada la instalación conviene “asegurarla” con el siguiente comando:

mysql_secure_installation

Lo que hará que se nos pregunten algunas cuestiones. En primer lugar se nos pedirá la contraseña de administrador (la que acabamos de elegir en el paso anterior), para luego sugerirnos que cambiemos esa contraseña.

En ese momento hay que pulsar la tecla n y luego Enter para evitar tener que elegir otra contraseña. A partir de ahí el resto de preguntas pueden ser respondidas directamente pulsando Enter para elegir las respuestas predefinidas.

---

 

Instalando HHVM

Como sucede en el caso de Nginx con el módulo PageSpeed, podemos encontrar paquetes precompilados de HHVM para Ubuntu 12.04. Por lo tanto, el proceso se simplifica de forma importante, y la secuencia de comandos que deberemos ejecutar es la siguiente:

sudo add-apt-repository ppa:mapnik/boost
wget -O - http://dl.hhvm.com/conf/hhvm.gpg.key | sudo apt-key add -
echo deb http://dl.hhvm.com/ubuntu precise main | sudo tee /etc/apt/sources.list.d/hhvm.list
sudo apt-get update
sudo apt-get install hhvm

Este primer conjunto de comandos añaden el repositorio en el que están los paquetes precompilados, añaden la clave de acceso al repositorio, actualizan la lista de repositorios y luego la lista de paquetes para, finalmente, instalar el paquete hhvm y sus dependencias.

Como se puede ver, tras la instalación se muestra información interesante sobre HHVM y la necesidad de completar esa instalación. Y esa es precisamente la segunda parte: tendremos que ejecutar un pequeño script que hace posible que HHVM y Nginx trabajen juntos. Para ello tendremos que ejecutar los siguientes comandos:

sudo apt-get install libboost1.49-dev libboost-regex1.49-dev libboost-system1.49-dev libboost-program-options1.49-dev libboost-filesystem1.49-dev libboost-thread1.49-dev
sudo /usr/share/hhvm/install_fastcgi.sh
sudo /etc/init.d/hhvm restart
sudo /etc/init.d/nginx restart

Esto ya deja todo preparado para nuestra instalación de WordPress, pero antes, una pequeña comprobación. Vamos a crear un pequeño fichero phpinfo.php en la raíz de nuestra carpeta por defecto en el servidor web:

sudo nano /usr/share/nginx/html/phpinfo.php

Y vamos a introducir una sola línea en el editor:

<?php phpinfo(); ?>

Salvamos el fichero, salimos, y en el navegador cargamos la URL http://nuestraip/phpinfo.php. Eso hará que aparezca un simple pero importante mensaje:

Tras lo cual podremos estar seguros de que Nginx y HHVM (HipHop Virtual Machine) están trabajando en perfecta armonía. Para evitar futuros conflictos, enlazamos PHP con HHVM con el siguiente comando:

 sudo ln -s $(which hhvm) /usr/local/bin/php

(Si no os deja realizar esta operación, haced un ‘su –‘, introducid la contraseña de root, ejecutad el comando y salid de esa cuenta con un ‘exit‘).

Tras ello, podemos asegurarnos de que efectivamente el intérprete PHP no es en realidad el original, y que HHVM se encarga de todo:

 php -v

Actualización (19/03/2015): Atentos a un último detalle que he descubierto al tratar de utilizar esta guía en otro sitio web con WordPress. Parece ser que ha surgido un problema con HHVM y MySQL/MariaDB cuando tratas de conectarte a una base de datos en tu propio servidor y usas para ello lo de ‘localhost’. Eso provoca que cuando tratas siquiera de instalar WordPress y acceder por primera vez a la web para que te muestre el formulario con lo del nombre del sitio web, nombre de usuario del administrador y contraseña te salga un horroroso “Error establishing connection with the database“. Si te ocurre, hay una forma sencilla de solucionarlo: Editar el fichero /etc/hhvm/php.ini y añadir la siguiente línea: 

hhvm.mysql.socket = /var/run/mysqld/mysqld.sock

Tras lo cual, eso sí, tendréis que reiniciar de nuevo el servicio: 

sudo service hhvm restart

Sin olvidar que también queremos que si la máquina se reinicia, también lo haga el servicio HHVM:

sudo update-rc.d hhvm defaults

Y ya podréis continuar con el funcionamiento normal. Fiu. 

---

 

Instalando WordPress

Nuestro servidor ya está preparado para que instalemos nuestro blog y éste funcione de forma perfecta (¡esperemos!). En este punto hay diversas opciones, y de hecho podremos instalar todo el directorio raíz del sitio web por defecto de Nginx (/usr/share/nginx/html), pero en mi caso suelo instalar varios sitios web en un mismo VPS, y prefiero tenerlos todos en otro directorio más tradicional, en concreto en /var/www/. Cada sitio web ocuparía su propio directorio, de modo que Incognitosis iría en /var/www/javipas.com, y Osphérica iría en /var/www/ospherica.es (aunque podéis nombrar a los directorios como queráis, claro).

Dado que ya tengo instalado Incognitosis en otro lado, voy a hacer uso de otro dominio que compré hace tiempo y que no he llegado a usar, lastresjotas.com, para estas pruebas. No es el objetivo de este artículo explicar cómo lograr que ese dominio apunte a mi servidor, pero en cualquier caso, basta con configurar la IP de mi VPS (en este caso, 5.56.58.85) en el registrador de dominios, creando dos entradas DNS de clase A, una con lastresjotas.com como entrada, y otra con www.lastresjotas.com. En mi registrador en este caso, PiensaSolutions, la configuración queda de la siguiente forma:

Con eso ya tenemos la parte de las DNS configuradas, pero claro, queda configurar nuestro VPS y, en concreto, nuestro servidor Nginx. Para ello creamos un nuevo fichero de configuración:

sudo nano /etc/nginx/sites-available/lastresjotas.com

E insertamos las siguientes líneas:

server {
 server_name lastresjotas.com www.lastresjotas.com;
 listen 80;
 root /var/www/lastresjotas.com/public_html;
 access_log /var/www/lastresjotas.com/logs/access.log;
 error_log /var/www/lastresjotas.com/logs/error.log;
 index index.php;

include hhvm.conf;

location / {
    try_files $uri $uri/ /index.php?q=$uri&$args;
    }

location ~* \.(jpg|jpeg|gif|css|png|js|ico|png|svg|zip|woff|gz)$ {
    access_log off;
    expires 1y;
    }

location ~ /\.ht {
    deny all;
    }

location ~ \.php$ {
    fastcgi_index index.php;
    fastcgi_keep_conn on;
    include /etc/nginx/fastcgi_params;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Y creamos un enlace desde el directorio /etc/nginx/sites-enabled para que Nginx sepa que ese nuevo sitio web estará habilitado:

sudo ln -s /etc/nginx/sites-available/lastresjotas.com /etc/nginx/sites-enabled/lastresjotas.com

Ahora deberemos crear los directorios que le hemos indicado en ese fichero de configuración que usaremos como destinos para los registros de acceso y errores y, por supuesto, como raíz de nuestro sitio web:

sudo mkdir -p /var/www/lastresjotas.com/{logs,public_html}
sudo chown -R www-data:www-data /var/www/

Y ahora instalamos WordPress en public_html:

cd /var/www/lastresjotas.com/public_html
sudo wget http://wordpress.org/latest.tar.gz
sudo tar -xvzf latest.tar.gz
sudo mv wordpress/* .
sudo rm -rf wordpress
sudo rm latest.tar.gz

Es el momento de crear la base de datos para nuestro blog. Para ello, entramos en el gestor de base de datos con el siguiente comando (se nos pedirá la contraseña del administrador de la base de datos):

mysql -uroot -p

Tras lo cual podremos crear la base de datos y dejarla preparada con los siguientes comandos. Atención a dos cosas: 1) El uso de mayúsculas es opcional, pero no os olvidéis de los puntos y coma salvo en el exit final, y 2) elegid de nuevo una contraseña específica para esa base de datos que solo afectará a ese blog en particular.

CREATE DATABASE WP_blog;
GRANT ALL PRIVILEGES ON WP_blog.* TO wp_blog@localhost IDENTIFIED BY 'unacontrasena';
FLUSH PRIVILEGES;
exit

 

Con esto ya tendremos esa parte preparada, y ahora falta indicarle a WordPress que esa es precisamente la base de datos que queremos utilizar. Para ello, creamos el fichero wp-config.php en el que se encuentran esos datos:

mv wp-config-sample.php wp-config.php
nano wp-config.php

Y como se ve en la imagen, añadimos en ese fichero los datos de la base de datos que acabamos de crear. Ahora nos aseguramos de que el directorio raíz tiene los propietarios adecuados, y reiniciamos nginx:

cd /var/www/lastresjotas.com
sudo chown -R www-data:www-data public_html/
sudo service nginx restart

y ya podremos acceder a la instalación de WordPress, primero para completarla, haciendo que nuestro navegador vaya a

http://lastresjotas.com/

Si esa URL no funciona, probad con ‘http://lastresjotas.com/wp-admin/install.php‘ Tras lo cual se nos pedirá el nombre del blog, el nombre del administrador, una contraseña y una dirección de correo electrónico.

Una vez completados esos pasos, WordPress nos presentará la confirmación final para que podamos entrar al panel de control (Dashboard) de nuestro blog, y, por supuesto, al blog propiamente dicho. ¡Listo!

---

Eso completaría esa instalación inicial, aunque no está de más dar algunos apuntes más. ¿Verdad?

---

 

Cómo clonar javipas.com en lastresjotas.com

Para realizar las pruebas de rendimiento quise copiar la estructura de Incognitosis de forma completa incluyendo la base de datos. De ese modo podría analizar cuál de ellas cargaba más rápido y cuál menos teniendo garantizado que en ambos casos se accedía a los mismos datos. El proceso es relativamente sencillo y consta de los siguientes pasos:

1. En el VPS origen (donde está el sitio javipas.com original)
   1. Crear un backup del directorio raíz de javipas.com
   2. Transferirlo al VPS destino
   3. Crear un backup de la base de datos de javipas.com
   4. Transferirlo al VPS destino
2. En el VPS destino (donde está el sitio lastresjotas.com)
   1. Realizar las sustituciones del dominio antiguo (javipas.com) al dominio nuevo (lastresjotas.com) en la base de datos del VPS destino

Vamos a ello. Tened en cuenta que al utilizar el comando scp especifico el directorio hogar de mi usuario en la máquina remota (el VPS donde está lastresjotas.com porque así me aseguro de que no habrá problemas de permisos al transferir esos ficheros al directorio deseado).

sudo tar -czf public-javipas-19092014.tar.gz public_html
scp -v -r public-javipas-19092014.tar.gz javipas@5.56.58.85:/home/javipas/
mysqldump -uroot -p WP_javipas > WP_javipas-19092014.sql
scp -v -r WP_javipas-19092014.sql javipas@5.56.58.85:/home/javipas/

Y en la máquina destino (donde está nuestro lastresjotas.com):

cd /home/javipas
sudo mv public-javipas-19092014.tar.gz WP_javipas-19092014.sql /var/www/lastresjotas.com/
sudo mv public_html oldpublic_html
sudo tar xzvf public-javipas-19092014.tar.gz

Antes de volcar la base de datos creamos una copia de la antigua:

sudo mysqldump -uroot -p WP_blog > /home/javipas/WP_blog-19092014-sql

Y ahora sí, realizamos el volcado:

mysql -uroot -p WP_blog < WP_javipas-19092014.sql

Debemos tener en cuenta que el fichero de configuración de WordPress no es el que tenemos en public_html, sino el que teníamos en oldpublic_html. Simplemente lo copiamos de un sitio a otro:

sudo cp oldpublic_html/wp-config.php public_html/

Y ahora viene el apartado clave: las sustituciones en la base de datos, que son cuatro y que deberemos realizar para que todo parezca que es Incognitosis, salvo las URLs, que siguen estando siempre en formato lastresjotas.com/loquesea.

Nos metemos en el gestor de bases de datos MariaDB:

mysql -uroot -p

Nos pide como siempre la contraseña del administrador, la introducimos y eso nos lleva al prompt de MariaDB, a partir de lo cual ejecutamos los siguientes comandos:

use WP_blog;

UPDATE wp_posts SET post_content = REPLACE (post_content, 'http://www.javipas.com','http://lastresjotas.com');

UPDATE wp_posts SET guid = REPLACE (guid, 'http://www.javipas.com','http://lastresjotas.com');

UPDATE wp_options SET option_value = REPLACE (option_value, 'http://www.javipas.com','http://lastresjotas.com');

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'http://www.javipas.com','http://lastresjotas.com');

exit

Ya podéis recargar el sitio web lastresjotas.com (o en vuestro caso, el dominio o subdominio elegido), y veréis como tenéis una copia exacta del dominio original en el sitio que acabáis de crear. Puede que como mucho os encontréis con que el idioma en el que se muestran algunos términos (fechas, ‘comments’ esté en inglés). Para resolverlo, editad el fichero wp-config.php y meted es_ES en la variable WP_LANG:

nano /var/www/lastresjotas.com/public_html/wp-config.php

Y allí cambiad

define('WPLANG', '');

por (o incluid la siguiente línea si no estaba):

define('WPLANG', 'es_ES');

Fijaos en la URL. Por lo demás, copia exacta de Incognitosis.

Listo, vuesto blog, también en español en todos los apartaditos. Muy útil para migraciones o para establecer entornos de pruebas.

---

 

Optimizaciones de Nginx

Nuestro servidor está listo, pero no del todo optimizado. Aunque hay muchos pequeños flecos que se pueden perfilar, hay algunos especialmente sencillos de tratar. Uno de los más claros es la optimización del servidor web Nginx a través de pequeños parámetros y ayudas.

Si nos damos una vuelta por PageSpeed Insights e introducimos la URL de nuestra web (en nuestro caso, http://NuestraIP, a secas) aparecerán unos valores decentes para la versión móvil (68 en mis pruebas) y la versión de escritorio (82). Este servicio de Google nos da pistas sobre qué cosas corregir, y la primera y más evidente es habilitar la compresión. Para ello nos vamos al fichero de configuración de Nginx:

sudo nano /etc/nginx/nginx.conf

Y tras las líneas:

gzip on;
gzip_disable "msie6";

Introducimos las siguientes:

gzip_comp_level 2;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/x-javascript text/xml text/css application/xml;

Tras lo cual salvamos y salimos. Si ahora reiniciamos el servidor Nginx con el tradicional ‘sudo service nginx restart‘ y volvemos a analizar la página en PageSpeed Insight, veremos algo sorprendente: la calificación móvil ha pasado a ser de 79 para la versión móvil y de 93 para la de escritorio. Ahí es nada.

Podemos hacer alguna optimización rápida más en Nginx, como por ejemplo establecer el número correcto de worker_processes y de worker_connections. Para ello ejecutamos estos dos comandos:

grep processor /proc/cpuinfo | wc -l
ulimit -n

Lo que nos dará dos valores. Editaremos de nuevo el anterior fichero con el ya conocido

sudo nano /etc/nginx/nginx.conf

E introduciremos el primer valor en worker_processes (en mi caso, “2”) y el segundo en worker_connections (en mi caso, 1024).

worker_processes 2;
worker_connections 1024;

Tras lo cual tendremos que reiniciar el servidor Nginx para aplicar los cambios:

sudo service nginx restart

También podremos añadir una fecha de caducidad a ciertos recursos para que éstos no se tengan que cargar de forma continua en cada visita, y que los navegadores los cacheen para reducir los tiempos de carga. Para ello editamos el fichero de configuración de nuestro blog,

sudo nano /etc/nginx/sites-enabled/default

Y añadimos las siguientes líneas dentro de la sección ‘server‘:

location ~* \.(js|css|png|jpg|jpeg|gif|ico|woff|ttf|svg|otf)$ {
   expires 30d;
   add_header Pragma public;
   add_header Cache-Control "public";
}

Tras lo cual volvemos a reinicar el servidor como antes. Hay algunas optimizaciones más que explican muy bien en este documento de DigitalOcean, pero en general con estas mejoras lograremos ya avances sensibles en la mejora del rendimiento y eficiencia de nuestro servidor web.

---

 

¿Cuál es la mejora de velocidad?

Lo de escribir esta guía se me ocurrió hace un par de días, pero cometí un fallo al planteármela: las pruebas de rendimiento tenía que haberlas pasado antes de la migración que llevé a cabo el viernes 12 de septiembre (y de la que no dije nada por si las moscas). Tenía que haber dejado el servidor original (algo más lento), pasar las pruebas con el servidor de pruebas (ya actualizado con todo esto) y guardar los datos, pero no lo hice. De hecho, solo tengo una captura válida que ya compartí en Twitter el 20 de agosto:

Ese es básicamente el resumen de la mejora de velocidad, que se mantenía tanto en la home como en varios de los artículos de Incognitosis que probé a cargar en el blog original y en el de pruebas. El servicio para compararlos, WhichLoadsFaster, ha desaparecido misteriosamente del mapa, pero el problema ya no es ese: es que no dispongo de una copia del servidor original y tendría que ponerme a instalar todo de nuevo como estaba en el servidor de pruebas (Debian 6  64 bits + Nginx + PHP-FPM5 + APC + Varnish + MySQL) para luego comparar rendimientos usando algún servicio de pruebas de estrés como LoadImpact, que ahora mismo da el siguiente resultado para este servidor de pruebas con lastresjotas.com:

Las pruebas de estrés no son mi fuerte (y eso de que esa prueba se ejecute desde Australia no ayuda a la carga, coñe, os aseguro que no tarda 4 segundos ni de lejos desde España), y sí que estaba más enfocado a comprobar si podía lograr “puntuaciones perfectas” en servicios como PageSpeed Insight, de los que ya he hablado en alguna ocasión, o en aplicaciones/extensiones similares como la fantástica YSlow para Firefox. Hay otros muchos servicios que dan pistas de donde se puede mejorar -yo destacaría sobre todo a Pingdom Tools, prodigioso-, pero incluso con esas indicaciones la mejora puede no depender de ti. De hecho, problemas como el famoso ‘Leverage browser caching‘ que suelen indicar en PageSpeed Insight y que tiene ayuda asociada es difícilmente controlable porque son componentes JavaScript que dependen de terceras partes (como Google Analytics) y que no se pueden solventar sin meter mano de forma incómoda a nuestro servidor.

---

 

CDNs, plugins de caché y otros

A todas estas ventajas que ofrece la combinación de HHVM con PageSpeed y Nginx se les pueden sumar otras muchas. He estado probando el efecto de utilizar el CDN propio de WordPress (Photon, que se puede activar vía el fantástico e imprescindible plugin JetPack), y lo he combinado con el uso del plugin WP Super Cache, un viejo conocido de los usuarios de WordPress.

La guía completa la tienen en DigitalOcean (no tengo fuerzas de adaptarla, no es difícil de seguir), y el problema es que tampoco he tenido tiempo de comprobar si la mejora es especialmente notable. Debería serlo, pero al menos en PageSpeed Insights no he logrado mayores puntuaciones (o imperceptibles, si no recuerdo mal) activando estas mejoras.

El problema es que aunque de cara al usuario todo va mejor activando el CDN y WP Super Cache, para el propietario del sitio y sobre todo para mi desarrolladora web (¡pipi!) trabajar con un sitio con caché activada es un tostón. Sobre todo porque a pesar de que desactivas la caché para usuarios internos del blog (opción que efectivamente está presente), hacer cambios en producción y tratar de verlos es toda una odisea.

A eso se suma el hecho de que en cuanto activé esas dos opciones dejé de poder incrustar imágenes más anchas que el ancho de la columna de texto, lo cual es un problema grave para ilustrar, por ejemplo, este artículo. No daba con la tecla tras tratar de solucionarlo, así que acabé optando por la solución fácil: desactivar Photon, y desactivar WP Super Cache. A ver si alguien es capaz de darme alguna pista para tratar de resolverlo y volver a activar ambos recursos.

Aparte de utilizar un CDN y un plugin de caché -los hay muy famosos en ambas divisiones, y de hecho creo que voy a intentar probar Cloudflare, pero paso de un insondable para mi W3 Total Cache- hay otras posibles mejoras y optimizaciones. No he tocado mucho más la configuración de Nginx, pero desde luego hay cosas que se pueden pulir, y lo mismo ocurre con MySQL o con cosas tan curiosas como el cacheo de Gravatar, que por cierto, a mi no me funcionó con un plugin que probé (y que no logro recordar ahora cuál es). Temas como hacer minify de CSS y JavaScript es igualmente muy popular en debates webperformance y en los servicios mencionados (hay plugins específicos, pero los que yo he probado, de nuevo, me han dado más problemas que ventajas por conflictos con mi querido editor frontend),  y también es muy conocida la optimización de imágenes (yo ahí me lo curro bastante, sobre todo porque uso imágenes de 1.440 x 500 px para abrir los artículos de Incognitosis).

Hay literalmente cientos de guías y tutoriales sobre Web Performance que os podéis aplicar, y hay muchos recursos –aquí un buen ejemplo– si lo que queréis es acelerar específicamente WordPress, como es mi caso. La guía de Vladimir Prelovac es una de las más conocidas (al menos, en mi caso) y cubre varios pasos importantes de forma más o menos ligera, pero si os queréis empapar del tema yo seguiría a gente como Ilya Grigoryk, un ingeniero de Google y absoluta referencia en Web Performance que va soltando perlas frecuentemente en su cuenta de Google+.

---

 

Posibles problemas

He ido probando cada uno de los pasos que habéis visto en este tutorial, pero es posible que me haya podido despistar en algún momento. Especialmente delicados son los permisos y propietarios de los directorios, algo que puede volverse un poco raruno si estamos clonando sitios web de un servidor a otro.

En la documentación oficial de WordPress explican cómo deben ser estos permisos, y este hilo de discusión en StackOverflow permite configurar correctamente los permisos de nuestro directorio raíz con un par de instrucciones. Pero atentos, porque como decía no solo es cuestión también de permisos, sino de los propietarios de esos directorios. Si os fijáis en el fichero /etc/nginx/nginx.conf, el usuario del servidor, definido en la primera línea, suele ser www-data (cuyo grupo es también www-data):

user www-data;

Por lo que es conveniente que el propietario de ese directorio raíz en nuestra web sea también este. Esa es la razón de que hagamos un

chown -R www-data:www-data /var/www/lastresjotas.com/

para asegurarnos de que Nginx va a poder funcionar perfecto en ese directorio y, por ejemplo, podremos subir imágenes para insertarlas en el blog. Eso plantea un problema, y es queremos editar los ficheros de configuración con algún editor HTML con cliente FTP integrado, no podremos hacerlo ya que nuestro usuario de acceso (al que habíamos creado cuenta con contraseña para acceso vía SSH) es en este caso ‘javipas‘.

Solo podríamos hacerlo como root (y luego habría que volver a cambiar el propietario del fichero editado a www-data), lo que se vuelve algo engorroso. Aquí siempre me quedan dudas, así que si tenéis sugerencias, bienvenidas sean, porque está claro que hay solución pero yo no la he encontrado aún.

También parece haber algún problema o conflicto con HHVM y el módulo PageSpeed de Nginx. Ya he tenido algún que otro susto porque de repente Incognitosis (la real, ya funcionando con esta misma configuración) dejaba de estar accesible. Para cuando me daba cuenta un rato después me conectaba por SSH y comprobaba que estaba todo funcionando… excepto el servicio HHVM, que estaba inexplicablemente parado. La solución es fácil, y basta con hacer un

sudo service hhvm restart

Tras lo cual todo volverá a la normalidad, pero claro, uno tiene que enterarse de que hay problemas.

En mi caso, acabo de crear una cuenta en UptimeRobot, un servicio clásico de monitorización que hace ping a la URL que le indiques y te manda mail si detecta que algo va mal. Es gratuito y veremos qué tal funciona, pero hay alternativas en este caso y espero que al menos así si hay parón lo pueda detectar más rápido para que no os quedéis sin poder accceder. Disculpas por los problemas, estoy tratando de consultarlo pero de momento no encuentro respuesta.

---

 Monitorizando tu servidor: monit al rescate

Desde que puse en marcha toda la nueva infraestructura del servidor de Incognitosis he estado sufriendo diversas caídas que, como mencionaba, tenían que ver con HHVM. Por alguna causa que aún no he logrado descubrir HHVM deja de funcionar y hace que mis sitios web queden inaccesibles, y por más vistazos al log de hhvm, preguntas a ServerFault o cambios a la configuración no hay forma de estabilizar la situación.

La única solución viable hoy por hoy -no ideal, peor no está mal- es la de monitorizar el sistema para reiniciar el servicio si éste se desactiva. Y esto es precisamente lo que permite monit, una singular herramienta disponible para diversas plataformas y que permite ejecutar todo tipo de acciones a partir de la monitorización. Yo me centraré en la parte que me interesa (reiniciar HHVM cuando se desactive), pero podéis obtener información más detallada sobre monit en el sitio web oficial del proyecto.

La instalación de monit es sencilla, y aunque hay paquetes precompilados yo he preferido instalarlo todo desde el código fuente. Antes, por si las moscas, hay que asegurarse de que tenemos las herramientas de compilación necesarias:

sudo apt-get install build-essential

Además instalaremos un par de paquetes que nos darán la opción de utilizar monit con conexiones seguras (algo que de momento yo no he hecho, pero así resuelvo la advertencia durante el proceso de configuración):

sudo apt-get install libpam0g-dev
sudo apt-get install libssl-dev

Tras lo cual podemos proceder a la descarga del código fuente de la aplicación, su compilación y su instalación.

cd
wget http://mmonit.com/monit/dist/monit-5.9.tar.gz
tar xzvf monit-5.9.tar.gz
cd monit-5.9/
./configure
make
sudo make install

Con esto ya podremos utilizar monit en nuestro servidor, pero vamos al grano y a la configuración de lo que nos interesa. Monit permite acceder a una interfaz web de consulta de todo lo que podemos monitorizar (estado de los servicios, consumos de CPU o memoria, cambios en ficheros -tamaños, fechas de modificación-), y tanto ese tipo de acceso como las opciones de monit las controlaremos desde el fichero monitrc. Nosotros ejecutaremos esta herramienta como superusuarios, por lo que tendremos que utilizar ese fichero desde el directorio /etc. Como tenemos un fichero ejemplo en el código fuente de monit, podremos copiarlo a ese directorio para luego editarlo:

cd ~/monit-5.9/
sudo cp monitrc /etc/monitrc

Y ahora ya podemos comenzar a editar. Para ello con nano (o vuestro editor preferido):

sudo nano /etc/monitrc

Y si vais bajando en él (el fichero es bastante explicativo y claro) veréis la parte en la que se muestra cómo acceder a esa información vía web:

set httpd port 2812 and
   use address localhost # only accept connection from localhost
   allow localhost        # allow localhost to connect to the server and
   allow admin:monit      # require user 'admin' with password 'monit'
   allow @monit           # allow users of group 'monit' to connect (rw)
   allow @users readonly  # allow users of group 'users' to connect readonly

Esa configuración debe quedar como sigue para que podáis acceder desde vuestro ordenador sin problemas:

set httpd port 2812
 use address www.javipas.com # only accept connection from localhost
 # allow localhost # allow localhost to connect to the server and
 allow admin:monit # require user 'admin' with password 'monit'
 allow @monit # allow users of group 'monit' to connect (rw)
 allow @users readonly # allow users of group 'users' to connect readonly

Evidentemente tendréis que modificar tanto la dirección web en la que consultar la información (usad el dominio de vuestro sitio web), el usuario (‘admin’) y la contraseña (‘monit’) para establecer los vuestros propios. Tras este primer cambio podéis salvar y salir, y ya podéis comenzar a comprobar qué es lo que ocurre al ejecutar monit como superusuario:

sudo monit

Al hacerlo aparecerán un par de mensajes informativos:

javipas@gigapas~ $ sudo monit
 Generated unique Monit id 6ac906f1880450c565bb3005eb59bfc1 and stored to '/root/.monit.id'
 Starting Monit 5.9 daemon with http interface at [www.javipas.com:2812]

Y como veis en ese mensaje, os podréis conectar con el usuario y contraseña que habéis elegido. En mi caso, escribo en el navegador la URL http://www.javipas.com:2812 tras lo que se os realizará la petición de ese usuario y contraseña. Al hacerlo os aparecerá este tipo de información visual (en mi caso, ya con los datos del servicio hhvm):

Esto pinta bien. Ahora solo queda configurar monit para que, como decíamos, esta monitorización reinicia HHVM cuando este servicio se desactive por la razón que sea. Para ello primero paramos monit:

sudo monit quit

Y ahora volvemos a editar el fichero:

sudo nano /etc/monitrc

Hay un buen ejemplo de lo que debemos hacer en ese fichero de configuración en la parte en la que se nos habla de cómo reiniciar Apache. En nuestro caso el servicio es hhvm, no el servidor web Apache, y no serán necesarias tantas condiciones: simplemente bastará que hhvm se reinicie cuando una petición de lectura de una página web cualquiera en nuestra web no obtenga la respuesta esperada. En mi caso basta con insertar las siguientes líneas en ese fichero, por ejemplo a la altura de esa parte en la que se indica el ejemplo de reinicio de Apache:

check process hhvm with pidfile /var/run/hhvm/pid
    start program = "/etc/init.d/hhvm start" with timeout 60 seconds
    stop program = "/etc/init.d/hhvm stop"
    if failed host www.javipas.com port 80 protocol http
        and request "/index.php"
    then restart

Como se puede ver, esta configuración primero comprueba cuál es el identificador de proceso (pid) del servicio hhvm, para luego establecer los comandos de inicio y parada en caso de ser necesarios. Luego llega lo importante: si nuestra página web (en mi caso, la URL de Incognitosis) no recibe respuesta para una petición normal por el puerto 80 (el que se usa normalmente en servidores web, como en mi caso), se reinicia el servicio. ¡Fácil!

Una vez incluidos los cambios, basta con salvar y salir de nuevo, y ya podremos volver a iniciar monit:

sudo monit

Esto hará no solo que tengamos acceso a visualizar cómo va todo (podemos desactivar esa opción en el fichero de configuración fácilmente dejando esa parte como estaba por defecto) sino que ya funcionará la reactivación del servicio hhvm que en mi caso se desactiva con cierta frecuencia. Podéis probar si funciona fácilmente: abrid un navegador y visitad en una pestaña vuestro blog y en otra la información de monitorización. Si no estábais conectados a vuestro servidor por SSH, conectaos. Parad el servicio hhvm (sudo service hhvm stop) y ved lo que pasa: recargad la página web del blog (saldrá el 502 de marras), mirad la pestaña de monit (al cabo de unos segundos/un minuto máximo) se refrescará indicando que el servicio no está disponible, pero instantes después el propio monit reiniciará hhvm. Si probáis a ir refrescando la pestaña con vuestro blog veréis como en apenas un minuto todo vuelve a la normalidad. Fantástico.

La solución no es óptima -introducimos algo de carga en el sistema, y puede haber pequeños periodos (máximo 1 minuto) en los que el blog no esté accesible, pero comparado con esos periodos normales en los que uno no reactiva el servicio hasta que no se da cuenta del problema (en mi caso, un mensaje 502 Gateway Error), la cosa mejora de forma notable. 

Un último paso:  añadir monit a la secuencia de arranque de forma que cada vez que haya un posible reinicio este servicio también se active para evitar los problemas mencionados. Para ello hay que crear un enlace simbólico que luego nos permitirá actualizar los scripts de inicio: 

sudo  ln -s /usr/local/bin/monit /etc/init.d/monit
sudo update-rc.d monit defaults

Con esto ya tendremos todo preparado para poder seguir usando esta herramienta de monitorización sin problemas. 

---

Sugerencias y comentarios

Estoy muy lejos de ser un experto en el tema, pero siempre me ha gustado leer sobre rendimiento web (Web Performance) y mi pasado puesto como CTO hace un par de años hizo que tuviera que investigar mucho y bien sobre un tema que ahora he recuperado de forma más gratificante: puedo trastear y probar cosas sin miedo a que una página de la que dependen puestos de trabajo sufra caídas o problemas graves. En Incognitosis (www.javipas.com) es aún posible rascar bastante en tiempos (un análisis de ahora mismo en Pingdom Tools por ejemplo deja clara la diferencia entre cargar el dominio con www y sin www, algo que debo corregir cuanto antes haciendo la redirección correcta en Nginx), pero eso conlleva tiempo y yo quería plantear tan solo la base, a partir de lo cual la idea es ir probando más y más cosas como algunas de las que he planteado.

Por esa razón querría que en los comentarios planteáseis cualquier tipo de sugerencia o mejora a la guía, que espero que sea un documento vivo y se vaya enriqueciendo con el tiempo. Como ya dije al principio, no puedo dedicarme a contestar todas vuestras dudas (intentaré contestar a alguna de cuando en cuando, pero no es el objetivo, así que por favor, moderaos con las preguntas y hacedlas mejor en sitios como StackOverflow o ServerFault) pero sí me encantaría que si detectáis fallos, problemas, o mejoras a esta guía, me las comunicáseis. Seguro que la guía puede enriquecerse con mejoras al proceso actual que he comentado, o a mejoras posteriores con las que rascarle milisegundos al servidor.

Y ahora, ya sabéis: a darle duro a vuestros servidores.

---

 

Referencias

High-performance WordPress installation using Nginx, MariaDB and HHVM from scratch in Ubuntu 13.10 (Federico Ramírez / Svbtle)

How to Move WordPress Blog to New Domain or Location (MyDigitalLife)

Ubuntu Server Guide: Install Nginx from source on Ubuntu 12.04 (Jeff Mould)

Setting up WordPress + Nginx + HHVM For The Fastest Possible Load Times (WebDevStudios)

WordPress on Nginx with HHVM (6tech)

How to optimize Nginx configuration (DigitalOcean)