Optimización del servidor de origen de la CDN para infraestructura dedicada

Optimizar tu servidor dedicado como origen de una CDN es algo muy distinto a optimizarlo para el tráfico directo de los usuarios. La CDN se encarga de la concurrencia y la distribución geográfica; el origen debe responder de forma fiable a las solicitudes de la CDN con encabezados de caché correctos, recursos comprimidos y un tiempo de respuesta mínimo hasta el primer byte.

En qué se diferencian las solicitudes al origen de la CDN de las solicitudes directas de los usuarios

Cuando se implementa una CDN delante de tu servidor dedicado, los patrones de tráfico de los usuarios cambian radicalmente:

Tráfico directo (sin CDN): cada solicitud de los usuarios llega directamente a tu servidor. Una alta concurrencia implica muchas conexiones simultáneas. El tiempo de respuesta afecta directamente a la experiencia del usuario.

Tráfico redirigido por CDN: los nodos periféricos de la CDN almacenan las respuestas en caché y las envían a los usuarios desde puntos de presencia (PoP) geográficos. Tu servidor de origen recibe solicitudes de la CDN, en su mayoría por fallos de caché relacionados con contenido nuevo o caducado. La concurrencia es menor, pero las solicitudes pueden ser menos predecibles (la caducidad de la caché provoca solicitudes simultáneas desde varios nodos periféricos).

Tormentas de fallos de caché: cuando un recurso muy solicitado caduca al mismo tiempo en todos los nodos de la CDN, varios nodos periféricos solicitan el mismo recurso a la vez. Si el servidor de origen tarda en responder, los fallos de caché se acumulan, lo que puede provocar que se sirva contenido obsoleto o que las solicitudes fallen durante el periodo de actualización. Cloudflare loCloudflare «escudo de origen»: al redirigir el tráfico de los nodos periféricos al de origen a través de un único nodo intermedio, se reduce el número de solicitudes simultáneas al servidor de origen durante la actualización de la caché.

Nginx para mejorar el rendimiento del servidor de origen de la CDN

Nginx en tu servidor dedicado requiere ajustes diferentes para el servicio de origen y para el servicio directo al usuario.

Procesos de trabajo y conexiones:

# /etc/nginx/nginx.conf

# Match worker count to CPU cores

worker_processes auto;

# Increase for origin serving high-traffic CDN pulls

events {

    worker_connections 4096;

    use epoll;

    multi_accept on;

}

# /etc/nginx/nginx.conf

# Match worker count to CPU cores

worker_processes auto;

# Increase for origin serving high-traffic CDN pulls

events {

    worker_connections 4096;

    use epoll;

    multi_accept on;

}

Keepalive para conexiones CDN: los nodos periféricos de la CDN envían solicitudes repetidas a tu servidor de origen. Las conexiones Keepalive eliminan la sobrecarga del protocolo TCP en cada solicitud:

http {

    # Keep connections to CDN alive

    keepalive_timeout 120s;

    keepalive_requests 1000;

    upstream origin_backend {

        server 127.0.0.1:8080;

        keepalive 64;  # Connection pool size

    }

}

http {

    # Keep connections to CDN alive

    keepalive_timeout 120s;

    keepalive_requests 1000;

    upstream origin_backend {

        server 127.0.0.1:8080;

        keepalive 64;  # Connection pool size

    }

}

Compresión Gzip en el servidor de origen: los nodos de la CDN suelen almacenar en caché la versión comprimida y servirla directamente. Configura Gzip en el servidor de origen para todos los tipos de archivos comprimibles:

gzip on;

gzip_vary on;

gzip_proxied any;

gzip_comp_level 6;

gzip_min_length 1024;

gzip_types

    text/plain

    text/css

    text/javascript

    application/javascript

    application/json

    application/xml

    image/svg+xml

    font/woff2;

gzip on;

gzip_vary on;

gzip_proxied any;

gzip_comp_level 6;

gzip_min_length 1024;

gzip_types

    text/plain

    text/css

    text/javascript

    application/javascript

    application/json

    application/xml

    image/svg+xml

    font/woff2;

