Reducerea încărcării serverului

În acest articol, vom aprofunda de ce are loc o încărcare crescută a serverului și vom discuta despre diferite modalități de optimizare a proceselor cu sarcină mare. O atenție deosebită va fi acordată optimizării codului în Apache/Nginx și MySQL, vom vorbi despre caching ca instrument auxiliar și vom lua în considerare, de asemenea, posibile amenințări externe, cum ar fi atacurile DDOS și modalități de a le preveni.

De ce are loc încărcarea serverului

Înainte de a trece la optimizarea serverului, este necesar să se efectueze o analiză amănunțită a încărcării curente a resurselor. Aceasta include măsurarea încărcării procesorului, a utilizării RAM, a activității în rețea și a altor parametri cheie. Înțelegerea dinamicii și a sarcinilor de vârf permite identificarea blocajelor și optimizarea alocării resurselor, crescând astfel stabilitatea și performanța infrastructurii serverului.

Pentru depanarea inițială a problemelor legate de încărcarea excesivă a serverului, vă recomandăm să efectuați o diagnosticare generală a serverului . Dacă aceasta este insuficientă, este necesară o analiză mai detaliată a resurselor . Ca instrument auxiliar, explorarea jurnalelor serverului Linux poate fi utilă, deoarece aici se găsește sursa problemei în majoritatea cazurilor.

Optimizarea serverului Apache/Nginx

Încărcare crescută a serverului datorită indexării

O sarcină crescută din cauza indexării pe server poate apărea, de exemplu, atunci când motoarele de căutare scanează un număr mare de pagini de pe site-ul dvs. Acest lucru poate duce la o utilizare sporită a resurselor serverului și, în consecință, la încetinirea performanței site-ului. Identificarea cauzei este relativ simplă; trebuie să deschideți fișierul aflat la:

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

Când este indexat de motoarele de căutare, utilizatorul va vedea intrări de următoarea natură:

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

Ca primă soluție pentru reducerea încărcării, puteți utiliza setarea metaetichetelor „noindex” și „nofollow” pe paginile care nu necesită indexare. A doua soluție este fișierul .htaccess , unde trebuie adăugate intrări corespunzătoare anumitor motoare de căutare, de exemplu, pentru a le ascunde 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

În mod similar, trebuie făcute modificări și pentru alte motoare de căutare. Trebuie menționat că capabilitățile fișierului .htaccess nu se limitează doar la blocarea indexării. Vă recomandăm să vă familiarizați mai bine cu principalele sale caracteristici în articol.

Utilizarea setărilor de cache

Setările incorecte de cache pe server pot duce, de asemenea, la o încărcare mare. Pentru a optimiza acest parametru, trebuie făcute modificări corespunzătoare în fișierele de configurare sau în .htaccess . În cazul Apache, ultima opțiune este preferabilă, iar pentru Nginx – prima.

Pe un server Apache , trebuie să deschideți fișierul .htacess și să introduceți următorul cod:

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

Apoi, activați modulul Expires folosind comanda:

sudo a2enmod expires

După care, reporniți serverul web:

sudo service apache2 restart

Și activați modulul specificând:

ExpiresActive On

Pe un server Nginx , este suficient să adăugați următorul cod în fișierul de configurare:

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

Și efectuați o reîncărcare a serviciului:

sudo service nginx restart

Rețineți că, cu aceste setări, directivele Allow și Deny vor fi ocolite.

Utilizarea compresiei datelor

Activarea compresiei datelor folosind Gzip pe serverele web Apache și Nginx ajută la reducerea cantității de date transmise între server și client, ceea ce îmbunătățește performanța și reduce timpul de încărcare a paginilor web.

Pentru a activa Gzip pe Apache , trebuie să activați modulul mod_deflate :

sudo a2enmod deflate

Apoi, reporniți serverul web:

sudo service apache2 restart

Și, în final, adăugați următorul bloc la fișierul de configurare sau .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>

Această configurație permite compresia pentru anumite tipuri de fișiere și o dezactivează pentru imagini.

În cazul Nginx , configurarea are loc în blocul http al fișierului de configurare. Trebuie adăugat următorul cod:

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 cu Apache , aici sunt setați parametrii de compresie pentru anumite tipuri de fișiere. După efectuarea modificărilor la oricare dintre serverele web, este necesară o reîncărcare a serviciului:

sudo service apache2 restart

Or

sudo service nginx restart

Atacul DDOS asupra serverului

Încărcarea mare a serverului poate apărea ca urmare a unui atac DDoS. Identificarea prezenței unui atac DDoS se poate face prin monitorizarea unei creșteri bruște a traficului, a solicitărilor anormale și a scăderilor de performanță a serverului. Examinarea jurnalelor pentru solicitări repetate de la o adresă IP sau scanarea portului poate indica, de asemenea, un posibil atac DDoS. Există multe măsuri de protecție, dar vom discuta doar elementele de bază.

Utilizarea unei CDN (Content Delivery Network - Rețea de livrare a conținutului) . O CDN poate servi ca intermediar între serverul web și utilizatori, distribuind traficul și memorând în cache conținutul pentru a atenua impactul unui atac DDoS. CDN-urile pot avea, de asemenea, mecanisme de protecție DDoS încorporate, inclusiv distribuția încărcării și filtrarea traficului.

Configurarea firewall-urilor și a sistemelor de detectare a intruziunilor (IDS/IPS) . Firewall-urile pot fi configurate pentru a filtra traficul pe baza diverselor criterii, cum ar fi adresele IP și porturile. IDS/IPS pot detecta comportamentul anormal al traficului și pot bloca conexiunile suspecte. Aceste instrumente pot fi eficiente în urmărirea și blocarea traficului potențial rău intenționat.

