Reduktimi i ngarkesës së serverit

Në këtë artikull, ne do të shqyrtojmë pse ndodh rritja e ngarkesës së serverit dhe do të diskutojmë mënyra të ndryshme për të optimizuar proceset me ngarkesë të lartë. Vëmendje e veçantë do t'i kushtohet optimizimit të kodit në Apache/Nginx dhe MySQL, ne do të flasim për caching si një mjet ndihmës dhe gjithashtu do të shqyrtojmë kërcënimet e mundshme të jashtme, siç janë sulmet DDOS dhe mënyrat për t'i parandaluar ato.

Pse ndodh ngarkimi i serverit

Para se të vazhdoni me optimizimin e serverit, është e nevojshme të bëni një analizë të plotë të ngarkesës aktuale në burime. Kjo përfshin matjen e ngarkesës së CPU-së, përdorimin e RAM-it, aktivitetin e rrjetit dhe parametra të tjerë kyç. Kuptimi i dinamikës dhe ngarkesave maksimale lejon identifikimin e pengesave dhe optimizimin e alokimit të burimeve, duke rritur kështu stabilitetin dhe performancën e infrastrukturës së serverit.

Për zgjidhjen fillestare të problemeve të ngarkesës së lartë të serverit, ne rekomandojmë kryerjen e një diagnostifikimi i përgjithshëm i serverit. Nëse kjo është e pamjaftueshme, një më e detajuar analiza e burimeve është e nevojshme. Si një mjet ndihmës, duke eksploruar regjistrat e Linux-it serveri mund të jetë i dobishëm, pasi këtu gjendet burimi i problemit në shumicën e rasteve.

Optimizimi i serverit Apache/Nginx

Ngarkesa e rritur e serverit për shkak të indeksimit

Rritja e ngarkesës për shkak të indeksimit në server mund të ndodhë, për shembull, kur motorët e kërkimit skanojnë një numër të madh faqesh në faqen tuaj. Kjo mund të çojë në rritjen e përdorimit të burimeve të serverit dhe, rrjedhimisht, në ngadalësimin e performancës së faqes. Identifikimi i shkakut është relativisht i thjeshtë; ju duhet të hapni skedarin e vendosur në:

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

Kur indeksohet nga motorët e kërkimit, përdoruesi do të shohë hyrje të natyrës së mëposhtme:

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

Si zgjidhje e parë për të reduktuar ngarkesën, mund të përdorni vendosjen e meta etiketave "noindex" "nofollow" në faqet që nuk kanë nevojë të indeksohen. Zgjidhja e dytë është . Htaccess skedar, ku duhet të shtohen hyrjet që korrespondojnë me motorë kërkimi specifik, për shembull, për t'u fshehur nga Yandex dhe 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ë mënyrë të ngjashme, modifikimet duhet të bëhen për motorët e tjerë të kërkimit. Duhet të theksohet se aftësitë e .htaccess nuk kufizohen vetëm në bllokimin e indeksimit. Ne ju rekomandojmë të njiheni më shumë me veçoritë e tij kryesore në artikull.

Përdorimi i cilësimeve të memorizimit

Cilësimet e pasakta të memorizimit në server mund të çojnë gjithashtu në ngarkesë të lartë. Për të optimizuar këtë parametër, duhet të bëhen ndryshimet përkatëse në skedarët e konfigurimit ose . Htaccess. Në rastin e Apache, opsioni i fundit është i preferueshëm, për Nginx - i pari.

Ne nje Apache server, ju duhet të hapni .htacess skedari dhe fut kodin e mëposhtëm:

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

Më pas, aktivizoni skadon moduli duke përdorur komandën:

sudo a2enmod expires

Pas së cilës, rinisni serverin në internet:

sudo service apache2 restart

Dhe aktivizoni modulin duke specifikuar:

ExpiresActive On

Në një nginx server, mjafton të shtoni kodin e mëposhtëm në skedarin e konfigurimit:

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

Dhe kryeni një ringarkim të shërbimit:

sudo service nginx restart

Vini re se me këto cilësime, Lejoj Mohoj direktivat do të anashkalohen.

Duke përdorur kompresimin e të dhënave

Mundësimi i ngjeshjes së të dhënave duke përdorur gzip në serverët e internetit Apache dhe Nginx ndihmon në uljen e sasisë së të dhënave të transmetuara midis serverit dhe klientit, gjë që përmirëson performancën dhe zvogëlon kohën e ngarkimit të faqeve në internet.

Për të mundësuar gzip on Apache, duhet të aktivizoni mod_deflate moduli:

sudo a2enmod deflate

Pastaj, rinisni serverin në internet:

sudo service apache2 restart

Dhe së fundi, shtoni bllokun e mëposhtëm në skedarin e konfigurimit ose .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>

Ky konfigurim mundëson kompresimin për lloje të caktuara skedarësh dhe e çaktivizon atë për imazhet.

Ne rastin e nginx, konfigurimi ndodh në http blloku i skedarit të konfigurimit. Kodi i mëposhtëm duhet të shtohet:

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;

Të ngjashme me Apache, këtu vendosen parametrat e kompresimit për lloje të caktuara skedarësh. Pas bërjes së ndryshimeve në ndonjë nga serverët e uebit, kërkohet një ringarkim i shërbimit:

sudo service apache2 restart

Or

sudo service nginx restart

Sulmi DDOS në server

Ngarkesa e lartë e serverit mund të ndodhë si rezultat i një sulmi DDoS. Identifikimi i pranisë së një sulmi DDoS mund të bëhet përmes monitorimit të një rritjeje të papritur të trafikut, kërkesave jonormale dhe rënies së performancës së serverit. Rishikimi i regjistrave për kërkesat e përsëritura nga një adresë IP ose skanimi i portit mund të tregojë gjithashtu një sulm të mundshëm DDoS. Ka shumë masa mbrojtëse, por ne do të diskutojmë vetëm bazat.

Përdorimi i një CDN (Rrjeti i shpërndarjes së përmbajtjes). Një CDN mund të shërbejë si një ndërmjetës midis serverit tuaj të internetit dhe përdoruesve, duke shpërndarë trafikun dhe përmbajtjen e memorizimit për të zbutur ndikimin e një sulmi DDoS. CDN-të mund të kenë gjithashtu mekanizma të integruar mbrojtës DDoS, duke përfshirë shpërndarjen e ngarkesës dhe filtrimin e trafikut.

Konfigurimi i mureve të zjarrit dhe sistemeve të zbulimit të ndërhyrjeve (IDS/IPS). Firewall-et mund të konfigurohen për të filtruar trafikun bazuar në kritere të ndryshme, si adresat IP dhe portet. IDS/IPS mund të zbulojë sjellje jonormale të trafikut dhe të bllokojë lidhjet e dyshimta. Këto mjete mund të jenë efektive në gjurmimin dhe bllokimin e trafikut potencialisht me qëllim të keq.

Konfigurimi i serverëve në internet Apache dhe Nginx për të zbutur ndikimin e sulmeve DDoS.

Si një zgjidhje për Apache, ne mundësojmë mod_evasive modul. Për ta bërë këtë, hiqni komentin ose shtoni rreshtin e mëposhtëm në httpd.conf or apache2.conf skedari i konfigurimit:

LoadModule evasive20_module modules/mod_evasive.so

Në të njëjtin skedar, duhet të shtoni një bllok cilësimesh:

<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ë mënyrë të ngjashme, ne aktivizojmë mod_ratelimit moduli:

LoadModule ratelimit_module modules/mod_ratelimit.so

Dhe shtoni konfigurimin:

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

Konfigurimi për nginx është e ngjashme me Apache. në nginx.konf skedari i konfigurimit, duhet të përdoren direktivat e mëposhtme:

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; ... } }

Pasi të keni bërë ndryshime në secilin prej shërbimeve, ato duhet të ringarkohen:

sudo systemctl restart apache2

Ose:

sudo systemctl restart nginx

Këta shembuj ofrojnë vetëm një konfigurim bazë, i cili mund të përshtatet më tej në varësi të kërkesave specifike dhe natyrës së sulmeve.

Optimizimi i pyetjeve të MySQL

Optimizimi i pyetjeve të bazës së të dhënave MySQL në një server në internet mund të arrihet në mënyra të ndryshme, dhe njëra prej tyre është konfigurimi i duhur i skedarit të konfigurimit. Në mënyrë tipike, ky skedar emërtohet my.cnf or my.ini dhe është e vendosur në / etj / or /etc/mysql/ drejtoria. Ju duhet ta hapni atë dhe të bëni ndryshimet e mëposhtme:

[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

Le të shqyrtojmë gjithashtu rekomandime shtesë që mund të lehtësojnë ndërveprimin me bazën e të dhënave të serverit:

1. Përdorimi Shpjegoni komanda përpara një pyetjeje SQL për të analizuar ekzekutimin e tij. Kjo ju lejon të merrni një plan ekzekutimi për pyetjen dhe të përcaktoni se cilët indekse përdoren, cilat tabela skanohen, etj.
2. Indekset përshpejtojnë kërkimin e të dhënave, kështu që indekset e dizajnuara siç duhet mund të përmirësojnë ndjeshëm performancën e pyetjeve. Kushtojini vëmendje kolonave që përdoren shpesh në KU or BASHKOHU kushtet.
3. Shmang përdorimin SELECT *. Specifikoni vetëm ato kolona që janë vërtet të nevojshme për pyetjen tuaj, në vend që të zgjidhni të gjitha kolonat në një tabelë.
4. Shmangni përdorimin e funksioneve në KU kushtet. Përdorimi i funksioneve (si p.sh POSHTME, UPPER, LEFT, E DREJTA) në KU kushtet mund t'i bëjnë indekset të padobishme. Mundohuni të shmangni përdorimin e tyre të drejtpërdrejtë në kushte.
5. përdorim INNER JOIN aty ku është e mundur, pasi zakonisht është më efikas. Gjithashtu, sigurohuni që kolonat përkatëse për bashkim të kenë indekse.
6. përdorim LIMIT për të kufizuar numrin e rreshtave të kthyer nëse duhet të merrni vetëm një numër të caktuar rezultatesh.
7. Merrni parasysh ruajtjen e rezultateve të pyetjeve në memorie, veçanërisht nëse ato ndryshojnë rrallë, për të zvogëluar ngarkesën e serverit.

Serveri i postës krijon ngarkesë të lartë në server

Në këtë seksion, ne do të shqyrtojmë se si të përcaktojmë që serveri i postës po përjeton ngarkesë të lartë dhe çfarë hapash mund të ndërmerren për të optimizuar funksionimin e tij, duke përfshirë kontrollimin e radhës së mesazheve dhe konfigurimin e parametrave të serverit. Filloni me kontrollimin e radhës së mesazheve. Të mailq mjeti mund të ndihmojë me këtë, për ta aktivizuar atë, futni komandën përkatëse në terminal:

mailq

Kjo do të shfaqë një listë të mesazheve në radhë, nëse ka. Çdo mesazh do të shfaqet me identifikuesin e tij unik dhe informacion rreth statusit të dërgimit. Një rezultat i ngjashëm mund të merret duke rishikuar regjistrat e klientëve të postës.

Në shumicën e rasteve, ngarkesa e lartë ndodh në rast të komprometimit të serverit kur ai fillon të dërgojë mesazhe të padëshiruara. Sidoqoftë, nëse pas kontrollit, administratori është i sigurt se serveri nuk është sulmuar nga jashtë dhe përdoruesit nuk po e lënë pas dore mesazhin e padëshiruar, është koha të kaloni në optimizimin e serverit të postës. Këtu janë hapat që do të ndihmojnë:

1. Sigurohuni që të dhënat DNS të domenit tuaj janë konfiguruar saktë, duke përfshirë SPF, DKIMdhe Zgjerimi DMARC regjistrime për të përmirësuar shpërndarjen e postës dhe për të mbrojtur kundër spamit. Konfigurimi i saktë i parametrave mund të gjendet në artikullin në diagnostikimi i serverit të postës.
2. Kontrolloni cilësimet e rrjetit, duke përfshirë konfigurimin e murit të zjarrit dhe rregullat e rrugëtimit, për të shmangur bllokimet dhe për të shpejtuar dërgimin e postës.
3. Konfiguro parametrat e radhës së mesazheve sipas ngarkesës së serverit. Kjo mund të përfshijë vendosjen e madhësisë maksimale të radhës dhe afateve.
4. Konsideroni zgjidhjet që diskutuam në këtë artikull më parë. Optimizoni periodikisht bazën e të dhënave të serverit të postës për të përmirësuar performancën, përdorni mekanizmat e ruajtjes së memories për të shpejtuar kërkimin dhe përpunimin e të dhënave, siç janë pyetjet DNS.
5. Nëse serveri i postës ende ndeshet rregullisht me ngarkesë të lartë, merrni parasysh opsionet e shkallëzimit, të tilla si përdorimi i një grupi të serverëve të postës ose zgjidhjeve cloud.

Përfundim

Rritja e ngarkesës së serverit ndikon drejtpërdrejt në shpejtësinë e ngarkimit të faqes në internet, duke ndikuar përfundimisht në përvojën dhe reputacionin e përdoruesit në motorët e kërkimit. Kështu, menaxhimi efektiv i kësaj ngarkese luan një rol kyç në sigurimin e funksionalitetit të vazhdueshëm të burimit dhe rritjen e aksesit të tij për vizitorët.