Reducir la carga del servidor

En este artículo, analizaremos en profundidad las causas del aumento de la carga del servidor y analizaremos diversas maneras de optimizar los procesos con alta carga. Se prestará especial atención a la optimización de código en Apache/Nginx y MySQL, abordaremos el almacenamiento en caché como herramienta auxiliar y consideraremos posibles amenazas externas, como los ataques DDoS, y cómo prevenirlos.

¿Por qué se produce la carga del servidor?

Antes de proceder a la optimización del servidor, es necesario realizar un análisis exhaustivo de la carga actual de recursos. Esto incluye medir la carga de la CPU, el uso de RAM, la actividad de la red y otros parámetros clave. Comprender la dinámica y los picos de carga permite identificar cuellos de botella y optimizar la asignación de recursos, mejorando así la estabilidad y el rendimiento de la infraestructura del servidor.

Para la resolución inicial de problemas de alta carga del servidor, recomendamos realizar una diagnóstico general del servidorSi esto no es suficiente, se puede realizar una revisión más detallada. análisis de recursos es necesario. Como herramienta auxiliar, explorar la registros de Linux El servidor puede ser útil, ya que es aquí donde se encuentra la fuente del problema en la mayoría de los casos.

Optimización del servidor Apache/Nginx

Aumento de la carga del servidor debido a la indexación

El aumento de carga debido a la indexación en el servidor puede ocurrir, por ejemplo, cuando los motores de búsqueda escanean un gran número de páginas de su sitio. Esto puede provocar un mayor uso de los recursos del servidor y, en consecuencia, ralentizar el rendimiento del sitio. Identificar la causa es relativamente sencillo; debe abrir el archivo ubicado en:

/var/www/httpd-logs/sitename.access.log

Al ser indexado por los motores de búsqueda, el usuario verá entradas de la siguiente naturaleza:

11.22.33.44 - - [Date and Time] "GET /your-page-path HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Como primera solución para reducir la carga, puedes utilizar la configuración de metaetiquetas "sin índice" y "no seguir" en páginas que no necesitan indexarse. La segunda solución es la .htaccess archivo donde se deben agregar entradas correspondientes a motores de búsqueda específicos, por ejemplo, para ocultarse de Yandex y Google:

SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot

De igual forma, es necesario realizar modificaciones para otros motores de búsqueda. Cabe destacar que las capacidades de .htaccess no se limitan a bloquear la indexación. Recomendamos familiarizarse con sus principales funciones en... artículo.

Uso de la configuración de almacenamiento en caché

Una configuración incorrecta del almacenamiento en caché en el servidor también puede provocar una carga elevada. Para optimizar este parámetro, es necesario realizar los cambios correspondientes en los archivos de configuración o .htaccessEn el caso de Apache, es preferible la última opción; para Nginx, la primera.

En una APACHE servidor, necesitas abrir el .htaccess archivo e inserte el siguiente código:

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

Luego, habilite el Expira módulo usando el comando:

sudo a2enmod expires

Luego de lo cual, reinicie el servidor web:

sudo service apache2 restart

Y activa el módulo especificando:

ExpiresActive On

En un Nginx servidor, basta con agregar el siguiente código al archivo de configuración:

location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}

Y realizar una recarga del servicio:

sudo service nginx restart

Tenga en cuenta que con esta configuración, el Permitir y Denegar Se pasarán por alto las directivas.

Uso de la compresión de datos

Habilitación de la compresión de datos mediante Gzip en los servidores web Apache y Nginx ayuda a reducir la cantidad de datos transmitidos entre el servidor y el cliente, lo que mejora el rendimiento y reduce el tiempo de carga de la página web.

Para permitir Gzip on APACHE, necesitas activar el mod_deflate módulo:

sudo a2enmod deflate

Luego, reinicie el servidor web:

sudo service apache2 restart

Y por último, agregue el siguiente bloque al archivo de configuración o .htaccess:

<IfModule mod_deflate.c>
# Configure compression for specified file types
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json

# If the browser matches the specified pattern, apply compression only to text/html files
BrowserMatch ^Mozilla/4 gzip-only-text/html

# If the browser matches the specified version patterns of Mozilla 4.0.6, 4.0.7, 4.0.8, disable compression
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# If the browser is MSIE (Internet Explorer), disable compression for all files except text/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# If the request contains the specified pattern (extensions of image files), disable compression
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
</IfModule>

Esta configuración habilita la compresión para ciertos tipos de archivos y la deshabilita para las imágenes.

