Smanjenje opterećenja poslužitelja

U ovom ćemo članku istražiti zašto dolazi do povećanog opterećenja poslužitelja i raspravljati o različitim načinima optimizacije procesa visokog opterećenja. Posebna pozornost bit će posvećena optimizaciji koda u Apache/Nginx i MySQL, govorit ćemo o cachingu kao pomoćnom alatu, a također ćemo razmotriti moguće vanjske prijetnje, poput DDOS napada, te načine za njihovo sprječavanje.

Zašto dolazi do opterećenja poslužitelja

Prije nego što pristupite optimizaciji poslužitelja, potrebno je provesti temeljitu analizu trenutnog opterećenja resursa. To uključuje mjerenje opterećenja CPU-a, upotrebe RAM-a, mrežne aktivnosti i drugih ključnih parametara. Razumijevanje dinamike i vršnih opterećenja omogućuje prepoznavanje uskih grla i optimiziranje raspodjele resursa, čime se povećava stabilnost i performanse poslužiteljske infrastrukture.

Za početno rješavanje problema visokog opterećenja poslužitelja preporučujemo provođenje opće dijagnostike poslužitelja . Ako to nije dovoljno, potrebna je detaljnija analiza resursa . Kao pomoćni alat, istraživanje logova Linux poslužitelja može biti korisno, jer se tu u većini slučajeva nalazi izvor problema.

Optimiziranje Apache/Nginx poslužitelja

Povećano opterećenje poslužitelja zbog indeksiranja

Do povećanog opterećenja zbog indeksiranja na poslužitelju može doći, na primjer, kada tražilice skeniraju velik broj stranica na vašoj stranici. To može dovesti do povećane upotrebe resursa poslužitelja i, posljedično, usporiti performanse stranice. Identificiranje uzroka je relativno jednostavno; morate otvoriti datoteku koja se nalazi na:

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

Kada ga tražilice indeksiraju, korisnik će vidjeti unose sljedeće prirode:

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

Kao prvo rješenje za smanjenje opterećenja, možete koristiti postavljanje meta oznaka "noindex" i "nofollow" na stranicama koje ne trebaju biti indeksirane. Drugo rješenje je .htaccess datoteka, gdje je potrebno dodati unose koji odgovaraju određenim tražilicama, na primjer, kako bi se sakrili od Yandexa i Googlea:

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

Slično tome, potrebno je napraviti izmjene i za ostale tražilice. Treba napomenuti da mogućnosti .htaccess datoteke nisu ograničene samo na blokiranje indeksiranja. Preporučujemo da se s njezinim glavnim značajkama detaljnije upoznate u članku.

Korištenje postavki predmemoriranja

Netočne postavke predmemorije na poslužitelju također mogu dovesti do velikog opterećenja. Za optimizaciju ovog parametra potrebno je izvršiti odgovarajuće promjene u konfiguracijskim datotekama ili .htaccess . U slučaju Apachea, potonja opcija je poželjnija, za Nginx - prva.

Na Apache poslužitelju morate otvoriti .htacess datoteku i umetnuti sljedeći kod:

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

Zatim omogućite modul Expires pomoću naredbe:

sudo a2enmod expires

Nakon toga ponovno pokrenite web poslužitelj:

sudo service apache2 restart

I aktivirajte modul navođenjem:

ExpiresActive On

Na Nginx serveru dovoljno je dodati sljedeći kod u konfiguracijsku datoteku:

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

I izvršite ponovno učitavanje usluge:

sudo service nginx restart

Imajte na umu da će se s ovim postavkama direktive Allow i Deny zaobići.

Korištenje kompresije podataka

Omogućavanje kompresije podataka pomoću Gzipa na Apache i Nginx web poslužiteljima pomaže u smanjenju količine podataka koji se prenose između poslužitelja i klijenta, što poboljšava performanse i smanjuje vrijeme učitavanja web stranice.

