Redución da carga do servidor

Neste artigo, analizaremos por que se produce o aumento da carga do servidor e discutiremos varias formas de optimizar os procesos de alta carga. Prestarase especial atención á optimización do código en Apache/Nginx e MySQL, falaremos do caché como ferramenta auxiliar, e tamén consideraremos posibles ameazas externas, como ataques DDOS, e formas de evitalas.

Por que se produce a carga do servidor

Antes de proceder á optimización do servidor, é necesario realizar unha análise exhaustiva da carga actual dos recursos. Isto inclúe medir a carga da CPU, o uso da RAM, a actividade da rede e outros parámetros clave. Comprender a dinámica e os picos de carga permite identificar os pescozos de botella e optimizar a asignación de recursos, aumentando así a estabilidade e o rendemento da infraestrutura do servidor.

Para a resolución inicial de problemas de alta carga do servidor, recomendamos realizar a diagnóstico xeral do servidor. Se isto é insuficiente, un máis detallado análise de recursos é necesario. Como ferramenta auxiliar, explorando o rexistros de Linux servidor pode ser útil, xa que aquí é onde se atopa a orixe do problema na maioría dos casos.

Optimización do servidor Apache/Nginx

Aumento da carga do servidor debido á indexación

O aumento da carga debido á indexación no servidor pode ocorrer, por exemplo, cando os motores de busca escanean un gran número de páxinas do teu sitio. Isto pode levar a un maior uso dos recursos do servidor e, en consecuencia, ralentizar o rendemento do sitio. Identificar a causa é relativamente sinxelo; cómpre abrir o ficheiro situado en:

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

Cando o indexen os buscadores, o usuario verá entradas da seguinte natureza:

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 primeira solución para reducir a carga, pode utilizar a configuración das metaetiquetas "sen índice" "non seguir" en páxinas que non precisan ser indexadas. A segunda solución é a htaccess ficheiro, onde hai que engadir entradas correspondentes a motores de busca específicos, por exemplo, para ocultarse de Yandex e Google:

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

Do mesmo xeito, hai que facer edicións para outros buscadores. Hai que ter en conta que as capacidades de .htaccess non se limitan só a bloquear a indexación. Recomendamos familiarizarse máis coas súas principais características no artigo.

Usando a configuración de caché

A configuración de caché incorrecta no servidor tamén pode provocar unha carga elevada. Para optimizar este parámetro, cómpre facer os cambios correspondentes nos ficheiros de configuración ou htaccess. No caso de Apache, a última opción é preferible, para Nginx, a primeira.

Nunha Apache servidor, debes abrir o .htacess arquivo e insira o seguinte código:

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

A continuación, activa o Caducas módulo usando o comando:

sudo a2enmod expires

Despois diso, reinicie o servidor web:

sudo service apache2 restart

E activa o módulo especificando:

ExpiresActive On

Nun Nginx servidor, é suficiente engadir o seguinte código ao ficheiro de configuración:

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

E realiza unha recarga do servizo:

sudo service nginx restart

Teña en conta que con esta configuración, o Permitir Negar as directivas serán ignoradas.

Usando compresión de datos

Activando a compresión de datos usando Gzip nos servidores web Apache e Nginx axuda a reducir a cantidade de datos transmitidos entre o servidor e o cliente, o que mellora o rendemento e reduce o tempo de carga da páxina web.

Para habilitar Gzip on Apache, debes activar o mod_deflate módulo:

sudo a2enmod deflate

A continuación, reinicie o servidor web:

sudo service apache2 restart

E, finalmente, engade o seguinte bloque ao ficheiro de configuración ou .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 permite a compresión para certos tipos de ficheiros e desactívaa para as imaxes.

No caso de que Nginx, a configuración ocorre en http bloque do ficheiro de configuración. É necesario engadir o seguinte 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;

Semellante a Apache, aquí establécense os parámetros de compresión para certos tipos de ficheiros. Despois de facer cambios nalgún dos servidores web, é necesaria unha recarga do servizo:

sudo service apache2 restart

Or

sudo service nginx restart

Ataque DDOS ao servidor

A alta carga do servidor pode ocorrer como resultado dun ataque DDoS. A identificación da presenza dun ataque DDoS pódese facer mediante o seguimento dun aumento repentino de tráfico, solicitudes anormais e caídas de rendemento do servidor. A revisión dos rexistros de solicitudes repetidas desde un enderezo IP ou a exploración de portos tamén pode indicar un posible ataque DDoS. Hai moitas medidas de protección, pero só comentaremos as bases.

Usando unha CDN (Rede de entrega de contido). Un CDN pode servir de intermediario entre o teu servidor web e os usuarios, distribuíndo tráfico e almacenando en caché o contido para mitigar o impacto dun ataque DDoS. As CDN tamén poden ter mecanismos de protección DDoS integrados, incluíndo a distribución de carga e o filtrado de tráfico.

Configuración de firewalls e sistemas de detección de intrusos (IDS/IPS). Os cortalumes pódense configurar para filtrar o tráfico en función de varios criterios, como enderezos IP e portos. IDS/IPS pode detectar comportamentos anormais do tráfico e bloquear conexións sospeitosas. Estas ferramentas poden ser eficaces para rastrexar e bloquear o tráfico potencialmente malicioso.