En el caso de los Nginx, la configuración se produce en el http Bloque del archivo de configuración. Se debe agregar el siguiente código:

gzip on;
gzip_disable "msie6";

# Adds the Vary header, indicating that the response may change depending on the Accept-Encoding header value
gzip_vary on;

# Enables compression for any proxy servers
gzip_proxied any;

# Sets the compression level. A value of 6 provides a good balance between compression efficiency and resource use
gzip_comp_level 6;

# Sets the size of the buffer for compressed data (16 buffers of 8 kilobytes each)
gzip_buffers 16 8k;

# Specifies that data compression should be used only for HTTP version 1.1 and higher
gzip_http_version 1.1;

# Sets the file types that can be compressed
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Similar a APACHEAquí se configuran los parámetros de compresión para ciertos tipos de archivos. Tras realizar cambios en cualquier servidor web, es necesario recargar el servicio:

sudo service apache2 restart

Or

sudo service nginx restart

Ataque DDOS al servidor

Un ataque DDoS puede generar una alta carga en el servidor. Para identificar un ataque DDoS, se puede monitorear un aumento repentino del tráfico, solicitudes anormales y caídas en el rendimiento del servidor. Revisar los registros para detectar solicitudes repetidas desde una dirección IP o escanear puertos también puede indicar un posible ataque DDoS. Existen muchas medidas de protección, pero solo abordaremos las básicas.

Uso de una CDN (red de distribución de contenido)Una CDN puede servir de intermediario entre su servidor web y los usuarios, distribuyendo el tráfico y almacenando en caché el contenido para mitigar el impacto de un ataque DDoS. Las CDN también pueden incorporar mecanismos de protección contra DDoS, como la distribución de carga y el filtrado de tráfico.

Configuración de firewalls y sistemas de detección de intrusiones (IDS/IPS)Los firewalls pueden configurarse para filtrar el tráfico según diversos criterios, como direcciones IP y puertos. Los sistemas IDS/IPS pueden detectar comportamientos anormales del tráfico y bloquear conexiones sospechosas. Estas herramientas pueden ser eficaces para rastrear y bloquear el tráfico potencialmente malicioso.

Configuración de servidores web Apache y Nginx para mitigar el impacto de los ataques DDoS.

Como solución para Apache, permitimos que mod_evasive módulo. Para ello, descomente o añada la siguiente línea en el httpd.conf or apache2.conf archivo de configuración:

LoadModule evasive20_module modules/mod_evasive.so

En el mismo archivo, debes agregar un bloque de configuración:

<IfModule mod_evasive20.c>
# Hash table size for storing request information
DOSHashTableSize 3097

# Number of requests to one page before activating protection
DOSPageCount 2
DOSPageInterval 1

# Number of requests to all pages before activating protection
DOSSiteCount 50
DOSSiteInterval 1

# Blocking period in seconds for IP addresses
DOSBlockingPeriod 10
</IfModule>

De manera similar, activamos el mod_ratelimit módulo:

LoadModule ratelimit_module modules/mod_ratelimit.so

Y agregamos la configuración:

<IfModule mod_ratelimit.c>
# Setting the output filter for rate limiting (Rate Limit)
SetOutputFilter RATE_LIMIT

# Beginning of the settings block for the location "/login"
<Location "/login">

# Setting the environment variable rate-limit with a value of 1
SetEnv rate-limit 1

# Ending of the settings block for the location "/login"
</Location>
</IfModule>

La configuración para Nginx es parecido a APACHE. En la nginx.conf archivo de configuración, se deben utilizar las siguientes directivas:

http {
...
# Defining a zone for connection limits
limit_conn_zone $binary_remote_addr zone=addr:10m;

# Defining a zone for request limits
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;

server {
        ...
        # Configuring connection limits
        limit_conn addr 10;

        # Configuring request limits
        limit_req zone=req_zone burst=5;

        ...
    }
}

Después de realizar cambios en cada uno de los servicios, es necesario volver a cargarlos:

sudo systemctl restart apache2

o:

sudo systemctl restart nginx

Estos ejemplos proporcionan sólo una configuración básica, que puede adaptarse aún más dependiendo de los requisitos específicos y la naturaleza de los ataques.

Optimización de consultas MySQL

La optimización de las consultas a bases de datos MySQL en un servidor web se puede lograr de varias maneras, y una de ellas es mediante la configuración correcta del archivo de configuración. Normalmente, este archivo se llama my.cnf or mi.ini y se encuentra en el /etc/ or /etc/mysql/ Directorio. Debe abrirlo y realizar los siguientes cambios:

