Para administrar un servidor dedicado o virtual Linux necesitamos herramientas para controlar el uso de memoria, cpu o almacenamiento. Hay una herramienta en modo consola o de terminal con la que podemos entrar y ver su estado sin necesitar de un entorno gráfico.
Estamos entonces pensando que el servidor que hemos contratado es demasiado pequeño y vayamos a contratar uno más grande. Pero antes merece la pena no entrar en más gastos y optimizarlo. Porque tal vez tengamos mucha más máquina que lo que estamos pensando, sólo era necesario optimizar.
Instalación de htop
$ sudo apt-get install htop
Una vez instalado ejecutamos htop si todo ha ido bien y ya tenemos un informe muy interesante. Ahora sabremos si estamos al borde del colapso, si el servidor de base de datos está consumiendo demasiado, etcétera. O si simplemente le sobra memoria y algo raro le está pasando.
Frentes de ataque para optimizar un servidor
Se supone que con un servidor pequeño, de 1 procesador y 1 Giga de RAM, se deben de poder servir alrededor de 10 000 vistas de página diarias. Es mucho ¿cierto? Pues sí, no estoy exagerando, la experiencia nos dice que las configuraciones por defecto de Apache, MariaDB y PHP tal vez no se acomoden bien y el servidor vaya lento, muestre páginas en blanco, se caiga el servicio.
Para cada programa o servicio se necesita su configuración así que sin contemplar la posibilidad de ampliar el servidor físicamente podemos optimizarlo viendo lo siguiente.
Configuraciones de Apache2
En un Ubuntu Server podemos encontrar sus configuraciones en /etc/apache2/apache2.conf Una de las cosas que merece la pena activar es la caché, aumenta considerablemente su rendimiento.
Si tenemos, como en éste caso una única máquina con todo en el mismo servidor (Apache2, MariaDB y PHP5). La memoria caché APC es una buena opción y se activa muy fácilmente con PHP5 si la tenemos disponible ya en Apache2.
Configuraciones de MariaDB
He escogido ésta base de datos porque trae muchas mejoras con respecto a MySQL y podemos instalar cualquier CMS compatible con MYSQL. Aparte de que es totalmente gratis.
Cuidado con la versión que instalemos, elegir mejor una estable para producción.
Las configuraciones de MariaDB las podemos optimizar en /etc/mysql/my.cnf
Es interesante instalarnos localmente MySQL y ver los fichers my-small.cnf, my-medium.cnf, my-large.cnf y my-huge.cnf para configurar los límites de nuestra MariaDB. Cuidado porque un servidor small se supone que sólo tiene 64 MB de RAM, uno de 1 GB de RAM es un servidor grande aunque no nos lo parezca, ya uno de 4 GB de RAM es enorme (huge).
Configuraciones de PHP
Tenemos en /etc/php5.6/apache2/php.ini las configuraciones que se usan para correr los scripts de PHP desde Apache.
Puede ser interesante optimizar la configuración de la linea de comandos de PHP con el fichero /etc/php5.6/cli/php.ini Éste fichero es el que se usa cuando ejecutas php desde línea de comandos. Puede ser necesario configurarlo para usar phpunit, comandos de consola de frameworks PHP, etc.
La caché de ejecución de scripts o el tiempo máximo de ejecución de un script pueden ser valores clave que provoquen que tus webs se queden en blanco. Algunos valores a los que suelo darle más son:
max_input_vars
max_upload_file_size
memory_limit
max_input_time
max_input_nesting_level
Si delegas la ejecución de PHP en el servicio FPM/Fastcgi sería lo mejor. Para esto hay que instalar el módulo fpm de PHP. Y el módulo de Apache para que delegue la ejecución de scripts PHP a este servicio llamado php-fpm. En este caso, tendrás las mismas configuraciones que cito antes pero en otro fichero que carga desde /etc/php5.6/fpm/php.ini, /etc/php7.2/fpm/php.ini según la versión de PHP que tengas instalada.
Cuando se instala el FPM/Fastcgi lo que conseguimos es que tanto Apache2 como PHP se ejecuten concurrentemente, pudiendo servir más páginas en paralelo.
Está la swap creada y activada?
Por último puede ser que la memoria de intercambio no esté creada. En muchos servidores virtuales simplemente tenemos la partición del sistema de ficheros principal. Damos por sentado que cuando se nos ha dado el servidor ya tenemos swap. Entonces si realmente no la tenemos no podemos usarla y si llenamos toda la memoria RAM ya tenemos colapsado el servidor porque no tiene realmente swap.
Podemos verlo usando:
$ free -m
Por ejemplo en un servidor con 1 GB de RAM y 512 GB de memoria de intercambio swap podemos tener lo siguiente:
total used free shared buffers cached
Mem: 992 503 488 37 31 200
-/+ buffers/cache: 272 720
Swap: 511 0 511
Si no nos sale algo parecido ya tenemos otra cosa que optimizar.
Apache Benchmark
Es interesante llevar al límite a nuestro servidor usando ésta herramienta, podemos simular fácilmente varios visitantes simultáneos hasta llegar a saturar el servidor y sabremos así cuánto aguanta y si ya es suficiente.
De nuevo si tenemos Linux como máquina local es muy sencillo instalarlo sólo con poner:
$ sudo apt-get install apache2-utils
Por ejemplo si quiero ejecutar 100 peticiones de 10 visitantes simultáneamente a mi máquina local escribimos:
$ ab -n 100 -c 10 http://localhost/
En mi caso, me sale los siguientes resultados que son bien interesantes. Junto con htop podemos ver en tiempo real qué ha pasado con nuestro servidor.
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)…..done
Server Software: Apache/2.4.7
Server Hostname: localhost
Server Port: 80
Document Path: /
Document Length: 5306 bytes
Concurrency Level: 10
Time taken for tests: 2.751 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 560500 bytes
HTML transferred: 530600 bytes
Requests per second: 36.35 [#/sec] (mean)
Time per request: 275.072 [ms] (mean)
Time per request: 27.507 [ms] (mean, across all concurrent requests)
Transfer rate: 198.99 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 0
Processing: 21 274 659.4 58 2242
Waiting: 21 271 653.4 56 2225
Total: 21 274 659.4 58 2242
Percentage of the requests served within a certain time (ms)
50% 58
66% 65
75% 75
80% 79
90% 2241
95% 2242
98% 2242
99% 2242
100% 2242 (longest request)
Puede ser un poco bruto pero ya puestos a llevar al extremo a nuestro servidor no está de sobra probarlo. Si el servidor aguanta el test entonces eso es buena señal. Si de repente ya no tenemos las webs visibles. Jeje, pues a optimizar.
Hay personas que dedican todo su trabajo a optimizar cada uno de éstos programas. Espero que comprenda que no puedo resumirlos en un sólo post así que aquí lo dejo y me remito a la documentación oficial.
http://httpd.apache.org/docs/2.0/es/
https://mariadb.com/kb/es/
http://php.net/manual/es/
Espero que haya servido de guía.
Saludos 🙂
