César D. Rodas

En estos días me he dedicado a ahondar en temas de performance para sitios relativamente grandes para shared hostings, y pequeños para servidores dedicados (posiblemente tenga que hostear un periodico local con 50.000 visitas diarias, todavía no está confirmado). Aunque el título de este post suena un poco marketinero, en realidad este artículo será la continuación de como mejorar el rendimiento de una web.

Baratos

Para la mayoría de los sitios webs no se justifica un servidor dedicado y un shared hosting que pequeño, entonces ¿cuál sería el punto medio?, ahí cuando entran en juego las VPS. Básicamente las VPS son máquinas virtuales en donde tenemos acceso total, casi todos utilizan Xen aunque personalmente me encanta el Linux-VServer (esto es totalmente irrelevante en este artículo), hablando mal y rápido son como máquinas dedicadas con menores recursos y lo más importante mucho menos precio.

Yo utilizo Linode, y realmente no me puedo quejar de su servicio, pero existen varios otra opciones en el mercado.

Seguros

La seguridad es un tópico bastante extenso, y básicamente es una buena práctica. Ya que nadie no velará por la seguridad de nuestro server, más que nosotros mismos tenemos que tomar algunas medidas, básicamente ocultar los detalles de nuestro servidores. En todos los ataques “hackers” que fui parte (siempre como victima, en algún trabajo) fue por que el “atacante” conocía como funcionaba el servidor (ex-funcionario) o por culpa del administrador del servidor que dejó las configuraciones por defecto.

Algunas de las buenas prácticas son las siguientes:

• Secure Shell (SSh): Esta herramienta es fundamental a la hora de conectarnos al servidor y administrarlo remotamente, al mismo tiempo de ser necesario puede volverse peligrosa, aunque es cierto es difícil de vulnerar (casi siempre por error humano, como una contraseña sencilla), pero en caso de vulnerar los resultados serán fatales.
  • Desabilitar el root login.
  • Utilizar contraseñas dificiles de adivinar (ej: 12 caracteres, mezclas entre mayusculas, minusculas y números) y anotar la contraseña. Para utilizar la anotación a cada vez que se necesite conectarse al servidor, se podría en una máquina personal, generar claves (ssh-keygen) y luego copiar las claves (ssh-copy-id) al servidor así a cada vez que nos hagamos login en el servidor, este no nos pedirá contraseña.
  • Escuchar en un puerto distinto del puerto 22, es preferible escuchar en un puerto superior al 20000 así sería un poquito más complicado de detectar con con algún scanner de puertos.
  • Guardar Log de los login fallidos.
  • Vía firewall permitir el acceso al SSH de algunos rangos de IPs si es posible.
• Siempre tener un firewall (IPtables o ipfw).
• Evitar el DoS attack: Ricardo Galli, creador de Menéame (y mi amigo vía talk), escribió en su blog, un interesante artículo de como él evitó el ataque de DoS en su sitio, bastante interesante.
• PHP:
  • Nunca mostrar los errores al usuario, siempre hacer logging de los errores y mostrar al usuario alguna página con información genérica del error sin datos técnicos.
  • Limitar los recursos como memoria RAM, tamaño máximo de las peticiones GET, POST, tiempo máximo de ejecución, etc.
• MySQL:
  • El mysqld debe escuchar 127.0.0.1 si la base de datos se encuentra en la misma máquina que el servidor web, en caso contrario siempre asegurarse que este en una red privada, nunca colocar en una red pública escuchando 0.0.0.0
• Backup: realizar backup de los datos (códigos fuentes, dump de la base de datos) y configuraciones (/etc/, /var/logs/ y otros) frecuentemente como máximo a cada día, y copiar en otro servidor, si no se cuenta con otro servidor, una alternativa efectiva y barata es colocar en Amazon S3.
• Generalidades: limitar los recursos de los servicios, siempre tener logs de los deamons.

Eficientes

Como decía en mi articulo anterior (como mejorar el rendimiento de una web), si deseamos tener un servidor para atender un gran número de visitas lo más importante despues de la buena práctica de programación era tener un servidor web efectivo, parte de la efectividad era separa las consultas dinámicas y las estáticas hacia diversos servidores. Esto no es problema si hacemos las aplicaciones from scratch, pero que pasaría si por ejemplo queremos instalar una aplicación Open Source (ej: wordpress), cambiar las direcciones de los archivos estáticos hacia otro dominio sería un poco trabajoso (todos sabemos que no sería un problema que con wp, solo es un ejemplo). La solución más simple sería un reverse proxy que redirija la petición dependiendo de que si el recurso requerido es estático o dinámico.

Ahí es cuando entra en juego el NGinx ya que aparte de ser un increíble webserver, también es reverse proxy entre otras cosas. La configuración será la siguiente.

Aquí va la configuración.

# El usuario va a ser nginx, siempre es importante
# ejecutar como usuario sin privilegio.
user  nginx;
# número de procesos "workers" que se encargaran de
# atender a la peticiones entrantes.
worker_processes 2;
# log
error_log  logs/error.log;
# pid, útil para reiniciar el "servicio"
pid        logs/nginx.pid;

events {
    # procesos que se encargaran de responder la petición
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] $request '
                      '"$status" $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;
    sendfile        on;
    keepalive_timeout  65;
    # Comprimir todo, útil para ahorrar ancho de banda.
    gzip  on;

    server {
        listen       80;
        server_name  www.servidor,com;
        access_log  logs/host.access.log  main;
        location / {
            # Por defecto pasar todas las peticiones al Apache.
            proxy_pass http://127.0.0.1:8080/;
            proxy_redirect off;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;

            client_max_body_size 10m;
            client_body_buffer_size 128k;
            proxy_connect_timeout 90;
            proxy_send_timeout 90;
            proxy_read_timeout 90;
            proxy_buffer_size       4k;
            proxy_buffers       4   32k;
            proxy_busy_buffers_size 64k;
            proxy_temp_file_write_size   64k;
        }
        # Si lo requerido es una archivo "estático", nginx tiene que responder,
        # y el cliente no tiene que volver a preguntar (gracias al cache).
        location ~* ^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
             root   /var/www/html/;
             expires max;
        }
        # Página estática de error
        error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

}

Para este ejemplo el Apache tiene que escuchar el puerto 8080 del IP 127.0.0.1. También sería razonable desabilitar los logs de acceso (pero los de error no, ya que PHP escribiría ahí los errores) ya que esos logs son generados por nginx, y para qué repetir datos?