Reducció de la càrrega del servidor

En aquest article, aprofundirem en per què es produeix un augment de la càrrega del servidor i discutirem diverses maneres d'optimitzar els processos d'alta càrrega. Es prestarà especial atenció a l'optimització de codi en Apache/Nginx i MySQL, parlarem de la memòria cau com a eina auxiliar, i també considerarem possibles amenaces externes, com atacs DDOS, i maneres de prevenir-les.

Per què es produeix la càrrega del servidor

Abans de procedir a l'optimització del servidor, cal realitzar una anàlisi exhaustiva de la càrrega actual dels recursos. Això inclou mesurar la càrrega de la CPU, l'ús de la memòria RAM, l'activitat de la xarxa i altres paràmetres clau. Entendre la dinàmica i les càrregues màximes permet identificar colls d'ampolla i optimitzar l'assignació de recursos, augmentant així l'estabilitat i el rendiment de la infraestructura del servidor.

Per a la resolució inicial de problemes d'alta càrrega del servidor, recomanem dur a terme un diagnòstic general del servidor . Si això no és suficient, cal una anàlisi més detallada dels recursos . Com a eina auxiliar, pot ser útil explorar els registres del servidor Linux, ja que és on es troba l'origen del problema en la majoria dels casos.

Optimització del servidor Apache/Nginx

Augment de la càrrega del servidor a causa de la indexació

Es pot produir un augment de la càrrega a causa de la indexació al servidor, per exemple, quan els motors de cerca escanegen un gran nombre de pàgines del vostre lloc. Això pot provocar un major ús dels recursos del servidor i, en conseqüència, alentir el rendiment del lloc. Identificar la causa és relativament senzill; heu d'obrir el fitxer que es troba a:

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

Quan sigui indexat pels motors de cerca, l'usuari veurà entrades de la següent naturalesa:

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)"

Com a primera solució per reduir la càrrega, podeu utilitzar la configuració de les metaetiquetes "noindex" i "nofollow" a les pàgines que no cal indexar. La segona solució és el fitxer .htaccess , on cal afegir entrades corresponents a motors de cerca específics, per exemple, per ocultar-les de Yandex i 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 la mateixa manera, cal fer edicions per a altres motors de cerca. Cal tenir en compte que les capacitats de .htaccess no es limiten només a bloquejar la indexació. Us recomanem que us familiaritzeu amb les seves principals característiques a l' article.

Ús de la configuració de la memòria cau

Una configuració incorrecta de la memòria cau al servidor també pot provocar una càrrega elevada. Per optimitzar aquest paràmetre, cal fer els canvis corresponents als fitxers de configuració o a .htaccess . En el cas d'Apache, és preferible la darrera opció, i per a Nginx, la primera.

En un servidor Apache , cal obrir el fitxer .htacess i inserir el codi següent:

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

A continuació, activeu el mòdul Expires amb l'ordre:

sudo a2enmod expires

Després d'això, reinicieu el servidor web:

sudo service apache2 restart

I activeu el mòdul especificant:

ExpiresActive On

En un servidor Nginx , n'hi ha prou amb afegir el següent codi al fitxer de configuració:

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

I realitzeu una recàrrega de servei:

sudo service nginx restart

Tingueu en compte que amb aquesta configuració, les directives Allow i Deny s'ometran.

Ús de la compressió de dades

Habilitar la compressió de dades mitjançant Gzip als servidors web Apache i Nginx ajuda a reduir la quantitat de dades transmeses entre el servidor i el client, cosa que millora el rendiment i redueix el temps de càrrega de la pàgina web.

Per habilitar Gzip a Apache , cal activar el mòdul mod_deflate :

sudo a2enmod deflate

A continuació, reinicieu el servidor web:

sudo service apache2 restart

I, finalment, afegiu el bloc següent al fitxer de configuració 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>

Aquesta configuració permet la compressió per a determinats tipus de fitxers i la desactiva per a les imatges.

En el cas de Nginx , la configuració es produeix al bloc http del fitxer de configuració. Cal afegir el codi següent:

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;

De manera similar a Apache , aquí es defineixen els paràmetres de compressió per a certs tipus de fitxers. Després de fer canvis a qualsevol dels servidors web, cal tornar a carregar el servei:

sudo service apache2 restart

Or

sudo service nginx restart

Atac DDOS al servidor

Es pot produir una càrrega elevada del servidor com a resultat d'un atac DDoS. La identificació de la presència d'un atac DDoS es pot fer mitjançant el seguiment d'un augment sobtat del trànsit, sol·licituds anormals i caigudes de rendiment del servidor. La revisió dels registres de sol·licituds repetides d'una adreça IP o d'una exploració de ports també pot indicar un possible atac DDoS. Hi ha moltes mesures de protecció, però només parlarem de les bases.

Ús d'una CDN (Xarxa de Distribució de Contingut) . Una CDN pot servir com a intermediari entre el servidor web i els usuaris, distribuint el trànsit i emmagatzemant el contingut a la memòria cau per mitigar l'impacte d'un atac DDoS. Les CDN també poden tenir mecanismes de protecció DDoS integrats, com ara la distribució de la càrrega i el filtratge del trànsit.

Configuració de tallafocs i sistemes de detecció d'intrusions (IDS/IPS) . Els tallafocs es poden configurar per filtrar el trànsit en funció de diversos criteris, com ara adreces IP i ports. Els IDS/IPS poden detectar un comportament anormal del trànsit i bloquejar connexions sospitoses. Aquestes eines poden ser efectives per rastrejar i bloquejar trànsit potencialment maliciós.

