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.

Zerbitzari-karga handiaren hasierako arazoak konpontzeko, zerbitzariaren diagnostiko orokorra egitea gomendatzen dugu. Hori nahikoa ez bada, baliabideen analisi zehatzagoa beharrezkoa da. Tresna laguntzaile gisa, Linux zerbitzariaren erregistroak aztertzea lagungarria izan daiteke, kasu gehienetan arazoaren iturria hor baitago.

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, "noindex" eta "nofollow" meta etiketak erabil ditzakezu indexatu behar ez diren orrialdeetan. Bigarren irtenbidea .htaccess fitxategia da, non bilaketa-motor espezifikoei 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 batzuetarako aldaketak egin behar dira. Kontuan izan behar da .htaccess-en gaitasunak ez direla indexazioa blokeatzera mugatzen. Artikuluan bere ezaugarri nagusiak hobeto ezagutzea gomendatzen dugu.

Cachearen ezarpenak erabiltzea

Zerbitzarian cache ezarpen okerrek ere karga handia ekar dezakete. Parametro hau optimizatzeko, konfigurazio fitxategietan edo .htaccess fitxategian aldaketak egin behar dira . Apache-ren kasuan, azken aukera hobesten da, Nginx-entzat lehenengoa.

Apache zerbitzari batean , .htacess fitxategia ireki eta kode hau txertatu behar duzu :

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

Ondoren, gaitu Expires modulua komando hau erabiliz:

sudo a2enmod expires

Horren ondoren, berrabiarazi web zerbitzaria:

sudo service apache2 restart

Eta aktibatu modulua zehaztuz:

ExpiresActive On

Nginx zerbitzari batean , nahikoa da konfigurazio fitxategira kode hau gehitzea:

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, Allow eta Deny direktibak saihestuko direla.

Datuen konpresioa erabiliz

Apache eta Nginx web zerbitzarietan Gzip erabiliz datuen konpresioa gaitzeak zerbitzariaren eta bezeroaren artean transmititzen den datu kopurua murrizten laguntzen du, eta horrek errendimendua hobetzen du eta web orriaren kargatzeko denbora murrizten du.

Apache -n Gzip gaitzeko , mod_deflate modulua aktibatu behar duzu :

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.

Nginx -en kasuan , konfigurazioa konfigurazio fitxategiaren http blokean gertatzen da. 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;

Apache- ren antzera , hemen fitxategi mota jakin batzuetarako konpresio parametroak ezartzen dira. Web zerbitzarietan aldaketak egin ondoren, zerbitzua berriro kargatu 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 (Edukia Banatzeko Sarea) 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 babes mekanismo integratuak ere izan ditzakete, besteak beste, karga banaketa eta trafiko iragazketa.

Suebakiak eta intrusioak detektatzeko sistemak (IDS/IPS) konfiguratzea . Suebakiak hainbat irizpideren arabera trafikoa iragazteko konfigura daitezke, hala nola IP helbideak eta atakak. IDS/IPS-ek trafikoaren portaera anormala detektatu eta konexio susmagarriak blokeatu ditzakete. Tresna hauek eraginkorrak izan daitezke potentzialki gaiztoa den trafikoa jarraitzeko eta blokeatzeko.

Apache eta Nginx web zerbitzariak konfiguratzea DDoS erasoen eragina arintzeko.

Apache-rako irtenbide gisa, mod_evasive modulua gaitzen dugu. Horretarako, kendu iruzkina edo gehitu lerro hau httpd.conf edo apache2.conf konfigurazio fitxategian:

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, mod_ratelimit modulua aktibatzen dugu :

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>

Nginx -en konfigurazioa Apache- ren antzekoa da . Nginx.conf konfigurazio fitxategian, honako direktiba 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-baseko kontsultak optimizatzea hainbat modutan lor daiteke, eta horietako bat konfigurazio fitxategiaren konfigurazio egokia da. Normalean, fitxategi honi my.cnf edo my.ini izena jartzen zaio eta /etc/ edo /etc/mysql/ direktorioan dago . 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 jasaten ari dela nola zehaztu aztertuko dugu eta bere funtzionamendua optimizatzeko zer urrats eman daitezkeen aztertuko dugu, mezu-ilara egiaztatzea eta zerbitzariaren parametroak konfiguratzea barne. Hasi mezu-ilara egiaztatzen. Mailq utilitateak horretan lagun zaitzake, 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.