Reduktion af serverbelastning

I denne artikel vil vi dykke ned i, hvorfor øget serverbelastning opstår, og diskutere forskellige måder at optimere højbelastningsprocesser på. Særlig opmærksomhed vil blive givet til kodeoptimering i Apache/Nginx og MySQL, vi vil tale om caching som et hjælpeværktøj og også overveje mulige eksterne trusler, såsom DDOS-angreb, og måder at forhindre dem på.

Hvorfor serverbelastning opstår

Før du går videre til serveroptimering, er det nødvendigt at foretage en grundig analyse af den aktuelle belastning af ressourcer. Dette inkluderer måling af CPU-belastning, RAM-brug, netværksaktivitet og andre nøgleparametre. Forståelse af dynamikken og spidsbelastningerne gør det muligt at identificere flaskehalse og optimere ressourceallokeringen, hvilket øger stabiliteten og ydeevnen af ​​serverinfrastrukturen.

Til indledende fejlfinding af høj serverbelastning anbefaler vi at udføre en generel serverdiagnostik . Hvis dette ikke er tilstrækkeligt, er en mere detaljeret analyse af ressourcerne nødvendig. Som et hjælpeværktøj kan det være nyttigt at undersøge Linux- serverens logfiler, da det i de fleste tilfælde er her, problemets kilde findes.

Optimering af Apache/Nginx-server

Øget serverbelastning på grund af indeksering

Øget belastning på grund af indeksering på serveren kan for eksempel forekomme, når søgemaskiner scanner et stort antal sider på dit websted. Dette kan føre til øget brug af serverressourcer og følgelig sænke webstedets ydeevne. At identificere årsagen er relativt enkel; du skal åbne filen på:

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

Når den er indekseret af søgemaskiner, vil brugeren se poster af følgende karakter:

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

Som en første løsning til at reducere belastningen kan du bruge indstillingen af ​​metatags "noindex" og "nofollow" på sider, der ikke behøver at blive indekseret. Den anden løsning er .htaccess- filen, hvor poster svarende til specifikke søgemaskiner skal tilføjes, for eksempel for at skjule sig fra Yandex og Google:

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

Ligeledes skal der foretages ændringer for andre søgemaskiner. Det skal bemærkes, at .htaccess' funktioner ikke er begrænset til blot at blokere indeksering. Vi anbefaler, at du bliver mere bekendt med dens vigtigste funktioner i artiklen.

Brug af cacheindstillinger

Forkerte caching-indstillinger på serveren kan også føre til høj belastning. For at optimere denne parameter skal der foretages tilsvarende ændringer i konfigurationsfilerne eller .htaccess . I tilfælde af Apache er sidstnævnte mulighed at foretrække, for Nginx er førstnævnte.

På en Apache- server skal du åbne .htacess -filen og indsætte følgende kode:

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

Aktivér derefter Expires- modulet ved hjælp af kommandoen:

sudo a2enmod expires

Genstart derefter webserveren:

sudo service apache2 restart

Og aktiver modulet ved at specificere:

ExpiresActive On

På en Nginx- server er det tilstrækkeligt at tilføje følgende kode til konfigurationsfilen:

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

Og udfør en servicegenindlæsning:

sudo service nginx restart

Bemærk, at med disse indstillinger vil Tillad- og Afvis -direktiverne blive omgået.

Brug af datakomprimering

Aktivering af datakomprimering ved hjælp af Gzip på Apache- og Nginx-webservere hjælper med at reducere mængden af ​​data, der overføres mellem serveren og klienten, hvilket forbedrer ydeevnen og reducerer indlæsningstiden for websider.

For at aktivere Gzip på Apache skal du aktivere mod_deflate- modulet:

sudo a2enmod deflate

Genstart derefter webserveren:

sudo service apache2 restart

Og til sidst skal du tilføje følgende blok til konfigurationsfilen eller .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>

Denne konfiguration muliggør komprimering for visse typer filer og deaktiverer den for billeder.

I tilfælde af Nginx sker konfigurationen i http- blokken i konfigurationsfilen. Følgende kode skal tilføjes:

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;

Ligesom Apache indstilles komprimeringsparametrene for bestemte filtyper her. Efter ændringer på en af ​​webserverne kræves en genindlæsning af tjenesten:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS-angreb på serveren

Høj serverbelastning kan opstå som følge af et DDoS-angreb. Identifikation af tilstedeværelsen af ​​et DDoS-angreb kan gøres ved at overvåge en pludselig stigning i trafik, unormale anmodninger og serverydeevnefald. Gennemgang af logfiler for gentagne anmodninger fra én IP-adresse eller portscanning kan også indikere et muligt DDoS-angreb. Der er mange beskyttelsesforanstaltninger, men vi vil kun diskutere det grundlæggende.

Brug af et CDN (Content Delivery Network) . Et CDN kan fungere som mellemled mellem din webserver og brugere, distribuere trafik og cache indhold for at afbøde virkningen af ​​et DDoS-angreb. CDN'er kan også have indbyggede DDoS-beskyttelsesmekanismer, herunder belastningsfordeling og trafikfiltrering.

Konfiguration af firewalls og indtrængningsdetekteringssystemer (IDS/IPS) . Firewalls kan konfigureres til at filtrere trafik baseret på forskellige kriterier, såsom IP-adresser og porte. IDS/IPS kan registrere unormal trafikadfærd og blokere mistænkelige forbindelser. Disse værktøjer kan være effektive til at spore og blokere potentielt ondsindet trafik.

