Tecnología

WordPress a toda pastilla con Nginx+PageSpeed, MariaDB, HHVM y más en Ubuntu 12.04

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é.


gigas-1-ubuntu

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.

hhvm-incognitosis-2

 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:

hhvm-incognitosis-4-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.

hhvm-incognitosis-6-usuario


 

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

hhvm-incognitosis-8-nginx-2-curl

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.

hhvm-incognitosis-9-mariadb-3-secure-installation

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.

hhvm-incognitosis-10-hhvm-1

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:

hhvm-incognitosis-12-hhvm-3-hiphop

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‘).

hhvm-incognitosis-12-hhvm-3

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:

hhvm-incognitosis-16-registrar-dominio

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

 hhvm-incognitosis-13-wordpress-1

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

hhvm-incognitosis-13-wordpress-2

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.

hhvm-incognitosis-17-wordpress-jotas-1

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!

hhvm-incognitosis-17-wordpress-jotas-4


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

hhvm-incognitosis-18-replace-bbdd-1

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');

hhvm-incognitosis-21-lastresjotas

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.

hhvm-incognitosis-15-pagespeedtest-1-concompresion-desktop

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:

whichloadsfaster

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:

hhvm-incognitosis-20-loadimpact

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.

hhvm-incognitosis-19-uptimerobot

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

monit-1-inicio

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)


Incognichollos

