Reduktante servilŝarĝon

En ĉi tiu artikolo, ni esploros kial pliigita servila ŝarĝo okazas kaj diskutos diversajn manierojn optimumigi altŝarĝajn procezojn. Speciala atento estos donita al koda optimumigo en Apache/Nginx kaj MySQL, ni parolos pri kaŝmemoro kiel helpa ilo, kaj ankaŭ konsideros eblajn eksterajn minacojn, kiel DDOS-atakojn, kaj manierojn malhelpi ilin.

Kial Servila Ŝarĝo Okazas

Antaŭ ol iri al servila optimumigo, necesas fari profundan analizon de la nuna ŝarĝo de rimedoj. Ĉi tio inkluzivas mezuri CPU-ŝarĝon, RAM-uzadon, retan agadon kaj aliajn ŝlosilajn parametrojn. Kompreni la dinamikon kaj pintajn ŝarĝojn permesas identigi proplempunktojn kaj optimumigi la asignon de rimedoj, tiel pliigante la stabilecon kaj rendimenton de la servila infrastrukturo.

Por komenca problemo de alta servila ŝarĝo, ni rekomendas fari a ĝeneralaj servilaj diagnozoj. Se ĉi tio estas nesufiĉa, pli detala analizo de rimedoj estas necesa. Kiel helpa ilo, esplorante la protokoloj de la Linukso servilo povas esti helpema, ĉar ĉi tie troviĝas la fonto de la problemo plejofte.

Optimumigo de Apache/Nginx-Servilo

Pliigita Servila Ŝarĝo Pro Indeksado

Pliigita ŝarĝo pro indeksado sur la servilo povas okazi, ekzemple, kiam serĉiloj skanas grandan nombron da paĝoj en via retejo. Ĉi tio povas konduki al pliigita uzo de servilaj rimedoj kaj, sekve, malrapidigi la agadon de la retejo. Identigi la kaŭzon estas relative simpla; vi devas malfermi la dosieron situantan ĉe:

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

Kiam indeksita de serĉiloj, la uzanto vidos enskribojn de la sekva naturo:

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

Kiel unua solvo por redukti la ŝarĝon, vi povas uzi la agordon de meta-etikedoj "senindekso" kaj "nesekvu" sur paĝoj kiuj ne bezonas esti indeksitaj. La dua solvo estas la .htaccess dosiero, kie enskriboj respondaj al specifaj serĉiloj devas esti aldonitaj, ekzemple, por kaŝi de Yandex kaj Guglo:

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

Simile, redaktoj devas esti faritaj por aliaj serĉiloj. Oni devas rimarki, ke la kapabloj de .htaccess ne estas limigitaj al nur blokado de indeksado. Ni rekomendas pli familiariĝi kun ĝiaj ĉefaj trajtoj en la artikolo.

Uzante Caching-Agordojn

Malĝustaj kaŝmemoraj agordoj sur la servilo ankaŭ povas konduki al alta ŝarĝo. Por optimumigi ĉi tiun parametron, respondaj ŝanĝoj devas esti faritaj en la agordaj dosieroj aŭ .htaccess. En la kazo de Apache, ĉi-lasta opcio estas preferinda, por Nginx - la unua.

Je Apache servilo, vi devas malfermi la .htacess dosieron kaj enigu la jenan kodon:

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

Tiam, ebligu la Eksvalidiĝas modulo uzante la komandon:

sudo a2enmod expires

Post tio, rekomencu la retservilon:

sudo service apache2 restart

Kaj aktivigu la modulon specifante:

ExpiresActive On

Sur Nginx servilo, sufiĉas aldoni la jenan kodon al la agorda dosiero:

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

Kaj faru servon reŝargi:

sudo service nginx restart

Notu, ke kun ĉi tiuj agordoj, la permesus kaj Denu direktivoj estos preterpasitaj.

Uzante Datumkunpremadon

Ebligante datuman kunpremadon uzante Gzip sur Apache kaj Nginx retserviloj helpas redukti la kvanton de datumoj transdonitaj inter la servilo kaj la kliento, kiu plibonigas rendimenton kaj reduktas retpaĝa ŝarĝo tempo.

