Aquí estoy lamiéndome las heridas de esta noche pasada. Hace unas semanas un cliente me contactó para preparar para alta capacidad una página web que administra. La página web sirve para hacer las inscripciones a una carrera de motos y el día de las inscripciones aquello se pone a fuego.
Tras un presupuesto super ajustado, el cliente opta por la opción más económica. El resultado? pues tras varios “yaque” (instálame un servidor de correo “yaqueestás”), prisas y cambios a último momento, un aumento considerable del tráfico respeto el año pasado y vete a saber que más, el servidor ha estado super saturado y no ha podido servir todas las peticiones necesarias en tiempo y forma; al menos lo importante, que son las inscripciones, se hicieron y con un bajo porcentaje de fallo.
La aplicación está hecha con zendframework2, ergo php5.6, con configuraciones a fuego en el código de la configuración del servidor, correo, etc. Además la web se encontraba en un servidor CentOS 7.0 (del 2014), con unas configuraciones crípticas, no, lo siguiente. ¿Lo de respetar los directorios según LHFS?, ¡¿pa’qué?!.
Para no tener que tocar la configuración del servidor que estaba funcionando, decidí desplegar la página web en otro servidor en mi humilde infraestructura y realizar primero ahí las pruebas.
El entorno de pruebas
Se montó una maquina virtual lxc con debian 11, con 8Gb de RAM y 2 CPU Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz, en mi humilde infraestructura tengo un cuello de botella pendiente de solucionar que es el CEPH, que al tenerlo sobre ethernet a la que metes un poco de caña a la infraestructura los iouts de disco se ponen por las nubes.
La configuración
Inicialmente la aplicación ya estaba montada con nginx + apache. En la nueva configuración he añadido el servidor varnish cache.
nginx
Lo primero que hice fue simplificar la configuración y hacerla mucho más entendible para evitar bucles raros.
root@test:/etc/nginx/sites-enabled# vi web
server {
server_name dominio.com
www.dominio.com;
if ($host = dominio.com) {
return 301 https://www.dominio.com$request_uri;
}
if ($host = www.dominio.com) {
return 301 https://www.dominio.com$request_uri;
}
}
server {
server_name www.dominio.com;
#include snippets/certbot.conf;
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_certificate /etc/letsencrypt/live/www.dominio.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/www.dominio.com/privkey.pem; # managed by Certbot
error_log /var/log/nginx/doimnio.com.error.log error;
include snippets/proxy.conf;
}
El contenido del snippet:
root@test:/etc/nginx/snippets# vi proxy.conf
location / {
proxy_pass http://127.0.0.1:6081;
#proxy_pass http://127.0.0.1:8080;
include proxy_params;
location ~ \.php$ {
proxy_pass http://127.0.0.1:6081;
#proxy_pass http://127.0.0.1:8080;
include proxy_params;
}
proxy_headers_hash_max_size 512;
proxy_headers_hash_bucket_size 128;
fastcgi_read_timeout 300;
proxy_read_timeout 300;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Host $remote_addr;
add_header X-Frame-Options SAMEORIGIN;
}
El puerto 8080 es para conectar directamente con la aplicación servida con el apache, el 6081 para hacerlo a través de varnish.
Apache
La configuración de apache está hecha para funcionar sobre php-fpm en lugar de libapache2-mod-php. El motivo es porqué php-fpm es posible adaptarlo más a los recursos disponibles de la máquina. Aquí cogí el fichero de configuración y lo limpié un poco, además la aplicación si la movías de su sitio original, dejaba de funcionar, así que tuve preservar la ruta, además de un FCGIWrapper raro (estaba ahí el binario metido al directorio, lo moví e hice un symlink al del sistema). Aquí puedes ver los logs activados, pero al momento de poner en marcha el servidor de producción comenté estas líneas, al igual que el log del nginx, para evitar las escrituras a disco.
root@test:/etc/apache2/sites-enabled# vi web.conf
<VirtualHost *:8080>
ServerName www.dominio.com
ServerAlias dominio.com
ServerAdmin info@dominio.com
DocumentRoot /home/admin/web/dominio.com/public_html
ScriptAlias /cgi-bin/ /home/admin/web/dominio.com/cgi-bin/
Alias /vstats/ /home/admin/web/dominio.com/stats/
Alias /error/ /home/admin/web/dominio.com/document_errors/
CustomLog ${APACHE_LOG_DIR}/dominio.com.bytes bytes
CustomLog ${APACHE_LOG_DIR}/dominio.com.log combined
ErrorLog ${APACHE_LOG_DIR}/dominio.com.error.log
<Directory /home/admin/web/dominio.com/public_html>
AllowOverride All
Options +Includes -Indexes +ExecCGI
FCGIWrapper /home/admin/web/dominio.com/cgi-bin/fcgi-starter .php
</Directory>
<Directory /home/admin/web/dominio.com/stats>
AllowOverride All
</Directory>
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php5.6-fpm.sock|fcgi://localhost"
</FilesMatch>
IncludeOptional /home/admin/conf/web/httpd.dominio.com.conf*
</VirtualHost>
Para tener funcionando nginx y apache al mismo momento, le decimos a apache que solo trabaje con el puerto 8080, además sólo escuchará en local, ya que los usuarios no tienen que porqué conectarse por este puerto. El contenido del fichero ports.conf será de una sola línea, todo lo demás tiene que ir comentado.
root@test:/etc/apache2# vi ports.conf Listen 127.0.0.1:8080
Además tenemos que indicarle que el directorio donde está la web es válido
root@test:/etc/apache2# vi apache2.conf
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
<Directory /home/admin/web/dominio.com/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
Finalmente vamos a desactivar php y apache-prefork y activar apache-worker y fcgi:
root@test:/etc/apache2# a2dismod php5.6 php7.4 mpm_prefork root@test:/etc/apache2# a2enmod proxy_fcgi mpm_worker
Para configurar mpm_worker, modificaremos el siguiente fichero, con la configuración:
root@test:/etc/apache2# vi mods-enabled/mpm_worker.conf
<IfModule mpm_worker_module>
# Original config
#StartServers 2
#MinSpareThreads 25
#MaxSpareThreads 75
#ThreadLimit 64
#ThreadsPerChild 25
#MaxRequestWorkers 150
#MaxConnectionsPerChild 0
# 4 CPU config
ServerLimit 2800
StartServers 4
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 2800
MaxConnectionsPerChild 1000
# 16 CPU config
#ServerLimit 11200
#StartServers 16
#MinSpareThreads 100
#MaxSpareThreads 300
#ThreadLimit 256
#ThreadsPerChild 100
#MaxRequestWorkers 11200
#MaxConnectionsPerChild 4000
</IfModule>
MariaDB/MySQL
Otro de los servicios que consumen gran cantidad de recursos es la base de datos. En la página web que se está usando, se hacen varias peticiones a la bbdd, que algunas, según mi opinión se podrían descartar. Como el alcance del trabajo no consistía en modificar el código de la web (¡valgamedios!) lo que hice fue activar la cache de MySQL, de esta forma, consultas que ya se han realizado en anterioridad, están almacenadas en la RAM y no es necesario recurrir a la base de datos para mostrar la consulta. Añado también sql-mode = “” para que sea compatible con inserts con null mal formados (” en lugar de null). Dejo también el bind-address a localhost; nadie mas que la aplicación tiene que acceder a este servidor MySQL.
root@test:/etc/mysql/mariadb.conf.d# vi 50-server.cnf [mysqld] sql-mode = "" bind-address = 127.0.0.1 query_cache_type=1 query_cache_size = 10M query_cache_limit=256K
varnish
Y aquí tenemos a la estrella de la fiesta. Varnish hace que una página web dinámica se cargue como una estática, además de que activa por defecto la compresión gzip, cosa que hace que se optimice mucho más el ancho de banda y el resultado sea un tiempo de carga de la página mucho inferior.
La configuración de varnish se encuentra en /etc/default/varnish
root@test:/etc/default# vi varnish
# 4 CPU config
DAEMON_OPTS="-a :6081 \
-T localhost:6082 \
-f /etc/varnish/default.vcl \
-S /etc/varnish/secret \
-s malloc,3G"
# 16 CPU config
#DAEMON_OPTS="-a :6081 \
# -T localhost:6082 \
# -f /etc/varnish/default.vcl \
# -S /etc/varnish/secret \
# -p thread_pools=14 \
# -p thread_pool_min=200 \
# -p thread_pool_max=5000 \
# -p listen_depth=128 \
# -p thread_pool_add_delay=2\
# -p lru_interval=20 \
# -h classic,72227 \
# -p session_linger=120 \
# -p sess_workspace=32768 \
# -p connect_timeout=600 \
# -s malloc,15G"
En la máquina de pruebas destino 3Gb a varnish, en la de producción que tiene 64Gb de RAM, la dejo a 15G
Después está el fichero de cache, que lo dejo por defecto, ya que no da tiempo de implementar en el código un purge de la cache cuando haya cambios en la página web. En varnish la cache se vacía o usando PURGE o reiniciando varnish. Apuntamos varnish al puerto 8080 que es donde se encuentra apache.
root@test-cenics:/etc/varnish# vi default.vcl
#
# This is an example VCL file for Varnish.
#
# It does not do anything by default, delegating control to the
# builtin VCL. The builtin VCL is called when there is no explicit
# return statement.
#
# See the VCL chapters in the Users Guide for a comprehensive documentation
# at https://www.varnish-cache.org/docs/.
# Marker to tell the VCL compiler that this VCL has been written with the
# 4.0 or 4.1 syntax.
vcl 4.1;
# Default backend definition. Set this to point to your content server.
backend default {
.host = "127.0.0.1";
.port = "8080";
}
sub vcl_recv {
# Happens before we check if we have this in cache already.
#
# Typically you clean up the request here, removing cookies you don't need,
# rewriting the request, etc.
}
sub vcl_backend_response {
# Happens after we have read the response headers from the backend.
#
# Here you clean the response headers, removing silly Set-Cookie headers
# and other mistakes your backend does.
}
sub vcl_deliver {
# Happens when we have all the pieces we need, and are about to send the
# response to the client.
#
# You can do accounting or modifying the final object here.
}
Las pruebas de carga
Para realizar las pruebas de carga usé curl y ab de apache.
curl
Curl lo usé para mirar el tiempo de respuesta de la página, tanto sin carga, como con carga. Para ello desde una máquina distinta al servidor de pruebas y distinta a la que usé para hacer el ab de apache, crée este fichero con este contenido
root@fermat:~# vi curl-format.txt
time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
———\n
time_total: %{time_total}\n\n
Y ejecuté curl de esta forma
root@fermat:~# curl -w "@curl-format.txt" -o /dev/null -s https://www.dominio.com/ time_namelookup: 0.004 time_connect: 0.030 time_appconnect: 0.000 time_pretransfer: 0.000 time_redirect: 0.000 time_starttransfer: 0.000 ——— time_total: 0.057
Apache workbench (ab)
Para hacer las pruebas de carga, usé un servidor que tengo con 24Gb de RAM y 12 CPU Intel(R) Xeon(R) CPU D-1531 @ 2.20GHz. Apache workbench (ab), está dentro del paquete apache2-utils
root@electra:~# ab -n 1000 -c 50 https://www.dominio.com/
Con esto le estamos diciendo, haz 1.000 peticiones con una concurrencia de 50 (es decir, 50 de golpe)
Resultados del benchmarking
Hice las pruebas primero en el servidor de pruebas y después en el servidor de producción que finalmente fue una instancia de OVH con 4CPU Intel Core Processor (Haswell, no TSX) con 16Gb de RAM.
servidor de pruebas
Prueba sin carga root@fermat:~# curl -w "@curl-format.txt" -o /dev/null -s https://dominio.com/ time_namelookup: 0.004 time_connect: 0.028 time_appconnect: 0.000 time_pretransfer: 0.000 time_redirect: 0.000 time_starttransfer: 0.000 ——— time_total: 0.054 Prueba con carga root@fermat:~# curl -w "@curl-format.txt" -o /dev/null -s https://dominio.com/ time_namelookup: 0.004 time_connect: 0.031 time_appconnect: 0.000 time_pretransfer: 0.000 time_redirect: 0.000 time_starttransfer: 0.000 ——— time_total: 0.060
En esta la máquina se ponía a todo trapo y aprovechaba todos los recursos de la maquina (glances). El resultado mirando varnishstat era de: 28-35, 59-67, 85-90, 31-37, 9-16: 7, 8, 5, 6, 7 (peticiones por segundo)
El resultado del comando ab
root@electra:~# ab -n 1000 -c 50 https://dominio.com/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking dominio.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: nginx/1.18.0
Server Hostname: dominio.com
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,4096,256
Server Temp Key: X25519 253 bits
TLS Server Name: dominio.com
Document Path: /
Document Length: 61939 bytes
Concurrency Level: 50
Time taken for tests: 158.840 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 62426228 bytes
HTML transferred: 61939000 bytes
Requests per second: 6.30 [#/sec] (mean)
Time per request: 7942.002 [ms] (mean)
Time per request: 158.840 [ms] (mean, across all concurrent requests)
Transfer rate: 383.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 75 90 52.0 79 482
Processing: 385 7658 946.4 7819 8449
Waiting: 354 7633 946.2 7794 8423
Total: 462 7749 927.2 7900 8612
Percentage of the requests served within a certain time (ms)
50% 7900
66% 7986
75% 8052
80% 8084
90% 8172
95% 8232
98% 8304
99% 8405
100% 8612 (longest request)
servidor de producción 4CPU
Prueba sin carga root@fermat:~# curl -w "@curl-format.txt" -o /dev/null -s https://dominio.com/ time_namelookup: 0.004 time_connect: 0.031 time_appconnect: 0.000 time_pretransfer: 0.000 time_redirect: 0.000 time_starttransfer: 0.000 ——— time_total: 0.059 Prueba con carga root@fermat:~# curl -w "@curl-format.txt" -o /dev/null -s https://dominio.com/ time_namelookup: 0.004 time_connect: 0.030 time_appconnect: 0.000 time_pretransfer: 0.000 time_redirect: 0.000 time_starttransfer: 0.000 ——— time_total: 0.078
Peticiones por segundo: 967-301, 035-308, 145-473: 334, 273, 328
La salida de ab
root@electra:~# ab -n 10000 -c 50 https://dominio.com/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking dominio.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
^C
Server Software: nginx/1.18.0
Server Hostname: dominio.com
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,4096,256
Server Temp Key: X25519 253 bits
TLS Server Name: dominio.com
Document Path: /
Document Length: 62664 bytes
Concurrency Level: 50
Time taken for tests: 16.857 seconds
Complete requests: 5371
Failed requests: 0
Total transferred: 339059660 bytes
HTML transferred: 336794736 bytes
Requests per second: 318.63 [#/sec] (mean)
Time per request: 156.923 [ms] (mean)
Time per request: 3.138 [ms] (mean, across all concurrent requests)
Transfer rate: 19642.83 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 32 69 12.3 67 198
Processing: 24 87 16.3 85 185
Waiting: 19 65 12.3 64 139
Total: 57 156 25.2 153 305
Percentage of the requests served within a certain time (ms)
50% 153
66% 162
75% 169
80% 172
90% 185
95% 203
98% 225
99% 238
100% 305 (longest request)
Con esto la máquina daba señales que sería capaz de gestionar el numero de peticiones que pidió el cliente.
Conclusiones
Esto con la propuesta ampliación a 16 cores, nos daba indicios que el tunning era suficiente para satisfacer un numero similar a las visitas que ocurrieron el año anterior.
Subimos la máquina a 16 cores 3 horas antes del inicio de las inscripciones (estas cosas de ahorrar dinero y tal) y apliqué la configuración que has visto comentada en los ficheros de configuración y mi sorpresa fué que quien se saturaba ahora era el php-fpm y que sólo levantaba 4 threads. Esto hizo que la máquina en lugar de alcanzar el 100% de CPU, se quedase a 30-35% y de consumo de RAM 64Gb) no subiese del 25%.
Pero la puesta en marcha del servidor de producción tuvo un par de detallitos mas, además de la falta de tiempo y mi poca experiencia en entornos de alto estrés (avisado de previa mano a mi cliente), la necesidad de instalar un servidor de correo (novedad respeto el año pasado que estaba fuera)… venga, métele a un servidor con mucha carga, un modoboa completico con postfix, dovecot, dkim, amavis, etc., mandando 3 correos electrónicos por inscripción (el correo al usuario y al administrador de la web, la recolección del correo del administrador de la web y el reenvio al alias del administrador de la web).
Además, las pruebas que habíamos hecho, no contemplaban insercciones en la base de datos (que en el momento crítico este almenos parece que estaba alto pero no saturado, oscilaba entre el 2% y el 60% de CPU en un solo thread).
Y lo más crítico, casi el doble de peticiones del año anterior (¿se terminó la pandemia?, ¡todos a la carretera!)
El momento crítico ha sido des de la apertura de las inscripciones a las 23:45 hasta las 01:15 que es cuando empezaron a bajar las peticiones (que segun varnishstat han sido de entre 60 y 130 peticiones por segundo durante la hora y media que ha durado el chaparrón de usuarios). Durante el momento de mas carga, de la cual 1,5h ha sido crítica (23h a 2h) ha habido un total de 29.544 visitas (26% mas que el año pasado) y visitantes únicos 2.852 (70% mas que el año pasado) a la web de inscripciones.
Esto ha hecho que algunos pagos fallasen o incluso se duplicasen (aprox 40 de ~857), en total de registros (pagados o no) es de 2780.
Por desgracia no tomé capturas de pantalla del momento de carga real del servidor. Reinicié los servicios, de poco sirvió, reinicié la máquina bajo mi resistencia, también de poco sirvió. En aquel momento era cruzar los dedos y confiar que la máquina hiciese el trabajo lo mejor posible. En algún momento había errores 500 que directamente el nginx no soportaba mas peticiones y 503 del varnish donde era el apache que daba timeout. Los momentos que era capaz de servir la página tardaba entre 3 y 20 segundos. El curl seguía respondiendo bastante rápido con respuestas de 0.2s.
Durante el chaparrón aplicamos algunos métodos para descargar la máquina, como vaciar la cola del postfix que estaba llena de mails en espera a enviar al correo del administrador (el alias), donde microsoft rechazaba los correos por exceso de envios. Tras esto modificamos el código para que no mandase el mail al administrador tras cada inscripción. Estas dos acciones permitieron dar un poco mas de aire al servidor.
La cosa es que ahora el cliente está enfadado de que la web, durante una hora y media, no respondió según lo esperado; por parte de los técnicos, que llevamos horas comparando los datos con el año anterior, nos quedamos con que nos hemos salvado de un fail absoluto y que el trabajo técnico realizado ha sido bastante notable. A la hora de escribir este post, el cliente final se ha puesto en el bolsillo alrededor de 4 ceros (con un ocho delante). El miércoles reunión para ver cuanto de enfadado está el cliente finalmente, de momento está en modo que el año que viene que no quiere repetir. Yo personalmente, tal como se ha trabajado, e incluso poniéndome presión el último día de mis vacaciones y con unos tiempos y presupuesto tan ajustado, tampoco.
No sé cuál fue la configuración que nos jodió y no nos permitió darle mas tralla a la máquina, se aceptan propuestas con el caso y los datos planteados a nivel de sistemas (la aplicación era la aplicación que era, si la configuración del primer servidor era kaos, imaginate el código). Lo que si que tengo claro es lo que digo siempre, 1 servidor – 1 servicio, sea en una máquina virtual o en otro servidor. Siempre da mucho mas juego diseñar un sistema entero para un servicio que un sistema para varios servicios, además evitas que se pisen procesos con otros. Una cosa que me quedó en el tinterio era tunear las tramas TCP, tal como hice en éste post.
Muchas gracias y espero que el post te haya sido interesante.
Links:
– NGINX Tuning For Best Performance
– 7 Tips for NGINX Performance Tuning
– How To Optimize MySQL with Query Cache on Ubuntu 18.04
Caram, caram… interesante. Si la aplicación tuviera más componentes estáticos podría ahorrarse unas cuantas peticiones al fpm. El cache frontal no es eficaz con cargas de datos dinámicas, por lo que si se usara html en el frontal para para la portada y la página de inicio de sesión y el formulario de inscripción fuera una ruta pública no condicionada por script de verificación de sesión (solo el POST) hasta se podría ahorrar nginx y varnish. Pero claro, en estos casos el código viene ya hecho y mal optimizado, así que toca hacer estos apaños. Salut.