[mysqld]
# Location of the file for recording slow queries. Be sure to replace it with your path
log-slow-queries = /var/log/mariadb/slow_queries.log

# Threshold time for considering slow queries (in seconds)
long_query_time = 5

# Enabling recording of queries that do not use indexes
log-queries-not-using-indexes = 1

# Disabling query caching
query_cache_size = 0
query_cache_type = 0
query_cache_limit = 1M

# Size of temporary tables
tmp_table_size = 16M
max_heap_table_size = 16M

# Size of the thread cache
thread_cache_size = 16

# Disabling name resolving
skip-name-resolve = 1

# Size of the InnoDB buffer pool. Set to 50-70% of available RAM
innodb_buffer_pool_size = 800M

# Size of the InnoDB log file
innodb_log_file_size = 200M

Consideremos también recomendaciones adicionales que pueden facilitar la interacción con la base de datos del servidor:

1. Utilice la sección EXPLICAR Comando antes de una consulta SQL para analizar su ejecución. Esto permite obtener un plan de ejecución de la consulta y determinar qué índices se utilizan, qué tablas se escanean, etc.
2. Los índices aceleran la búsqueda de datos, por lo que un diseño adecuado puede mejorar significativamente el rendimiento de las consultas. Preste atención a las columnas que se usan con frecuencia en Dónde or ÚNETE .
3. Evitar el uso de SELECT *. Especifique sólo las columnas que sean realmente necesarias para su consulta, en lugar de seleccionar todas las columnas de una tabla.
4. Evite utilizar funciones en Dónde condiciones. Utilizando funciones (como BAJAR, SUPERIOR, IZQUIERDA, DERECHO) en Dónde Las condiciones pueden inutilizar los índices. Evite su uso directo en condiciones.
5. Use INNER JOIN Siempre que sea posible, ya que suele ser más eficiente. Además, asegúrese de que las columnas correspondientes para la unión tengan índices.
6. Use LIMITE LAS para restringir el número de filas devueltas si necesita obtener solo una cierta cantidad de resultados.
7. Considere almacenar en caché los resultados de las consultas, especialmente si rara vez cambian, para reducir la carga del servidor.

El servidor de correo crea una alta carga en el servidor

En esta sección, exploraremos cómo determinar si el servidor de correo está experimentando una alta carga y qué medidas se pueden tomar para optimizar su funcionamiento, incluyendo la comprobación de la cola de mensajes y la configuración de los parámetros del servidor. Comience por comprobar la cola de mensajes. correo q La utilidad puede ayudar con esto, para activarla, ingrese el comando correspondiente en la terminal:

mailq

Esto mostrará una lista de los mensajes en cola, si los hay. Cada mensaje se mostrará con su identificador único e información sobre el estado de envío. Se puede obtener un resultado similar revisando los registros del cliente de correo.

En la mayoría de los casos, la alta carga se produce cuando el servidor se ve comprometido y comienza a enviar spam. Sin embargo, si tras la comprobación, el administrador está seguro de que el servidor no ha sido atacado desde el exterior y de que los usuarios no están descuidando el spam, es hora de optimizar el servidor de correo. Estos son los pasos que le ayudarán:

1. Asegúrese de que los registros DNS de su dominio estén configurados correctamente, incluidos SPF, DKIM y DMARC Registros para mejorar la entrega de correo y proteger contra el spam. La configuración correcta de los parámetros se puede encontrar en el artículo sobre diagnóstico del servidor de correo.
2. Verifique la configuración de red, incluida la configuración del firewall y las reglas de enrutamiento, para evitar bloqueos y acelerar la entrega de correo.
3. Configure los parámetros de la cola de mensajes según la carga del servidor. Esto puede incluir el tamaño máximo de la cola y los tiempos de espera.
4. Considere las soluciones que analizamos en este artículo. Optimice periódicamente la base de datos del servidor de correo para mejorar el rendimiento y utilice mecanismos de caché para acelerar la búsqueda y el procesamiento de datos, como las consultas DNS.
5. Si el servidor de correo aún enfrenta regularmente una carga alta, considere opciones de escalamiento, como usar un clúster de servidores de correo o soluciones en la nube.

Conclusión

El aumento de la carga del servidor afecta directamente la velocidad de carga del sitio web, lo que a su vez afecta la experiencia del usuario y su reputación en los motores de búsqueda. Por lo tanto, gestionar eficazmente esta carga es fundamental para garantizar la funcionalidad continua del recurso y aumentar su accesibilidad para los visitantes.