Configurando servidores web Apache e Nginx para mitigar o impacto dos ataques DDoS.

Como solución para Apache, activamos o mod_evasivo módulo. Para iso, quite o comentario ou engada a seguinte liña no ficheiro httpd.conf or apache2.conf ficheiro de configuración:

LoadModule evasive20_module modules/mod_evasive.so

No mesmo ficheiro, cómpre engadir 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>

Do mesmo xeito, activamos o mod_ratelimit módulo:

LoadModule ratelimit_module modules/mod_ratelimit.so

E engade a 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>

A configuración para Nginx é semellante Apache. no nginx.conf ficheiro de configuración, hai que utilizar as seguintes 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;

        ...
    }
}

Despois de facer cambios en cada un dos servizos, hai que volver cargalos:

sudo systemctl restart apache2

Ou:

sudo systemctl restart nginx

Estes exemplos proporcionan só unha configuración básica, que se pode adaptar aínda máis dependendo dos requisitos específicos e da natureza dos ataques.

Optimización de consultas MySQL

A optimización das consultas de bases de datos MySQL nun servidor web pódese conseguir de varias maneiras, e unha delas é a correcta configuración do ficheiro de configuración. Normalmente, este ficheiro recibe un nome meu.cnf or meu.ini e está situado no / etc / or /etc/mysql/ directorio. Debe abrilo e facer os seguintes 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 tamén recomendacións adicionais que poden facilitar a interacción coa base de datos do servidor:

1. Utilizar a EXPLICAR comando antes dunha consulta SQL para analizar a súa execución. Isto permítelle obter un plan de execución para a consulta e determinar que índices se utilizan, que táboas se analizan, etc.
2. Os índices aceleran a busca de datos, polo que os índices deseñados correctamente poden mellorar significativamente o rendemento das consultas. Preste atención ás columnas que se usan con frecuencia ONDE or Rexístrese se condicións.
3. Evite usar SELECCIONAR *. Especifique só as columnas que sexan realmente necesarias para a súa consulta, en lugar de seleccionar todas as columnas dunha táboa.
4. Evite usar funcións en ONDE condicións. Usando funcións (como BAIXO, SUPERIOR, Esquerda, DEREITO) en ONDE as condicións poden facer que os índices sexan inútiles. Intente evitar o seu uso directo en condicións.
5. Usar ENTRADA INTERIOR sempre que sexa posible, xa que adoita ser máis eficiente. Ademais, asegúrese de que as columnas correspondentes para unir teñan índices.
6. Usar LÍMITE para restrinxir o número de filas devoltas se precisa obter só un determinado número de resultados.
7. Considere almacenar na caché os resultados das consultas, especialmente se raramente cambian, para reducir a carga do servidor.

O servidor de correo crea alta carga no servidor

Nesta sección, exploraremos como determinar se o servidor de correo está experimentando unha carga elevada e que pasos se poden tomar para optimizar o seu funcionamento, incluíndo a comprobación da cola de mensaxes e a configuración dos parámetros do servidor. Comeza comprobando a cola de mensaxes. O mailq A utilidade pode axudar con isto, para activalo, introduza o comando correspondente no terminal:

mailq

Isto amosará unha lista de mensaxes na cola, se as hai. Cada mensaxe mostrarase co seu identificador único e información sobre o estado de envío. Pódese obter un resultado semellante revisando os rexistros do cliente de correo.

Na maioría dos casos, a alta carga prodúcese no caso de comprometer o servidor cando comeza a enviar correo lixo. Non obstante, se despois de comprobar o administrador confía en que o servidor non foi atacado desde fóra e os usuarios non descoidan o spam, é hora de pasar á optimización do servidor de correo. Estes son os pasos que axudarán:

1. Asegúrate de que os rexistros DNS do teu dominio estean configurados correctamente, incluíndo SPF, DKIMe DMARC rexistros para mellorar a entrega de correo e protexerse contra o spam. A configuración correcta dos parámetros pódese atopar no artigo sobre diagnóstico do servidor de correo.
2. Comprobe a configuración da rede, incluída a configuración do firewall e as regras de enrutamento, para evitar bloqueos e acelerar a entrega de correo.
3. Configure os parámetros da cola de mensaxes segundo a carga do servidor. Isto pode incluír establecer o tamaño máximo da cola e os tempos de espera.
4. Considere as solucións que comentamos anteriormente neste artigo. Optimice periodicamente a base de datos do servidor de correo para mellorar o rendemento, use mecanismos de caché para acelerar a busca e procesamento de datos, como consultas DNS.
5. Se o servidor de correo aínda ten unha carga elevada con regularidade, considere opcións de escalado, como usar un clúster de servidores de correo ou solucións na nube.

Conclusión

O aumento da carga do servidor afecta directamente á velocidade de carga do sitio web, afectando finalmente a experiencia do usuario e a reputación nos motores de busca. Así, a xestión eficaz desta carga xoga un papel fundamental para garantir a funcionalidade continua do recurso e aumentar a súa accesibilidade para os visitantes.