El nivel 6 equilibra la relación de compresión con el consumo de CPU. Los niveles 7-9 ofrecen una compresión adicional mínima a costa de una carga significativa para la CPU; rara vez merece la pena para los recursos estáticos.

Encabezados Cache-Control: la configuración de origen más importante

El comportamiento de la CDN viene determinado casi por completo por los encabezados Cache-Control que envía tu servidor de origen. Si los configuras correctamente, la CDN almacenará en caché de forma agresiva (lo que reduce la carga del servidor de origen) o actualizará el contenido con frecuencia (lo que añade solicitudes innecesarias al servidor de origen).

Recursos estáticos (CSS, JS, imágenes, fuentes): establece un valor alto para «max-age» con las URL identificadas. Cuando cambia el contenido del archivo, cambia también el nombre del archivo (hash de contenido de Webpack, etc.), por lo que se puede almacenar en caché sin problemas:

location ~* \.(css|js|woff2|woff|ttf|jpg|jpeg|png|gif|ico|svg)$ {

    expires 1y;

    add_header Cache-Control "public, max-age=31536000, immutable";

    add_header Vary "Accept-Encoding";

}

location ~* \.(css|js|woff2|woff|ttf|jpg|jpeg|png|gif|ico|svg)$ {

    expires 1y;

    add_header Cache-Control "public, max-age=31536000, immutable";

    add_header Vary "Accept-Encoding";

}

La directiva «immutable» indica a la CDN y a los navegadores que nunca vuelvan a validar esta URL: el contenido nunca cambiará en esta URL.

Páginas HTML: caché breve o sin caché. El HTML cambia con las actualizaciones de contenido y no debería almacenarse en caché de forma agresiva a menos que hayas implementado una invalidación de caché adecuada:

location / {

    add_header Cache-Control "public, max-age=300, stale-while-revalidate=60";

}

location / {

    add_header Cache-Control "public, max-age=300, stale-while-revalidate=60";

}

stale-while-revalidate=60 permite que la CDN sirva una respuesta HTML ligeramente desactualizada mientras se descarga una copia actualizada en segundo plano; esto reduce las solicitudes al servidor de origen sin que los usuarios vean contenido desactualizado durante más de 60 segundos.

Respuestas de la API: Normalmente sin caché o con un TTL corto:

location /api/ {

    add_header Cache-Control "private, no-store";

}

location /api/ {

    add_header Cache-Control "private, no-store";

}

Configuración de Origin Shield

Un «origin shield» es una función de la CDN que redirige todo el tráfico de los nodos periféricos al servidor de origen a través de un único punto de presencia (PoP) regional, en lugar de permitir que todos los nodos periféricos globales obtengan los datos directamente de tu servidor de origen. La ventaja práctica: en lugar de que 50 nodos periféricos soliciten cada uno el mismo recurso cuando caduca la caché, un único nodo «shield» realiza la solicitud y distribuye la respuesta almacenada en caché a los demás nodos periféricos.

La caché por nivelesCloudflare implementa esto mediante una topología de caché inteligente por niveles que selecciona automáticamente el punto de presencia (PoP) intermedio más adecuado en función de tus patrones de tráfico. Actívala en el Cloudflare , en la sección «Caching» > «Tiered Cache».

Para los servidores de origen del centro de datos de InMotion en Los Ángeles, el nivel «West US» Cloudflareofrece la menor latencia entre el escudo y el servidor de origen. Para el centro de datos de Ámsterdam, lo más adecuado es el nivel «Western Europe».

Servicio de recursos estáticos desde NVMe: configuración de E/S

NVMe de tu servidor dedicado envían recursos estáticos a los nodos periféricos de la CDN. El rendimiento NVMe rara vez es el cuello de botella en el envío de archivos estáticos: normalmente, el ancho de banda de la red alcanza sus límites antes NVMe . Pero la configuración del sistema de archivos influye en la velocidad de envío:

Caché de archivos abiertos: Nginx los descriptores de archivos y los resultados de stat() para los archivos que se sirven con frecuencia:

open_file_cache max=10000 inactive=30s;

open_file_cache_valid 60s;