Esta es una selección con las mejores ofertas tecnológicas actualizadas casi diariamente, como expliqué aquí. Aunque estés en un post “antiguo” las ofertas son de última hora, los Incognichollos los actualizo aparte. Aprovecha, que no suelen durar mucho tiempo:

  • Tarjeta Micro SD SanDisk Ultra 64 GB: oferta destacada para los que queráis ampliar la memoria de vuestros móviles porque esta MicroSD de 64 GB tiene clase 10 y además certificación A1 que indica que es especialmente buena para mover a ella apps móviles. Está a 13,17 euros en GearBest con el cupón THURESDA1.
  • Nintendo Switch: la consola que está triunfando en todo el mundo baja de precio en su versión en color gris. Está a 299,90 euros en Amazon, cuando normalmente cuesta 329 euros sin juegos. ¡Si quieres regalarla en Navidad, atento!
  • OnePlus 5T: los nuevos telefonazos de OnePlus llegan por fin a las tiendas chinas con precios más atractivos si no os importa tanto el tema garantía. El precio más bajo ahora mismo es el de los 412,34 euros que cuesta en Banggood con el cupón 12BGDiscount. También lo tenéis a 419,39 euros en eBay con el cupón PNAVIDAD10. También interesante ahora mismo es la versión de 8GB/128 GB que también está a 470,80 euros en Banggood con el cupón 12BGDISkm.
  • Auriculares Sennheiser HD 4.30i: son unos auriculares de diadema cerrados pero plegables en color blanco y que por lo qeu dicen tienen una calidad de sonido fantástica. Están bastante rebajados, otro buen regalo navideño diría: están a 59,99 euros en Amazon (39% dto.)
  • Honor 7X: el nuevo gama media de Huawei está muy bien: un Kirin 659, 4 GB de RAM, 32 GB de capacidad ampliables y cámara dual bastante maja. Gran competidor del Xiaomi Mi A1, diría. Todo por 174,90 euros en Geekbuying con el cupón NVIXVWYM.
  • Patinete eléctrico Xiaomi: el Mijia Scooter vuelve a estar de oferta, un patinete eléctrico plegable para desplazamientos urbanos con autonomía de 30 km y velocidad de hasta 25 km/h. Está a 280,61 euros en GearBest con el cupón EQ365TG, y regalan dos ruedas de repuesto.
  • Xiaomi Mi Notebook Pro: el señor portatilazo de este fabricante compite con lo más granado del mercado, de ahí lo del “Pro” final. Llega con un Core i5-8250 de ultimísima generación, una potente GeForce MX150 (netamente superior a las 940MX), 8 GB de memoria DDR4, 256 GB de capacidad y lector de huella. Está a 677,35 euros en LightningInTheBox, un precio absolutamente alucinante para este maquinón. Por cierto, el modelo con el Core i7-8550U, 16 GB de RAM y 256 GB de SSD está a 914,76 euros en LightningInTheBox, que tampoco está nada mal.
  • Grim Fandango Remastered: el famoso juego de LucsaArts de 1998, pero remasterizado. Todo un clásico que podéis ahora disfrutar gratis. Ole.
  • Xiaomi Mi 5X: es como el triunfal Mi A1, pero con MIUI, algo que a mí no me molesta en absoluto (tengo el Mi 6) y que además permite conseguirlo muy barato. Un 5,5 pulgadas con el Snapdragon 625, 4 GB de RAM, 64 GB de capacidad y cámara dual más que decente por 161,40 euros en GeekBuying con el cupón JNXYOBSZ. Un chollete en toda regla, vamos.
  • Xiaomi Mi 6 64 GB: atención lectores y amantes de los caprichos tecnológicos, porque mi móvil favorito está a precio interesante. La versión en color azul está a 313,77 euros en GearBest. El modelo negro de 64 GB no está tan barato y sale a 331,63 euros en GearBest con el cupón MI6XGB. También tenéis la versión “oficial” que venden en España y que está a  449 euros en Amazon, un precio quizás excesivamente alto, pero ahí tenéis la opción.
  • SSD SanDisk Ultra 1 TB: una unidad SSD con esta capacidad no es ninguna tontería, sobre todo cuando está a un precio impresionante, 269 euros en Amazon (cuesta más 349 normalmente).
  • ‘Assassin’s Creed IV: Black Flag’: Ubisoft está que lo tira, y regalan esta edición de su famosa franquicia, así que si quieres jugarlo en PC completamente gratis, puedes descargarlo desde aquí.
  • Xiaomi Mi Air 13,3: el nuevo modelo de mi portátil BBB (bueno, bonito y barato) favorito llega con un Core i5-7200U, 8 GB de RAM, 256 GB de SSD, una GeForce MX150 y atentos, lector de huella. Creedme: es una pasada, sobre todo a este precio. Lo tenéis en LightningInTheBox por 609,55 euros. El modelo antiguo con el Core i5-6200U, una NVIDIA 940MX y sin sensor de huella está a 615,33 euros en GearBest, curioso, más caro que el moderno.
  • Seagate FireCuda 2 TB + Assasins Creed: un disco duro híbrido ideal para la PS4 o para PC con una parte SSD (de poca capacidad) y esos 2 TB para almacenar lo que queráis. Mola porque además regalan el último ‘Assasin’s Creed: Origins”. Todo por 109,79 euros en Amazon.
  • Xiaomi Redmi 5: está recién presentado esta pasada semana, y ya está en tiendas preparado para arrasar. Es el primer “sin marcos asequible” de Xiaomi con pantalla de 5,7 pulgadas casi ocupando todo el frontal, además de 3 GB de RAM, 32 GB de capacidad y un Snapdragon 450. A eso se le añade su cámara de 12 MP y una batería de 3.300 mAh, todo por 151,72 euros en Banggood (en reserva por ahora) con el cupón BGR532G.
  • Xiaomi Redmi 5 Plus: la versión mejorada del anterior, con pantalla de 5,99 pulgadas en formato 18:9 también, Snapdragon 625, 3 GB de RAM, 64 GB de capacidad y una cámara de 12 MP. Lo tenéis a 168,69 euros en Banggood con el cupón BGR5PLUS32G.
  • Afeitadora eléctrica de Xiaomi: curiosidad del día. Si os fiáis de los chinos en móviles, quizás también lo hagáis para afeitaros, y aquí Xiaomi también está presente (cómo no) con un producto que además se recarga vía USB-C y que tiene un motor a 7.800 RPM. La tenéis a 33,16 euros en GearBest.
  • Raspberry Pi 3: el miniPC en crudo que más nos gusta y que te permite montar desde un Media Center hasta estaciones metereológicas. La tenéis en GearBest a 30,60 euros. También está en Amazon por 34,00 euros.
  • Cargador universal – Adaptador de viaje: si quieres recargar tus dispositivos allá donde vayas, este adaptador te soluciona el problema. Tiene tomas para distintos países y también dos puertos de carga USB. Un invento a un buen precio, 4,51 euros en LightInTheBox.
  • Teclado plegable Bluetooth: un producto simpático que usé hace años (de otra marca) y que creo qeu es un invento para poder escribir textos largos en un smartphone o tablet en diversos escenarios. El modelo de 1byone tiene distribución española, y sobre todo tiene un precio estupendo de 27,99 euros en Amazon (66% dto.)
  • Samsung Galaxy S8: el súper teléfono de Samsung a precio rompedor, aunque eso sí, en versión alemana, con lo que no podréis usar Samsung Pay de forma nativa. En las preguntas y respuestas un usuario explica cómo lograr que sí se pueda usar. Si os convence, está a 569 euros en Amazon.
  • Tarjeta gráfica MSI GeForce GTX 1050 Ti: una tarjeta modesta pero que dará bastante juego y que está reacondicionada por Amazon, o sea, con todas las garantías. Está a 159 euros en Amazon.
  • SSD Crucial 240 GB: una unidad SSD con unabuena capacidad, el modelo Crucial BX300, que además ofrece velocidades de escritura de hasta 500 MB/s. Está a 66,90 euros en Amazon (30% dto.). La versión de 120 GB está también rebajada a 49,99 euros (21% dto).
  • LG G6: el súper teléfono de LG es una gran opción ahora que ha bajado de precio. Esa pantalla de 5,7 pulgadas sin marcos es estupenda, y su cámara dual, también. El modelo “rosa dorado” está a 400 euros en Amazon. Preciazo, no digo más.
  • Huawei P10: el súper teléfono de Huawei, solo superado por su Mate 10, está a precio estupendísimo, e integra un Kirin 960, 4 GB de RAM, 64 GB de capacidad y una cámara dual muy, muy chula. Está a 365,65 en GearBest con el cupón CXLP10.
  • Xiaomi Mi Mix 2: el smartphone sin marcos de Xiaomi es una fantástica evolución del modelo anterior que gana en hardware (Snapdragon 835, 6GB RAM, 64 GB capacidad, 6 pulgadas), aunque descuida un poco el tema de la cámara. Eso sí, diseño espectacular. Está a 459,19 euros en GearBest.
  • GameSir G4s: este mando de juegos para smartphones te permite jugar en tu móvil con mucha más versatilidad, en plan consola. Lo del soporte para el móvil en la parte superior y la conectividad Bluetooth resuelven todos los problemas. Está a precio chollo, 22,10 euros en GearBest con el cupón CYMONESG4S.
  • Honor 9: una gran propuesta de esta filial de Huawei que cuenta con un Kirin 960, cámara dual, 4 GB de RAM y 64 GB de capacidad. Está a 263,60 euros en GearBest con el cupón MiESHH9 e incluye dos años de garantía en España. En Amazon, por ejemplo, está a 405 euros.
  • Umidigi S2 Pro: no conozco demasiado la marca, pero desde luego están intentando crecer en mercados internacionales. Este terminal cuenta ocon un procesador medio (Helio P25) pero esa pantalla sin marcos resulta muy atractiva. Cuenta con 6 GB de RAM, 128 GB de capacidad y una cámara dual (13+5 MP, un poco rara) y todo por 255,10 euros en GearBest.
  • Nubia M2: un smartphone de 5,5 pulgadas con un Snapdragon 625, 4 GB de RAM, 64 GB de capacidad y doble cámara. Muy majo para el precio que tiene, 149,41 euros en Banggood con el cupón M2XMAS.
  • Logitech MX Master: el ratón que llevo usando desde hace un par de años y que ahora está a un precio inigualable, 49,90 euros en Amazon (54%). La mitad de lo que yo pagué por él. Espectacular en ergonomía y prestaciones.
  • Android TV Box Alfawise H96 Pro+: una cajita bastante potente para acompañar a vuestra tele. Integra un Amlogic S912 -de lo mejorcito-, tiene WiFi, Gigabit Ethernet, 3 GB de RAM y 32 GB de capacidad, además de tener Android 7.1. Lo tenéis en GearBest a 47,61 euros con el cupón blackfridayes27.
  • Ratón Gaming Razer Abyssus 2014: un ratón gaming que anda a precios mucho más altos por aquí (45 euros) pero que podéis encontrar en Geekbuying a 18,93 euros con el cupón GZFIZDQK. Adivinad quién lo ha comprado para sus partiditas al Battlefield 1.
  • Tarjeta MicroSD Samsung EVO Plus 64 GB: una buena forma de darle más vida a vuestro dispositivo móvil o a vuestra RPi, la tenéis a 18,53 euros en GearBest. Si no queréis esperar al envío de la tienda china, atentos porque en Amazon tienen una Samsung EVO de 64 GB por 24,90 euros (42% dto.). Si queréis versiones más reducidas en tamaño y precio, la Samsung EVO+ de 32 GB está a 9,77 euros en GearBest.
  • Xiaomi Mi Box TV: la cajita para convertir vuestra tele en una súper tele inteligente, que puede con todo tipo de formatos (incluidos H.265 o VP9) y que está al precio más bajo que yo he visto jamás: 59,44 euros en GearBest.
  • SSD SanDisk Plus 240 GB: una unidad de estado sólido que pinta muy bien a muy buen precio gracias al pre-black friday de estos días. La tenéis a 81,48 euros en Amazon (27% dto.)
  • Android TV Box: si quieres darle más vidilla a tu tele tienes varias opciones, como este Mecool M8S Pro con un Amlogic S905W, 2GB/16GB y Android 7.1.1 que está a 24,65 euros en GearBest con el cupón Bfriday039.
  • Amazon Fire TV Stick Basic Edition: por fin tenemos este competidor del Chromecast en nuestro país, aunque eso sí, llega sin el soporte Alexa de su hermanito mayor. Lo mejor, que podéis prescindir del móvil para controlarlo (tiene mando) y que además de todo lo que ofrece Chromecast ofrece soporta, evidentemente, Prime Video. Si sois usuarios Premium de Amazon lo tenéis por 39,99 euros en Amazon. Muy, muy interesante.
  • Huawei P9 Lite: la versión modesta del tope de gama de Huawei del año pasado tiene un precio rompedor. Llega con pantalla de 5,2 pulgadas 1080p, un Kirin 650, 3 GB de RAM y 16 GB de capacidad ampliables, además de una cámara muy decente de 13 MP. Está a 136,05 euros en GearBest con el cupón CXLP9LITE.