Konfiguration af Apache- og Nginx-webservere for at afbøde virkningen af ​​DDoS-angreb.

Som en løsning for Apache aktiverer vi mod_evasive- modulet. For at gøre dette skal du fjerne kommentaren eller tilføje følgende linje i konfigurationsfilen httpd.conf eller apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

I den samme fil skal du tilføje en indstillingsblok:

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

På samme måde aktiverer vi mod_ratelimit- modulet:

LoadModule ratelimit_module modules/mod_ratelimit.so

Og tilføj konfigurationen:

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

Konfigurationen for Nginx ligner Apache . I nginx.conf -konfigurationsfilen skal følgende direktiver anvendes:

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;

        ...
    }
}

Efter at have foretaget ændringer af hver af tjenesterne, skal de genindlæses:

sudo systemctl restart apache2

Eller:

sudo systemctl restart nginx

Disse eksempler giver kun en grundlæggende konfiguration, som kan tilpasses yderligere afhængigt af specifikke krav og arten af ​​angreb.

Optimering af MySQL-forespørgsler

Optimering af MySQL-databaseforespørgsler på en webserver kan opnås på forskellige måder, og en af ​​dem er korrekt konfiguration af konfigurationsfilen. Typisk hedder denne fil my.cnf eller my.ini og er placeret i mappen /etc/ eller /etc/mysql/ . Du skal åbne den og foretage følgende ændringer:

[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

Lad os også overveje yderligere anbefalinger, der kan lette interaktion med serverdatabasen:

1. Brug FORKLAR kommando før en SQL-forespørgsel for at analysere dens udførelse. Dette giver dig mulighed for at få en eksekveringsplan for forespørgslen og bestemme hvilke indekser der bruges, hvilke tabeller der scannes osv.
2. Indekser fremskynder datasøgning, så korrekt designede indekser kan forbedre forespørgselsydeevnen betydeligt. Vær opmærksom på kolonner, der ofte bruges i HVOR or JOIN betingelser.
3. Undgå at bruge VÆLG *. Angiv kun de kolonner, der virkelig er nødvendige for din forespørgsel, i stedet for at vælge alle kolonner i en tabel.
4. Undgå at bruge funktioner i HVOR forhold. Brug af funktioner (som f NEDERSTE, ØVERST, VENSTRE, HØJRE) i HVOR forhold kan gøre indekser ubrugelige. Prøv at undgå deres direkte brug under forhold.
5. Brug INNER JOIN hvor det er muligt, da det normalt er mere effektivt. Sørg også for, at de tilsvarende kolonner til sammenføjning har indekser.
6. Brug GRÆNSE for at begrænse antallet af returnerede rækker, hvis du kun skal have et vist antal resultater.
7. Overvej at cache forespørgselsresultater, især hvis de sjældent ændres, for at reducere serverbelastningen.

Mailserveren skaber høj belastning på serveren

I dette afsnit vil vi undersøge, hvordan man kan fastslå, om mailserveren oplever høj belastning, og hvilke trin der kan tages for at optimere dens drift, herunder kontrol af meddelelseskøen og konfiguration af serverparametre. Start med at kontrollere meddelelseskøen. Mailq - værktøjet kan hjælpe med dette. For at aktivere det skal du indtaste den tilsvarende kommando i terminalen:

mailq

Dette vil vise en liste over meddelelser i køen, hvis nogen. Hver besked vil blive vist med sin unikke identifikator og information om afsendelsesstatus. Et lignende resultat kan opnås ved at gennemgå e-mailklientens logfiler.

I de fleste tilfælde opstår der høj belastning i tilfælde af serverkompromittering, når den begynder at sende spam. Men hvis administratoren efter kontrol er sikker på, at serveren ikke er blevet angrebet udefra, og brugerne ikke forsømmer spam, er det tid til at gå videre til optimering af mailserveren. Her er de trin, der vil hjælpe:

1. Sørg for, at dit domænes DNS-poster er korrekt konfigureret, inklusive SPF, dkim udvidelseog DMARC optegnelser for at forbedre postleveringen og beskytte mod spam. Den korrekte konfiguration af parametre kan findes i artiklen om mail server diagnostik.
2. Tjek netværksindstillinger, herunder firewall-konfiguration og routingregler, for at undgå blokeringer og fremskynde postlevering.
3. Konfigurer beskedkøparametre i henhold til serverbelastning. Dette kan omfatte indstilling af den maksimale køstørrelse og timeouts.
4. Overvej de løsninger, vi diskuterede i denne artikel tidligere. Optimer mailserverdatabasen med jævne mellemrum for at forbedre ydeevnen, brug cachemekanismer til at fremskynde datasøgning og -behandling, såsom DNS-forespørgsler.
5. Hvis mailserveren stadig ofte støder på høj belastning, kan du overveje skaleringsmuligheder, såsom at bruge en klynge af mailservere eller cloud-løsninger.

Konklusion

Øget serverbelastning påvirker direkte hjemmesidens indlæsningshastighed, hvilket i sidste ende påvirker brugeroplevelsen og omdømmet i søgemaskinerne. Effektiv styring af denne belastning spiller således en nøglerolle i at sikre en kontinuerlig funktionalitet af ressourcen og øge dens tilgængelighed for besøgende.