Zerbitzariaren karga murriztea

Artikulu honetan, zerbitzariaren karga handitzea zergatik gertatzen den sakonduko dugu eta karga handiko prozesuak optimizatzeko hainbat modu aztertuko ditugu. Arreta berezia emango zaio Apache/Nginx eta MySQL-en kodeen optimizazioari, tresna laguntzaile gisa caching-ari buruz hitz egingo dugu, eta kanpoko mehatxu posibleak ere kontuan hartuko ditugu, hala nola DDOS erasoak, eta horiek saihesteko moduak.

Zergatik gertatzen da zerbitzariaren karga

Zerbitzariaren optimizazioari ekin aurretik, beharrezkoa da baliabideen egungo kargaren azterketa sakona egitea. Honek PUZaren karga, RAM erabilera, sareko jarduera eta beste funtsezko parametro batzuk neurtzen ditu. Dinamika eta karga gailurrak ulertzeak botila-lepoak identifikatzea eta baliabideen esleipena optimizatzea ahalbidetzen du, horrela zerbitzariaren azpiegituraren egonkortasuna eta errendimendua areagotuz.

Zerbitzariaren karga handiko hasierako arazoak konpontzeko, a egitea gomendatzen dugu zerbitzariaren diagnostiko orokorrak. Hau nahikoa ez bada, zehatzagoa baliabideen azterketa beharrezkoa da. Tresna laguntzaile gisa, arakatuz Linux-en erregistroak zerbitzaria lagungarria izan daiteke, hemen baitago arazoaren iturria kasu gehienetan.

Apache/Nginx zerbitzaria optimizatzen

Zerbitzariaren karga handitu indexatzea dela eta

Zerbitzarian indexatzearen ondoriozko karga handitzea gerta daiteke, adibidez, bilatzaileek zure webguneko orrialde kopuru handia eskaneatzen dutenean. Horrek zerbitzariaren baliabideen erabilera areagotzea ekar dezake eta, ondorioz, gunearen errendimendua moteldu. Kausa identifikatzea nahiko erraza da; helbidean dagoen fitxategia ireki behar duzu:

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

Bilatzaileek indexatzen dutenean, erabiltzaileak izaera hauetako sarrerak ikusiko ditu:

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

Karga murrizteko lehen irtenbide gisa, meta etiketen ezarpena erabil dezakezu "Noindex" "ez jarraitu" indexatu behar ez diren orrialdeetan. Bigarren irtenbidea da . Htaccess fitxategia, non bilatzaile zehatzei dagozkien sarrerak gehitu behar diren, adibidez, Yandex eta Google-tik ezkutatzeko:

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

Era berean, beste bilatzaile batzuen aldaketak egin behar dira. Kontuan izan behar da .htaccess-en gaitasunak ez direla soilik indexatzea blokeatzera mugatzen. Bere ezaugarri nagusiak hobeto ezagutzea gomendatzen dugu article.

Cachearen ezarpenak erabiltzea

Zerbitzariko cachearen ezarpen okerrak karga handia ere ekar dezake. Parametro hau optimizatzeko, dagozkion aldaketak egin behar dira konfigurazio fitxategietan edo . Htaccess. Apache-ren kasuan, bigarren aukera hobe da, Nginx-entzat - lehena.

Bat batean Apache zerbitzaria, ireki behar duzu .htacess fitxategia eta sartu kodea:

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

Ondoren, gaitu Iraungitzen zara modulua komandoa erabiliz:

sudo a2enmod expires

Horren ondoren, berrabiarazi web zerbitzaria:

sudo service apache2 restart

Eta aktibatu modulua zehaztuz:

ExpiresActive On

Batean nginx zerbitzaria, nahikoa da kode hau gehitzea konfigurazio fitxategian:

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

Eta egin zerbitzuaren birkarga:

sudo service nginx restart

Kontuan izan ezarpen hauekin, Baimendu Ukatu zuzentarauak alde batera utziko dira.

Datuen konpresioa erabiliz

Datuen konpresioa erabiliz gzip Apache eta Nginx web zerbitzarietan zerbitzariaren eta bezeroaren artean transmititzen den datu kopurua murrizten laguntzen du, eta horrek errendimendua hobetzen du eta web-orriak kargatzeko denbora murrizten du.