Ebligi Gzip on Apache, vi devas aktivigi la mod_deflate modulo:

sudo a2enmod deflate

Poste, rekomencu la retservilon:

sudo service apache2 restart

Kaj finfine, aldonu la sekvan blokon al la agorda dosiero aŭ .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>

Ĉi tiu agordo ebligas kunpremadon por certaj specoj de dosieroj kaj malŝaltas ĝin por bildoj.

En la kazo de Nginx, agordo okazas en la Http bloko de la agorda dosiero. La sekva kodo devas esti aldonita:

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;

Simila al Apache, ĉi tie la kunpremaj parametroj por certaj specoj de dosieroj estas fiksitaj. Post fari ŝanĝojn al iu el la retserviloj, servo reŝargi estas postulata:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS-Atako sur la Servilo

Alta servila ŝarĝo povas okazi kiel rezulto de DDoS-atako. Identigi la ĉeeston de DDoS-atako povas esti farita per monitorado de subita kresko de trafiko, nenormalaj petoj kaj servilaj rendimento-faloj. Revizii protokolojn por ripetaj petoj de unu IP-adreso aŭ havena skanado ankaŭ povas indiki eblan DDoS-atakon. Estas multaj protektaj mezuroj, sed ni diskutos nur la bazaĵojn.

Uzante CDN (Enhavo-Livera Reto). CDN povas servi kiel peranto inter via retservilo kaj uzantoj, distribuante trafikon kaj konservante enhavon por mildigi la efikon de DDoS-atako. CDN-oj ankaŭ povas havi enkonstruitajn DDoS-protektajn mekanismojn, inkluzive de ŝarĝa distribuo kaj trafika filtrado.

Agordi fajroŝirmilojn kaj entrudiĝajn detektajn sistemojn (IDS/IPS). Fajromuroj povas esti agorditaj por filtri trafikon laŭ diversaj kriterioj, kiel IP-adresoj kaj havenoj. IDS/IPS povas detekti eksternorman trafikan konduton kaj bloki suspektindajn ligojn. Ĉi tiuj iloj povas esti efikaj por spuri kaj bloki eble malican trafikon.

Agordante retservilojn Apache kaj Nginx por mildigi la efikon de DDoS-atakoj.

Kiel solvo por Apache, ni ebligas la mod_evasiva modulo. Por fari tion, malkomentu aŭ aldonu la sekvan linion en la httpd.conf or apache2.conf agorda dosiero:

LoadModule evasive20_module modules/mod_evasive.so

En la sama dosiero, vi devas aldoni agordan blokon:

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

Simile, ni aktivigas la mod_ratelim modulo:

LoadModule ratelimit_module modules/mod_ratelimit.so

Kaj aldonu la agordon:

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

La agordo por Nginx similas al Apache. En la nginx.conf agorda dosiero, la sekvaj direktivoj devas esti uzataj:

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;

        ...
    }
}

Post fari ŝanĝojn al ĉiu el la servoj, ili devas esti reŝargitaj:

sudo systemctl restart apache2

aŭ:

sudo systemctl restart nginx

Tiuj ekzemploj disponigas nur bazan agordon, kiu povas esti plue adaptita depende de specifaj postuloj kaj la naturo de atakoj.

Optimumigo de MySQL-Demandoj

Optimumigo de MySQL-datumbazaj demandoj en retservilo povas esti atingita en diversaj manieroj, kaj unu el ili estas la taŭga agordo de la agorda dosiero. Tipe, ĉi tiu dosiero estas nomita mia.cnf or mia.ini kaj situas en la / ktp / or /etc/mysql/ dosierujo. Vi devas malfermi ĝin kaj fari la sekvajn ŝanĝojn:

[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

Ni konsideru ankaŭ kromajn rekomendojn, kiuj povas faciligi interagadon kun la servila datumbazo:

1. Uzu la EKZAMENO komando antaŭ SQL-demando por analizi ĝian ekzekuton. Ĉi tio ebligas al vi akiri ekzekutplanon por la demando kaj determini kiuj indeksoj estas uzataj, kiuj tabeloj estas skanitaj, ktp.
2. Indeksoj akcelas datumserĉon, do konvene dezajnitaj indeksoj povas signife plibonigi demandan rendimenton. Atentu kolumnojn, kiuj estas ofte uzataj en WHERE or JOIN kondiĉoj.
3. Evitu uzi SELEKTU *. Specifu nur tiujn kolumnojn kiuj estas vere necesaj por via demando, anstataŭ elekti ĉiujn kolumnojn en tabelo.
4. Evitu uzi funkciojn en WHERE kondiĉoj. Uzante funkciojn (kiel ekzemple MALPLI, UPPER, MALDEKSTRA, RIGHT) en WHERE kondiĉoj povas senutiligi indeksojn. Provu eviti ilian rektan uzon en kondiĉoj.
5. uzo INTERNA ALIĜO kie eblas, ĉar ĝi estas kutime pli efika. Ankaŭ certigu, ke la respondaj kolumnoj por kunigo havas indeksojn.
6. uzo LIMIT por limigi la nombron de redonitaj vicoj se vi bezonas ricevi nur certan nombron da rezultoj.
7. Konsideru konservi enketrezultojn, precipe se ili malofte ŝanĝiĝas, por redukti servilan ŝarĝon.

La Poŝtservilo Kreas Alta Ŝarĝo sur la Servilo

En ĉi tiu sekcio, ni esploros kiel determini, ke la poŝtservilo spertas altan ŝarĝon kaj kiajn paŝojn oni povas preni por optimumigi ĝian funkciadon, inkluzive de kontrolado de la mesaĝvico kaj agordo de servilaj parametroj. Komencu kontroli la mesaĝvicon. La mailq ilo povas helpi pri tio, por aktivigi ĝin, enigu la respondan komandon en la terminalo:

mailq

Ĉi tio montros liston de mesaĝoj en la atendovico, se ekzistas. Ĉiu mesaĝo estos montrata kun sia unika identigilo kaj informoj pri la senda stato. Simila rezulto povas esti akirita per revizio de la retpoŝtaj klientaj protokoloj.

Plejofte, alta ŝarĝo okazas okaze de servila kompromiso kiam ĝi komencas sendi spamon. Tamen, se post kontrolo la administranto certas, ke la servilo ne estis atakita de ekstere kaj uzantoj ne neglektas spamon, estas tempo pluiri al optimumigo de la poŝtservilo. Jen la paŝoj, kiuj helpos:

1. Certigu, ke la DNS-rekordoj de via domajno estas ĝuste agorditaj, inkluzive SPF, DKIMKaj DMARC rekordoj por plibonigi poŝtan liveron kaj protekti kontraŭ spamado. La ĝusta agordo de parametroj troveblas en la artikolo pri diagnozo de poŝtservilo.
2. Kontrolu retajn agordojn, inkluzive de fajroŝirmilo-agordo kaj vojreguloj, por eviti blokojn kaj akceli poŝtan liveron.
3. Agordi la parametrojn de mesaĝvostovicoj laŭ servila ŝarĝo. Ĉi tio povas inkluzivi agordi la maksimuman atendovicgrandon kaj tempodaŭrojn.
4. Konsideru la solvojn, kiujn ni antaŭe diskutis en ĉi tiu artikolo. Periode optimumigu la datumbazon de poŝtservilo por plibonigi rendimenton, uzu kaŝmemormekanismojn por akceli datumserĉon kaj prilaboradon, kiel DNS-demandojn.
5. Se la poŝtservilo ankoraŭ regule renkontas altan ŝarĝon, konsideru skali opciojn, kiel uzi aron da poŝtserviloj aŭ nubaj solvoj.

konkludo

Pliigita servila ŝarĝo rekte influas retejan ŝarĝrapidecon, finfine influante uzantan sperton kaj reputacion en serĉiloj. Tiel, efike administri ĉi tiun ŝarĝon ludas ŝlosilan rolon por certigi kontinuan funkciecon de la rimedo kaj pliigi ĝian alireblecon por vizitantoj.