¿Quieres recibir un correo de aviso cuando publique nuevas entradas?

Standard

44 comentarios en “WordPress a toda pastilla con Nginx+PageSpeed, MariaDB, HHVM y más en Ubuntu 12.04

    • Los droplets de DigitalOcean son un buen invento, sí señor. No soy muy de CentOS, pero de hecho me estuve mirando a fondo el tuto que enlazo al final, en el que el autor se basaba también en CentOS. Yo probé con Ubuntu por los paquetes precompilados de Nginx+PageSpeed más que nada, pero también porque me siento más cómodo con el apt-get.

  1. emocion dice:

    Hola Javi! Muy buen y completo articulo. Acababa de instalar LEMP con WordPress cuando he leido tu articulo y he descubierto el HHVM.
    ¿Ves el tema de activar caché como algo vital para la mejora del rendimiento/velocidad? No me atrevo de momento a activar y configurar ningun plugin de cache…

    Saludos!

  2. Hace algunos días intenté acceder a javipas.com y me daba “502 Bad Gateway”. Ahora, me está pasando lo mismo con un sitio en donde estoy haciendo estas pruebas. El sitio funcionó bien 24 horas, y ahora está dando “502 Bad Gateway”. ¿Cómo lo solucionaste?

    • Efectivamente, parece que hhvm de repente se para por sorpresa. Ya comento al final del post, en la sección de “Posibles problemas”, que esto ocurría -monitorizarlo con servicios tipo Uptime Robot minimiza un poco el problema por las alertas-, y tenía que actualizarlo con esta posible solución, que parece que por el momento funciona 🙂

    • Vi que cuando doy reboot HHVM lo tengo que reiniciar manualmente

      creo (la verdad no se) si olvidaste (o en realidad va esto) en el tutorial>

      root@localhost:/etc/init.d# sudo update-rc.d hhvm defaults

    • Creo recordar que en esa de Nginx había algún problema con los custom permalinks, y hay algún expire más, pero puedes probar con la oficial de Nginx, claro. A mi me ha funcionado con estas opciones, pero es bueno que probéis variaciones a ver si hay cambios a mejor. Si es así, ¡no dudes en comentármelo!

    • https://www.cloudflare.com/railgun

      Sino, solo el cloudflare sirve de maravilla

      1) es un CDN GRATUITO (bueno la pro son 20 dolares, pero no es nada comparando con MAXCDN o otro CDN que te cobran por GB)
      2) Tienen bastante servers para el cdn https://www.cloudflare.com/features-cdn
      3) Minifi del html, css, js, asi no necesitas cosas extra como el pagespeed dentro de tu maquina
      4) optimizacion de imagenes ya sea lazy load o compression loosy o loosness
      5) varios otros tweaks

      Yo personalmente uso la version pagada de 200 usd por mes para un mes y VUELA mi sitio, time to first byte tan bajo como 40ms-80ms y los demas contenidos pues obvio los mandan del cdn asi que ufff encantado con cloudflare

      • Sí, como te decía Cloudflare tenía la intención de probarlo en algún momento, pero desde luego no la versión de pago. Este es un blog personal, sin publicidad, y no puedo permitirme ese gasto… pero gracias por el apunte de todos modos

      • JAVIPAS, claro la version gratuita tambien es muy buena

        MAS QUE NADA y el mejor punto es el CDN, te habilita reglas individuales si quieres, auto minify… etc

        Si eres un freak de la optimizacion, esto es lo ultimo que metes y veras que nunca te arrepentiras

        Un saludo

    • Ojo esta la version gratuita de cloudflare que es bastante bueno

      Donde ya tienes
      1) Auto Minify
      2) CDN

      Con la pro pagas 20 dolares (5 dolares por sitio extra, yo tengo 5 con ellos pro y 1 bussiness)
      Con la pro te dan buenas cosas como
      1) Mirage 2/ PRO / BUSINESS / ENTERPRISE/ BETA
      Automatically optimizes image loading through virtualized and lazy-loaded images. Improves the performance of images on a mobile connectio
      2) Polish: image optimization/ PRO / BUSINESS / ENTERPRISE
      Strips metadata and compresses your images for faster page load times.
      Note: For the service to take effect immediately, you will have to cache purge.
      Basic (Lossless): Reduce the size of PNG, JPEG, and GIF files – no impact on visual quality.
      Basic + JPEG (Lossy): Further reduce the size of JPEG files for faster image loading.
      Larger JPEGs are converted to progressive images, loading a lower-resolution image first and ending in a higher-resolution version. Not recommended for hi-res photography sites.

      Asi tambien optimizas tus imagenes, que comentabas son grandes y para moviles queda excelente el mirage

      Mi sitio mas optimizado en question de velocidad era
      http://bit.ly/1rZ08Ot
      ESTOY CAMBIANDO LA CONFIGURACION ESO SI DEL SERVIDOR, la voy a cambiar a NGINX + (PHP-FPM o VHHM) + zend opcache + Varnish 3/4 + Mariadb + Cloudflare railgin

      Al momento lo tengo sobre apache, recibo de 250k-400k visitas, pero la vdd cloudflare y varnish estan haciendo una maravilla, pero busco volverlo perfecto con la nueva configuracion del servidor, la deberia tener para ahora en la noche y quiero ver como volara el sitio

      OJO el ranking de pagespeed es debido a las integraciones
      1) Los JS y SDK de facebook, twitter y google+
      2) el plugin de addthis
      3) my sidebar es estatico mientras le das escroll

      aun asi checa el sitio y dame tu opinion para mi orita esta bastante rapido, el render carga bastante rapido y los javascript todos son async asi que casi no afectan la experiencia del usuario

      si desactivo todos esos JS y plugins el pagspeed me da como un 94/100 pero obvio pierdo as integraciones que sirven para mi nicho

    • Gracias Daniel, estuve probando el servicio PageSpeed de Google, similar al de Cloudflare, pero lo dejé cuando hice esta última migración. Igual pruebo Cloudflare a ver que tal, gracias por la idea y por tus impresiones 😀

  3. Ojo checando rapidamente tu sitio vi varias cosas
    FONTS
    1)Estas usando demasiados fonts
    a)http://brick.a.ssl.fastly.net/Linux+Libertine:400,400i,700
    b) http://fonts.googleapis.com/css?family=Lato:100,300,400,700,900,100italic,300italic,400italic,700italic,900italic
    c) http://fonts.googleapis.com/css?family=Playfair+Display:400,700,900,400italic,700italic,900italic&subset=latin,latin-ext
    d) Genericons

    2) Solo el font BRICKS le mete 450k+ al lector (esta bastante pesado ese font no se cual sera)
    3) Son demasiados WEIGHTS de cada font, no creo uses todos, en google font al final solo selecciona los que usas, porque aqui le estas bajando mas de 15 FONTS a tu usuario y te repercuten algo en el loading time

    Por ejemplo:

    Y ahi con ese ya estas diciendoles con 1 solo request (en vez de 2,3…n) que baje esos dos fonts con el weight especifico

    Yo en vez de genericos uso font awesome http://fortawesome.github.io/Font-Awesome/ Y con reglas MUY basicas puedes darle un excelence custom a tu theme, checa este link http://sridharkatakam.com/using-font-awesome-wordpress/ (este sujeto usa genesis framework y hace unos customs tremendos aparte de que genesis es SUPER LIGERO), por ejemplo la lupa para buscar la metes como icono de aqui y te quitas meterle mas imagenes a tu template

    Por ejemplo este sitio lo uso para pulir mis themes (no le meto ningun plug in para visualizar de la mejor manera todos los archivos que tengo sin plugins o JS que meto despues para experiencia del usuario)
    http://www.recreotesting.com/politica-de-privacidad/

    Esa pagina no tiene imagenes o casi JS
    Ojo si tarda en cargar es porque la tengo en shared hosting con hostgator (SOLO LA USO para ver que archvios tengo en un template limpio y mejorarlo para que sea casi perfecto y ultra liviano para el lector)

    15 requests y solo 182kb (60kb son del font awesome)

    Ya teniendolo bien por ejemplo lo pongo en un sitio con todo la optimizacion posible y queda ufff como rayo

    • Qué buenos consejos Daniel, de nuevo gracias. Sí que había mirado por encima en Pingdom qué recursos pesaban más y lo de las fuentes lo tenía en el punto de mira. Gracias de nuevo, a ver si puedo ponerme un rato con ello para actualizar. Lo malo es que Linux Libertine (la de Bricks) me molaba especialmente, pero creo que compensa tirar de algo más ligerito. Igual te mando alguna preguntita al respecto que veo que controlas 😉 Saludos!

    • Añadido, perdona, tenías razón. ¿? No hace falta Daniel, Monit, el servicio que se encarga de ir haciendo pings y comprobando que el servidor web sigue sirviendo las páginas, ya tiene en cuenta que si eso pasa tiene que reiniciar el servicio. Está todo correcto… te lo aseguro porque Incognitosis sigue cayéndose de cuando en cuando, pero Monit lo detecta y levanta hhvm él solito al cabo de un minuto como máximo.

  4. Pingback: Configura Hosts en tu VPS | Cambia de SO

  5. Ojo

    tmb es importante para algunas personas agregar en la configuracion de nginx

    client_max_body_size

    Y darle un valor preferible, ya que por defaul dejara subir solo 1MB maximo a wordpress, si subes imagenes de alta calidad o gifs no te dejara subirlos y te dara un error HTTP

    en mi caso lo subi a:

    client_max_body_size 20m;

    asi evitas esos problemas a la hora de subir imagenes o archivos en el servdor y que no te arroje http error

Comentarios cerrados