Configuració dels servidors web Apache i Nginx per mitigar l'impacte dels atacs DDoS.

Com a solució per a Apache, activem el mòdul mod_evasive . Per fer-ho, elimineu el comentari o afegiu la línia següent al fitxer de configuració httpd.conf o apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

Al mateix fitxer, heu d'afegir un bloc de configuració:

<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 la mateixa manera, activem el mòdul mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

I afegiu la configuració:

<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ó per a Nginx és similar a la d'Apache . Al fitxer de configuració nginx.conf , cal utilitzar les directives següents:

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;

        ...
    }
}

Després de fer canvis a cadascun dels serveis, s'han de tornar a carregar:

sudo systemctl restart apache2

O bé:

sudo systemctl restart nginx

Aquests exemples proporcionen només una configuració bàsica, que es pot adaptar encara més en funció dels requisits específics i de la naturalesa dels atacs.

Optimització de consultes MySQL

L'optimització de les consultes de bases de dades MySQL en un servidor web es pot aconseguir de diverses maneres, i una d'elles és la configuració adequada del fitxer de configuració. Normalment, aquest fitxer s'anomena my.cnf o my.ini i es troba al directori /etc/ o /etc/mysql/ . Cal obrir-lo i fer els canvis següents:

[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

Considerem també recomanacions addicionals que poden facilitar la interacció amb la base de dades del servidor:

1. Feu servir l' EXPLICA comanda abans d'una consulta SQL per analitzar-ne l'execució. Això us permet obtenir un pla d'execució de la consulta i determinar quins índexs s'utilitzen, quines taules s'escanegen, etc.
2. Els índexs acceleren la cerca de dades, de manera que els índexs dissenyats correctament poden millorar significativament el rendiment de les consultes. Preste atenció a les columnes que s'utilitzen amb freqüència WHERE or JOIN condicions.
3. Evitar l'ús SELECCIONA *. Especifiqueu només les columnes que són realment necessàries per a la vostra consulta, en lloc de seleccionar totes les columnes d'una taula.
4. Eviteu utilitzar funcions a WHERE condicions. Ús de funcions (com ara MÉS BAIX, SUPERIOR, LEFT, DRET) in WHERE condicions poden fer inútils els índexs. Intenta evitar el seu ús directe en condicions.
5. Ús COMBINACIÓ INTERNA sempre que sigui possible, ja que normalment és més eficient. A més, assegureu-vos que les columnes corresponents per a la unió tinguin índexs.
6. Ús LIMIT per restringir el nombre de files retornades si només cal obtenir un nombre determinat de resultats.
7. Penseu en l'emmagatzematge en memòria cau dels resultats de les consultes, especialment si no canvien poques vegades, per reduir la càrrega del servidor.

El servidor de correu crea una càrrega elevada al servidor

En aquesta secció, explorarem com determinar que el servidor de correu està experimentant una càrrega elevada i quins passos es poden prendre per optimitzar-ne el funcionament, incloent-hi la comprovació de la cua de missatges i la configuració dels paràmetres del servidor. Comenceu per comprovar la cua de missatges. La utilitat mailq us pot ajudar amb això, per activar-la, introduïu l'ordre corresponent al terminal:

mailq

Això mostrarà una llista de missatges a la cua, si n'hi ha. Cada missatge es mostrarà amb el seu identificador únic i informació sobre l'estat d'enviament. Es pot obtenir un resultat similar revisant els registres del client de correu.

En la majoria dels casos, es produeix una càrrega elevada en cas de compromís del servidor quan comença a enviar correu brossa. Tanmateix, si després de comprovar l'administrador confia que el servidor no ha estat atacat des de l'exterior i els usuaris no descuiden el correu brossa, és hora de passar a l'optimització del servidor de correu. Aquests són els passos que us ajudaran:

1. Assegureu-vos que els registres DNS del vostre domini estiguin configurats correctament, inclòs SPF, extensió dkimi Extensió DMARC registres per millorar el lliurament del correu i protegir-se del correu brossa. La configuració correcta dels paràmetres es pot trobar a l'article sobre diagnòstic del servidor de correu.
2. Comproveu la configuració de la xarxa, inclosa la configuració del tallafoc i les regles d'encaminament, per evitar bloquejos i accelerar el lliurament del correu.
3. Configureu els paràmetres de la cua de missatges segons la càrrega del servidor. Això pot incloure establir la mida màxima de la cua i els temps d'espera.
4. Considereu les solucions que hem comentat anteriorment en aquest article. Optimitzeu periòdicament la base de dades del servidor de correu per millorar el rendiment, utilitzeu mecanismes de memòria cau per accelerar la cerca i el processament de dades, com ara consultes DNS.
5. Si el servidor de correu encara té una càrrega elevada regularment, considereu opcions d'escalat, com ara utilitzar un clúster de servidors de correu o solucions al núvol.

Conclusió

L'augment de la càrrega del servidor afecta directament la velocitat de càrrega del lloc web i, finalment, afecta l'experiència de l'usuari i la reputació als motors de cerca. Així, la gestió eficaç d'aquesta càrrega juga un paper clau per garantir la funcionalitat contínua del recurs i augmentar la seva accessibilitat per als visitants.