Gaitzeko gzip on Apache, aktibatu behar duzu mod_puztu modulua:

sudo a2enmod deflate

Ondoren, berrabiarazi web zerbitzaria:

sudo service apache2 restart

Eta azkenik, gehitu bloke hau konfigurazio fitxategian edo .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>

Konfigurazio honek fitxategi mota batzuen konpresioa ahalbidetzen du eta irudietarako desgaitzen du.

Kasuan nginx, konfigurazioan gertatzen da http konfigurazio fitxategiaren blokea. Kode hau gehitu behar da:

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;

Antzekoak Apache, hemen fitxategi mota batzuen konpresio-parametroak ezartzen dira. Web zerbitzarietako edozein aldaketa egin ondoren, zerbitzua birkargatu behar da:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS zerbitzariaren erasoa

DDoS eraso baten ondorioz zerbitzariaren karga handia gerta daiteke. DDoS eraso baten presentzia identifikatzea trafikoaren bat-bateko igoeraren, eskaera ezohikoen eta zerbitzariaren errendimenduaren jaitsieraren jarraipenaren bidez egin daiteke. IP helbide edo ataka-eskaeratze errepikatuen erregistroak berrikusteak DDoS eraso posible bat ere adieraz dezake. Babes neurri asko daude, baina oinarriak baino ez ditugu eztabaidatuko.

CDN (Content Delivery Network) bat erabiltzea. CDN batek zure web zerbitzariaren eta erabiltzaileen arteko bitartekari gisa balio dezake, trafikoa banatuz eta edukia cachean gordez DDoS eraso baten eragina arintzeko. CDNek DDoS babeserako mekanismoak ere izan ditzakete, karga banaketa eta trafikoa iragaztea barne.

Suebakiak eta intrusioak detektatzeko sistemak (IDS/IPS) konfiguratzea. Suebakiak konfiguratu daitezke trafikoa iragazteko hainbat irizpideren arabera, hala nola IP helbideak eta atakak. IDS/IPS-k trafikoaren portaera anormal detektatu eta konexio susmagarriak blokeatu ditzake. Tresna hauek eraginkorrak izan daitezke trafiko gaiztoa izan daitekeen jarraipena egiteko eta blokeatzeko.

Apache eta Nginx web zerbitzariak konfiguratzea DDoS erasoen eragina arintzeko.

Apacherako irtenbide gisa, gaitzen dugu mod_ihesbide modulua. Horretarako, kendu iruzkinak edo gehitu hurrengo lerroa httpd.conf or apache2.conf konfigurazio fitxategia:

LoadModule evasive20_module modules/mod_evasive.so

Fitxategi berean, ezarpen bloke bat gehitu behar duzu:

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

Era berean, aktibatzen dugu mod_ratelimit modulua:

LoadModule ratelimit_module modules/mod_ratelimit.so

Eta gehitu konfigurazioa:

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

Konfigurazioa nginx antzekoa da Apache. In the nginx.conf konfigurazio fitxategia, jarraibide hauek erabili behar dira:

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;

        ...
    }
}

Zerbitzu bakoitzean aldaketak egin ondoren, berriro kargatu behar dira:

sudo systemctl restart apache2

Edo:

sudo systemctl restart nginx

Adibide hauek oinarrizko konfigurazio bat baino ez dute eskaintzen, eta baldintza zehatzen eta erasoen izaeraren arabera gehiago egokitu daitekeena.

MySQL kontsultak optimizatzea

Web zerbitzari batean MySQL datu-basearen kontsultak optimizatzea hainbat modutara lor daiteke, eta horietako bat konfigurazio fitxategiaren konfigurazio egokia da. Normalean, fitxategi honi izena ematen zaio nire.cnf or nire.ini eta kokatuta dago / etc / or /etc/mysql/ direktorioa. Ireki eta aldaketa hauek egin behar dituzu:

[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

Har ditzagun zerbitzariaren datu-basearekin elkarrekintza erraztu dezaketen gomendio gehigarriak ere:

1. Erabili AZALTZEN komandoa SQL kontsulta baten aurretik haren exekuzioa aztertzeko. Horri esker, kontsultaren exekuzio-plan bat lortu dezakezu eta zein indize erabiltzen diren, zein taula eskaneatzen diren, etab.
2. Indizeek datuen bilaketa bizkortzen dute, beraz, behar bezala diseinatutako indizeek kontsulten errendimendua nabarmen hobetu dezakete. Erreparatu maiz erabiltzen diren zutabeei NON or ELKARTU baldintzak.
3. Saihestu erabiltzen SELECT *. Zehaztu zure kontsultarako benetan beharrezkoak diren zutabeak soilik, taula bateko zutabe guztiak hautatu beharrean.
4. Saihestu barruko funtzioak erabiltzea NON baldintzak. Funtzioak erabiltzea (adibidez LOWER, UPPER, EZKER, RIGHT) sartu NON baldintzek indizeak alferrikakoak izan ditzakete. Saiatu haien zuzeneko erabilera baldintzetan saihesten.
5. Erabili INNER JOIN ahal denean, eraginkorragoa izan ohi baita. Gainera, ziurtatu elkartzeko dagozkien zutabeek indizeak dituztela.
6. Erabili LIMIT itzultzen diren errenkaden kopurua mugatzeko emaitza kopuru jakin bat bakarrik lortu behar baduzu.
7. Kontuan izan kontsulten emaitzak cachean gordetzea, batez ere gutxitan aldatzen badira, zerbitzariaren karga murrizteko.

Posta zerbitzariak karga handia sortzen du zerbitzarian

Atal honetan, posta zerbitzariak karga handia duela nola zehaztu eta funtzionamendua optimizatzeko zer urrats egin daitezkeen aztertuko dugu, besteak beste, mezu-ilara egiaztatzea eta zerbitzariaren parametroak konfiguratzea. Hasi mezu-ilara egiaztatzen. The mailq utilitateak honetan lagun dezake, aktibatzeko, idatzi dagokion komandoa terminalean:

mailq

Honek ilaran dauden mezuen zerrenda bistaratuko du, baldin badago. Mezu bakoitza bere identifikatzaile esklusiboarekin eta bidalketaren egoerari buruzko informazioarekin bistaratuko da. Antzeko emaitza lor daiteke posta-bezeroen erregistroak aztertuz.

Kasu gehienetan, karga handia gertatzen da zerbitzaria arriskuan jartzen bada spama bidaltzen hasten denean. Dena den, administratzaileak egiaztatu ondoren zerbitzariari kanpotik erasotu ez zaiola ziur bada eta erabiltzaileek spam-a alde batera uzten ez badute, bada garaia posta zerbitzaria optimizatzera pasatzeko. Hona hemen lagunduko dizuten urratsak:

1. Ziurtatu zure domeinuko DNS erregistroak behar bezala konfiguratuta daudela, barne SPF, DKIM, eta DMARC erregistroak posta bidalketa hobetzeko eta spam-aren aurka babesteko. Parametroen konfigurazio zuzena buruzko artikuluan aurki daiteke posta zerbitzariaren diagnostikoak.
2. Egiaztatu sarearen ezarpenak, suebakiaren konfigurazioa eta bideratze-arauak barne, blokeoak saihesteko eta posta bidaltzeko bizkortzeko.
3. Konfiguratu mezu-ilararen parametroak zerbitzariaren kargaren arabera. Horrek ilararen gehienezko tamaina eta denbora-muga ezartzea izan dezake.
4. Artikulu honetan aipatu ditugun irtenbideak kontuan hartu. Aldian-aldian optimizatu posta-zerbitzariaren datu-basea errendimendua hobetzeko, erabili cache-mekanismoak datuen bilaketa eta prozesamendua azkartzeko, hala nola DNS kontsultak.
5. Posta-zerbitzariak karga handia izaten jarraitzen badu, kontuan hartu eskalatzeko aukerak, hala nola posta-zerbitzarien multzoa edo hodeiko irtenbideak erabiltzea.

Ondorioa

Zerbitzariaren karga handitzeak webgunearen kargatzeko abiadurari eragiten dio zuzenean, azken finean, erabiltzailearen esperientzian eta bilatzaileetan ospea eragiten du. Beraz, karga hori modu eraginkorrean kudeatzea funtsezkoa da baliabidearen etengabeko funtzionaltasuna bermatzeko eta bisitarientzako irisgarritasuna areagotzeko.