Yn dit artikel sille wy ferdjipje yn wêrom't ferhege serverlading optreedt en ferskate manieren beprate om prosessen mei hege lading te optimalisearjen. Spesjaal omtinken sil jûn wurde oan koade-optimisaasje yn Apache / Nginx en MySQL, wy sille prate oer caching as in helpmiddel, en ek beskôgje mooglike eksterne bedrigingen, lykas DDOS-oanfallen, en manieren om se te foarkommen.
Wêrom Server Load Optreedt
Foardat jo trochgean mei tsjinneroptimalisaasje, is it nedich om in yngeande analyse te fieren fan 'e hjoeddeistige lading op boarnen. Dit omfettet it mjitten fan CPU-lading, RAM-gebrûk, netwurkaktiviteit en oare wichtige parameters. De dynamyk en pyklasten begripe kinne knelpunten identifisearje en de allocaasje fan boarnen optimalisearje, sadat de stabiliteit en prestaasjes fan 'e serverynfrastruktuer ferheegje.
Foar it earste probleemoplossing fan hege serverbelêsting, advisearje wy in algemiene serverdiagnostyk út te fieren . As dit net genôch is, is in detaillearre analyze fan boarnen nedich. As in helpmiddel kin it ûndersykjen fan 'e logs fan' e Linux- server nuttich wêze, om't hjir yn 'e measte gefallen de boarne fan it probleem leit.
Apache / Nginx-tsjinner optimalisearje
Ferhege tsjinnerbelêsting fanwege yndeksearring
Ferhege lading troch yndeksearring op 'e tsjinner kin foarkomme, bygelyks as sykmasines in grut oantal siden op jo side scannen. Dit kin liede ta ferhege gebrûk fan serverboarnen en, as gefolch, de prestaasjes fan 'e side fertrage. Identifisearje de oarsaak is relatyf ienfâldich; jo moatte it bestân iepenje op:
/var/www/httpd-logs/sitename.access.logAs yndeksearre troch sykmasines, sil de brûker yngongen sjen fan de folgjende aard:
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)"As in earste oplossing om de lading te ferminderjen, kinne jo de ynstelling fan metatags "noindex" en "nofollow" brûke op siden dy't net yndeksearre hoege te wurden. De twadde oplossing is it .htaccess- bestân, wêrby't yngongen dy't oerienkomme mei spesifike sykmasines tafoege wurde moatte, bygelyks om te ferbergjen foar Yandex en Google:
SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_botLikegoed moatte bewurkings makke wurde foar oare sykmasines. It moat opmurken wurde dat de mooglikheden fan .htaccess net beheind binne ta allinich it blokkearjen fan yndeksearjen. Wy riede oan om yn it artikel mear bekend te wurden mei de wichtichste funksjes.
Caching-ynstellingen brûke
Ferkearde caching-ynstellings op 'e server kinne ek liede ta hege lading. Om dizze parameter te optimalisearjen, moatte oerienkommende feroarings makke wurde yn 'e konfiguraasjebestannen of .htaccess . Yn it gefal fan Apache hat de lêste opsje de foarkar, foar Nginx de earste.
Op in Apache- tsjinner moatte jo it .htacess- bestân iepenje en de folgjende koade ynfoegje:
<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>Skeakelje dan de Expires- module yn mei it kommando:
sudo a2enmod expiresWernei de webserver opnij starte:
sudo service apache2 restartEn aktivearje de module troch op te jaan:
ExpiresActive OnOp in Nginx -tsjinner is it genôch om de folgjende koade ta te foegjen oan it konfiguraasjebestân:
location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}En fier in tsjinst opnij laden:
sudo service nginx restartTink derom dat mei dizze ynstellings de rjochtlinen Tastean en Weigerje oerslein wurde.
Gebrûk fan gegevenskompresje
It ynskeakeljen fan gegevenskompresje mei Gzip op Apache- en Nginx-webservers helpt de hoemannichte gegevens te ferminderjen dy't tusken de server en de kliïnt oerdroegen wurdt, wat de prestaasjes ferbetteret en de laadtiid fan websiden ferminderet.
Om Gzip op Apache yn te skeakeljen , moatte jo de mod_deflate module aktivearje:
sudo a2enmod deflateStart dan de webserver opnij:
sudo service apache2 restartEn as lêste, foegje it folgjende blok ta oan it konfiguraasjetriem of .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>Dizze konfiguraasje makket kompresje foar bepaalde soarten triemmen mooglik en skeakelet it út foar ôfbyldings.
Yn it gefal fan Nginx fynt de konfiguraasje plak yn it http- blok fan it konfiguraasjebestân. De folgjende koade moat tafoege wurde:
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;Lykas by Apache wurde hjir de kompresjeparameters foar bepaalde soarten bestannen ynsteld. Nei it meitsjen fan feroarings oan ien fan 'e webservers is in opnij laden fan 'e tsjinst fereaske:
sudo service apache2 restartOr
sudo service nginx restartDDOS oanfal op de tsjinner
Hege serverbelêsting kin foarkomme as gefolch fan in DDoS-oanfal. It identifisearjen fan de oanwêzigens fan in DDoS-oanfal kin dien wurde troch it kontrolearjen fan in hommelse ferheging fan ferkear, abnormale oanfragen, en drippen fan serverprestaasjes. It besjen fan logs foar werhelle oanfragen fan ien IP-adres of poarte-scanning kin ek in mooglike DDoS-oanfal oanjaan. D'r binne in protte beskermingsmaatregels, mar wy sille allinich de basis besprekke.
Mei help fan in CDN (Content Delivery Network) . In CDN kin tsjinje as tuskenpersoan tusken jo webserver en brûkers, ferkear ferspriede en ynhâld yn 'e cache opslaan om de ynfloed fan in DDoS-oanfal te ferminderjen. CDN's kinne ek ynboude DDoS-beskermingsmeganismen hawwe, ynklusyf ladingferdieling en ferkearsfiltering.
Firewalls en ynbraakdeteksjesystemen (IDS/IPS) konfigurearje . Firewalls kinne wurde konfigurearre om ferkear te filterjen op basis fan ferskate kritearia, lykas IP-adressen en poarten. IDS/IPS kin abnormaal ferkearsgedrach detektearje en fertochte ferbiningen blokkearje. Dizze ark kinne effektyf wêze yn it folgjen en blokkearjen fan potinsjeel kwea-aardich ferkear.
It konfigurearjen fan Apache- en Nginx-webservers om de ynfloed fan DDoS-oanfallen te ferminderjen.
As oplossing foar Apache, skeakelje wy de mod_evasive module yn. Om dit te dwaan, ûntkommentearje of foegje de folgjende rigel ta yn it httpd.conf- of apache2.conf -konfiguraasjetriem:
LoadModule evasive20_module modules/mod_evasive.soYn itselde bestân moatte jo in ynstellingsblok taheakje:
<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>Op deselde wize aktivearje wy de mod_ratelimit module:
LoadModule ratelimit_module modules/mod_ratelimit.soEn foegje de konfiguraasje ta:
<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>De konfiguraasje foar Nginx is fergelykber mei Apache . Yn it konfiguraasjetriem nginx.conf moatte de folgjende rjochtlinen brûkt wurde:
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;
...
}
}Nei it meitsjen fan wizigingen oan elk fan 'e tsjinsten, moatte se opnij laden wurde:
sudo systemctl restart apache2Of:
sudo systemctl restart nginxDizze foarbylden jouwe allinich in basiskonfiguraasje, dy't fierder oanpast wurde kin ôfhinklik fan spesifike easken en de aard fan oanfallen.
Optimalisearje MySQL Queries
It optimalisearjen fan MySQL-databasefragen op in webserver kin op ferskate manieren berikt wurde, en ien dêrfan is de juste konfiguraasje fan it konfiguraasjebestân. Typysk hjit dit bestân my.cnf of my.ini en leit it yn 'e map /etc/ of /etc/mysql/ . Jo moatte it iepenje en de folgjende feroarings meitsje:
[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 = 200MLitte wy ek oanfoljende oanbefellings beskôgje dy't ynteraksje mei de serverdatabase kinne fasilitearje:
- Brûk de FERKLAAN kommando foar in SQL-query om de útfiering te analysearjen. Hjirmei kinne jo in útfieringsplan krije foar de query en bepale hokker yndeksen wurde brûkt, hokker tabellen wurde skansearre, ensfh.
- Yndeksen fersnelle gegevenssykjen, sadat goed ûntworpen yndeksen de queryprestaasjes signifikant kinne ferbetterje. Soarch omtinken foar kolommen dy't faak brûkt wurde yn WÊR or JOIN betingsten.
- Foarkom gebrûk ÚTKIEZE *. Spesifisearje allinich de kolommen dy't wirklik nedich binne foar jo query, ynstee fan alle kolommen yn in tabel te selektearjen.
- Foarkom it brûken fan funksjes yn WÊR betingsten. It brûken fan funksjes (lykas LEGER, HEGER, LINKS, RJOCHTS) yn WÊR betingsten kinne yndeksen nutteloos meitsje. Besykje har direkte gebrûk yn betingsten te foarkommen.
- Brûke BINNE JOIN wêr mooglik, sa't it meastal effisjinter is. Soargje der ek foar dat de oerienkommende kolommen foar oansluting yndeksen hawwe.
- Brûke LIMIT om it oantal weromjûne rigen te beheinen as jo mar in bepaald oantal resultaten krije moatte.
- Beskôgje it caching fan query-resultaten, benammen as se komselden feroarje, om de tsjinnerbelêsting te ferminderjen.
De e-posttsjinner makket hege lading op 'e tsjinner
Yn dizze seksje sille wy ûndersykje hoe't wy kinne fêststelle dat de e-posttsjinner in hege lading hat en hokker stappen nommen wurde kinne om de wurking te optimalisearjen, ynklusyf it kontrolearjen fan de berjochtenwachtrige en it konfigurearjen fan serverparameters. Begjin mei it kontrolearjen fan de berjochtenwachtrige. It hulpprogramma mailq kin hjirby helpe, om it te aktivearjen, fier it oerienkommende kommando yn 'e terminal yn:
mailqDit sil in list mei berjochten yn 'e wachtrige werjaan, as der binne. Elk berjocht sil werjûn wurde mei syn unike identifier en ynformaasje oer de ferstjoerstatus. In ferlykber resultaat kin wurde krigen troch de e-postclientlogs te besjen.
Yn 'e measte gefallen komt hege lading foar yn gefal fan tsjinner kompromis as it begjint spam te ferstjoeren. As lykwols, nei it kontrolearjen, de behearder der wis fan is dat de tsjinner net fan bûten is oanfallen en brûkers spam net negearje, is it tiid om troch te gean nei it optimalisearjen fan de e-posttsjinner. Hjir binne de stappen dy't sille helpe:
- Soargje derfoar dat de DNS-records fan jo domein goed binne ynsteld, ynklusyf SPF, DKIM, en DMARC records om postferstjoering te ferbetterjen en te beskermjen tsjin spam. De juste konfiguraasje fan parameters is te finen yn it artikel oer mail tsjinner diagnostyk.
- Kontrolearje netwurkynstellingen, ynklusyf firewall-konfiguraasje en routingregels, om blokken te foarkommen en e-postlevering te fersnellen.
- Konfigurearje berjochtwachtrige parameters neffens tsjinner load. Dit kin omfetsje it ynstellen fan de maksimale wachtrigegrutte en timeouts.
- Beskôgje de oplossingen dy't wy earder yn dit artikel besprutsen hawwe. Optimalisearje de e-postserverdatabase periodyk om prestaasjes te ferbetterjen, brûk cachingmeganismen om gegevenssykjen en ferwurking te fersnellen, lykas DNS-fragen.
- As de e-posttsjinner noch geregeld in hege lading tsjinkomt, beskôgje dan skaalopsjes, lykas it brûken fan in kluster fan e-posttsjinners of wolkoplossingen.
Konklúzje
Ferheegde serverlading hat direkt ynfloed op it laden fan webside, en hat úteinlik ynfloed op brûkersûnderfining en reputaasje yn sykmasines. Sa spilet it effektyf behear fan dizze lading in wichtige rol by it garandearjen fan trochgeande funksjonaliteit fan 'e boarne en it fergrutsjen fan de tagonklikens foar besikers.