Configurarea serverelor web Apache și Nginx pentru a atenua impactul atacurilor DDoS.

Ca soluție pentru Apache, activăm modulul mod_evasive . Pentru a face acest lucru, decomentați sau adăugați următoarea linie în fișierul de configurare httpd.conf sau apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

În același fișier, trebuie să adăugați un bloc de setări:

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

În mod similar, activăm modulul mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

Și adăugați configurația:

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

Configurația pentru Nginx este similară cu cea pentru Apache . În fișierul de configurare nginx.conf , trebuie utilizate următoarele directive:

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;

        ...
    }
}

După efectuarea modificărilor la fiecare dintre servicii, acestea trebuie să fie reîncărcate:

sudo systemctl restart apache2

Sau:

sudo systemctl restart nginx

Aceste exemple oferă doar o configurație de bază, care poate fi adaptată în continuare în funcție de cerințele specifice și de natura atacurilor.

Optimizarea interogărilor MySQL

Optimizarea interogărilor bazei de date MySQL pe un server web se poate realiza în diverse moduri, iar unul dintre acestea este configurarea corectă a fișierului de configurare. De obicei, acest fișier se numește my.cnf sau my.ini și se află în directorul /etc/ sau /etc/mysql/ . Trebuie să îl deschideți și să faceți următoarele modificări:

[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

Să luăm în considerare și recomandări suplimentare care pot facilita interacțiunea cu baza de date a serverului:

1. Folosește EXPLICAȚI comandă înainte de o interogare SQL pentru a analiza execuția acesteia. Acest lucru vă permite să obțineți un plan de execuție pentru interogare și să determinați ce indici sunt utilizați, ce tabele sunt scanate etc.
2. Indecșii accelerează căutarea datelor, astfel încât indecșii proiectați corespunzător pot îmbunătăți semnificativ performanța interogărilor. Acordați atenție coloanelor care sunt utilizate frecvent în UNDE or JOIN condiții.
3. Evita sa folosesti SELECTAȚI *. Specificați numai acele coloane care sunt cu adevărat necesare pentru interogarea dvs., în loc să selectați toate coloanele dintr-un tabel.
4. Evitați utilizarea funcțiilor în UNDE conditii. Utilizarea funcțiilor (cum ar fi INFERIOR, SUPERIOR, LEFT, DREAPTA) în UNDE condițiile pot face indicii inutili. Încercați să evitați utilizarea lor directă în condiții.
5. Utilizare INNER JOIN acolo unde este posibil, deoarece este de obicei mai eficient. De asemenea, asigurați-vă că coloanele corespunzătoare pentru unire au indici.
6. Utilizare LIMITĂ pentru a restricționa numărul de rânduri returnate dacă trebuie să obțineți doar un anumit număr de rezultate.
7. Luați în considerare stocarea în cache a rezultatelor interogărilor, mai ales dacă acestea se modifică rar, pentru a reduce încărcarea serverului.

Serverul de e-mail creează încărcare mare pe server

În această secțiune, vom explora cum să determinăm dacă serverul de mail se confruntă cu o sarcină mare și ce pași pot fi luați pentru a optimiza funcționarea acestuia, inclusiv verificarea cozii de mesaje și configurarea parametrilor serverului. Începeți prin verificarea cozii de mesaje. Utilitarul mailq vă poate ajuta în acest sens, pentru a-l activa, introduceți comanda corespunzătoare în terminal:

mailq

Aceasta va afișa o listă de mesaje în coadă, dacă există. Fiecare mesaj va fi afișat cu identificatorul său unic și informații despre starea expedierii. Un rezultat similar poate fi obținut prin examinarea jurnalelor clientului de e-mail.

În cele mai multe cazuri, sarcina mare apare în cazul compromiterii serverului atunci când începe să trimită spam. Totuși, dacă după verificare, administratorul are încredere că serverul nu a fost atacat din exterior și utilizatorii nu neglijează spam-ul, este timpul să trecem la optimizarea serverului de mail. Iată pașii care vă vor ajuta:

1. Asigurați-vă că înregistrările DNS ale domeniului dvs. sunt configurate corect, inclusiv SPF, extensia dkim și DMARC înregistrări pentru a îmbunătăți livrarea e-mailurilor și a proteja împotriva spamului. Configurarea corectă a parametrilor poate fi găsită în articolul despre diagnosticare server de mail.
2. Verificați setările rețelei, inclusiv configurația firewall-ului și regulile de rutare, pentru a evita blocările și pentru a accelera livrarea e-mailurilor.
3. Configurați parametrii cozii de mesaje în funcție de încărcarea serverului. Aceasta poate include setarea dimensiunii maxime a cozii de aşteptare şi a timeout-urilor.
4. Luați în considerare soluțiile pe care le-am discutat mai devreme în acest articol. Optimizați periodic baza de date a serverului de e-mail pentru a îmbunătăți performanța, utilizați mecanisme de stocare în cache pentru a accelera căutarea și procesarea datelor, cum ar fi interogările DNS.
5. Dacă serverul de e-mail întâmpină în mod regulat încărcare mare, luați în considerare opțiunile de scalare, cum ar fi utilizarea unui cluster de servere de e-mail sau soluții cloud.

Concluzie

Încărcarea crescută a serverului afectează direct viteza de încărcare a site-ului web, influențând în cele din urmă experiența utilizatorului și reputația în motoarele de căutare. Astfel, gestionarea eficientă a acestei sarcini joacă un rol cheie în asigurarea funcționalității continue a resursei și creșterea accesibilității acesteia pentru vizitatori.