Da biste omogućili Gzip na Apacheu , morate aktivirati modul mod_deflate :

sudo a2enmod deflate

Zatim ponovno pokrenite web poslužitelj:

sudo service apache2 restart

I na kraju, dodajte sljedeći blok u konfiguracijsku datoteku ili .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>

Ova konfiguracija omogućuje kompresiju za određene vrste datoteka i onemogućuje je za slike.

U slučaju Nginxa , konfiguracija se događa u http bloku konfiguracijske datoteke. Potrebno je dodati sljedeći kod:

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;

Slično kao kod Apachea , ovdje se postavljaju parametri kompresije za određene vrste datoteka. Nakon što se izvrše promjene na bilo kojem od web poslužitelja, potrebno je ponovno pokretanje usluge:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS napad na server

Do velikog opterećenja poslužitelja može doći kao rezultat DDoS napada. Identificiranje prisutnosti DDoS napada može se izvršiti praćenjem iznenadnog porasta prometa, abnormalnih zahtjeva i pada performansi poslužitelja. Pregledavanje zapisa za ponovljene zahtjeve s jedne IP adrese ili skeniranje porta također može ukazivati ​​na mogući DDoS napad. Postoje mnoge mjere zaštite, ali mi ćemo govoriti samo o osnovama.

Korištenje CDN-a (mreže za isporuku sadržaja) . CDN može poslužiti kao posrednik između vašeg web poslužitelja i korisnika, distribuirajući promet i pohranjujući sadržaj u predmemoriju kako bi ublažio utjecaj DDoS napada. CDN-ovi također mogu imati ugrađene mehanizme zaštite od DDoS napada, uključujući raspodjelu opterećenja i filtriranje prometa.

Konfiguriranje vatrozida i sustava za otkrivanje upada (IDS/IPS) . Vatrozidovi se mogu konfigurirati za filtriranje prometa na temelju različitih kriterija, kao što su IP adrese i portovi. IDS/IPS može otkriti abnormalno ponašanje prometa i blokirati sumnjive veze. Ovi alati mogu biti učinkoviti u praćenju i blokiranju potencijalno zlonamjernog prometa.

Konfiguriranje Apache i Nginx web poslužitelja za ublažavanje utjecaja DDoS napada.

Kao rješenje za Apache, omogućavamo modul mod_evasive . Da biste to učinili, uklonite komentare ili dodajte sljedeći redak u konfiguracijsku datoteku httpd.conf ili apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

U istoj datoteci morate dodati blok postavki:

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

Slično tome, aktiviramo modul mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

I dodajte konfiguraciju:

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

Konfiguracija za Nginx je slična Apacheu . U konfiguracijskoj datoteci nginx.conf potrebno je koristiti sljedeće direktive:

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;

        ...
    }
}

Nakon što izvršite izmjene na svakoj od usluga, potrebno ih je ponovno učitati:

sudo systemctl restart apache2

Ili:

sudo systemctl restart nginx

Ovi primjeri daju samo osnovnu konfiguraciju, koja se može dodatno prilagoditi ovisno o specifičnim zahtjevima i prirodi napada.

Optimiziranje MySQL upita

Optimizacija upita MySQL bazi podataka na web poslužitelju može se postići na različite načine, a jedan od njih je pravilna konfiguracija konfiguracijske datoteke. Obično se ova datoteka zove my.cnf ili my.ini i nalazi se u direktoriju /etc/ ili /etc/mysql/ . Potrebno je otvoriti je i napraviti sljedeće promjene:

[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

Razmotrimo i dodatne preporuke koje mogu olakšati interakciju s bazom podataka poslužitelja:

1. Koristite OBJASNITI naredbu prije SQL upita za analizu njegovog izvršenja. To vam omogućuje da dobijete plan izvršenja za upit i odredite koji se indeksi koriste, koje se tablice skeniraju itd.
2. Indeksi ubrzavaju pretraživanje podataka, tako da pravilno dizajnirani indeksi mogu značajno poboljšati izvedbu upita. Obratite pozornost na stupce koji se često koriste u GDJE or PRIDRUŽITE uvjeti.
3. Izbjegavajte upotrebu IZABERI *. Navedite samo one stupce koji su uistinu potrebni za vaš upit, umjesto odabira svih stupaca u tablici.
4. Izbjegavajte korištenje funkcija u GDJE uvjetima. Korištenje funkcija (kao što je NIŽI, GORNJI, LIJEVO, PRAVO) u GDJE uvjeti mogu učiniti indekse beskorisnim. Pokušajte izbjeći njihovu izravnu upotrebu u uvjetima.
5. Koristiti INNER JOIN gdje je to moguće, jer je to obično učinkovitije. Također, osigurajte da odgovarajući stupci za spajanje imaju indekse.
6. Koristiti OGRANIČAVA da ograničite broj vraćenih redaka ako trebate dobiti samo određeni broj rezultata.
7. Razmislite o predmemoriranju rezultata upita, posebno ako se rijetko mijenjaju, kako biste smanjili opterećenje poslužitelja.

Poslužitelj pošte stvara veliko opterećenje poslužitelja

U ovom odjeljku istražit ćemo kako utvrditi da li je poslužitelj pošte pod velikim opterećenjem i koje korake možemo poduzeti za optimizaciju njegovog rada, uključujući provjeru reda čekanja poruka i konfiguriranje parametara poslužitelja. Započnite s provjerom reda čekanja poruka. Uslužni program mailq može vam pomoći u tome, da biste ga aktivirali, unesite odgovarajuću naredbu u terminal:

mailq

Ovo će prikazati popis poruka u redu čekanja, ako ih ima. Svaka će poruka biti prikazana sa svojim jedinstvenim identifikatorom i informacijama o statusu slanja. Sličan rezultat može se dobiti pregledom zapisa klijenta pošte.

U većini slučajeva do velikog opterećenja dolazi u slučaju kompromitacije poslužitelja kada počne slati neželjenu poštu. Međutim, ako je nakon provjere administrator uvjeren da poslužitelj nije napadnut izvana i da korisnici ne zanemaruju spam, vrijeme je da prijeđete na optimizaciju poslužitelja e-pošte. Evo koraka koji će vam pomoći:

1. Provjerite jesu li DNS zapisi vaše domene ispravno konfigurirani, uključujući SPF, dkim nastavaki DMARC proširenje zapise za poboljšanje isporuke pošte i zaštitu od neželjene pošte. Ispravnu konfiguraciju parametara možete pronaći u članku o dijagnostika poslužitelja pošte.
2. Provjerite mrežne postavke, uključujući konfiguraciju vatrozida i pravila usmjeravanja, kako biste izbjegli blokade i ubrzali isporuku pošte.
3. Konfigurirajte parametre reda poruka u skladu s opterećenjem poslužitelja. To može uključivati ​​postavljanje maksimalne veličine čekanja i vremenskih ograničenja.
4. Razmotrite rješenja o kojima smo ranije govorili u ovom članku. Povremeno optimizirajte bazu podataka poslužitelja e-pošte kako biste poboljšali performanse, koristite mehanizme predmemorije za ubrzavanje pretraživanja i obrade podataka, kao što su DNS upiti.
5. Ako se poslužitelj e-pošte i dalje redovito susreće s velikim opterećenjem, razmislite o mogućnostima skaliranja, poput upotrebe klastera poslužitelja e-pošte ili rješenja u oblaku.

Zaključak

Povećano opterećenje poslužitelja izravno utječe na brzinu učitavanja web stranice, što u konačnici utječe na korisničko iskustvo i ugled u tražilicama. Stoga učinkovito upravljanje ovim opterećenjem igra ključnu ulogu u osiguravanju kontinuirane funkcionalnosti resursa i povećanju njegove dostupnosti za posjetitelje.