open_file_cache_min_uses 2;

open_file_cache_errors on;

open_file_cache max=10000 inactive=30s;

open_file_cache_valid 60s;

open_file_cache_min_uses 2;

open_file_cache_errors on;

Esto elimina las llamadas repetidas a las funciones del sistema open() y stat() para los mismos archivos, lo que supone una mejora notable en el servicio de contenido estático con un alto volumen de solicitudes.

Sendfile: Usa la llamada al sistema sendfile() del núcleo en lugar de read()+write() para la transferencia de archivos. Transferencia de datos sin copia:

sendfile on;

tcp_nopush on;  # Agrupa las llamadas a sendfile para mejorar la eficiencia

tcp_nodelay on; # Desactiva Nagle una vez enviados los datos

sendfile on;

tcp_nopush on;  # Batch sendfile calls for efficiency

tcp_nodelay on; # Disable Nagle after data is sent

AIO para archivos grandes: Para archivos de vídeo, descargas pesadas u otros archivos de más de 1 MB:

aio on;

directio 512;  # Usa E/S directa para archivos de más de 512 bytes

output_buffers 2 128k;

aio on;

directio 512;  # Use direct I/O for files over 512 bytes

output_buffers 2 128k;

Supervisión del rendimiento del servidor de origen desde la perspectiva de la CDN

La supervisión estándar del servidor muestra el uso de recursos de tu servidor. Para evaluar el rendimiento del origen desde la perspectiva de la CDN, es necesario realizar una supervisión desde la capa de la CDN.

Cloudflare muestra el tiempo de respuesta del origen (el tiempo que tarda en ir desde el punto de borde de la CDN hasta tu servidor y volver), la tasa de aciertos en caché y las tasas de error. Objetivo:

• Índice de aciertos en la caché: más del 85 % para sitios con mucho contenido, más del 95 % para sitios con muchos recursos estáticos
• Tiempo de respuesta del servidor de origen (TTFB en el borde): menos de 100 ms para las respuestas almacenadas en caché, menos de 500 ms para las solicitudes al servidor de origen
• Índice de errores de origen (5xx): inferior al 0,1 %

El análisis del registroNginx muestra lo que la CDN solicita realmente a tu servidor de origen. Un gran volumen de solicitudes para la misma URL indica un problema de almacenamiento en caché: o bien la URL no se está almacenando en caché, o bien la caché caduca con demasiada frecuencia:

# Buscar las URL más solicitadas (posibles fallos de caché)

awk '{print $7}'nginx.log | sort | uniq -c | sort -rn | head -20

# Find most frequently requested URLs (potential caching misses)

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Si las mismas URL dinámicas aparecen una y otra vez, es porque o bien no se pueden almacenar en caché (lo cual es normal en los puntos finales de API) o bien les faltan los encabezados Cache-Control (algo que se puede solucionar).

WordPress origen de CDN

WordPress suelen funcionar a través de una CDN con un servidor dedicado como origen. WP Rocket, W3 Total Cachey LiteSpeed Cache admiten la integración con CDN y gestionan automáticamente los encabezados Cache-Control para los tipos de contenido WordPress.

WordPress clave WordPress para el servicio de origen de CDN:

• Activa el almacenamiento en caché de objetos con Redis (reduce el tiempo de generación dinámica de páginas y mejora el TTFB del servidor de origen)
• Establece el tiempo de vida (TTL) de la caché de la página entre 30 y 60 minutos para los usuarios que no hayan iniciado sesión
• Excluye del almacenamiento en caché las URL de administración, el carrito, la página de pago y las páginas de cuenta
• Activa la integración con la CDN en el plugin de almacenamiento en caché para reescribir las URL de los recursos con los nombres de dominio de la CDN

El plan Premier Care InMotion Hostingincluye una hora de asesoramiento de InMotion Solutions para equipos que configuran la integración de una CDN por primera vez; esa hora mensual de asesoramiento se puede usar para revisar y optimizar la configuración de la CDN.

Lecturas relacionadas: Optimización de la latencia de red para servidores dedicados | Supervisión de recursos del servidor y ajuste del rendimiento