Inapunguza upakiaji wa seva

Katika makala haya, tutachunguza kwa nini kuongezeka kwa mzigo wa seva hutokea na kujadili njia mbalimbali za kuboresha michakato ya upakiaji wa juu. Uangalifu maalum utatolewa kwa uboreshaji wa msimbo katika Apache/Nginx na MySQL, tutazungumza juu ya kache kama zana msaidizi, na pia tutazingatia vitisho vya nje vinavyowezekana, kama vile shambulio la DDOS, na njia za kuzizuia.

Kwa Nini Upakiaji wa Seva Unatokea

Kabla ya kuendelea na uboreshaji wa seva, ni muhimu kufanya uchambuzi wa kina wa mzigo wa sasa kwenye rasilimali. Hii ni pamoja na kupima mzigo wa CPU, matumizi ya RAM, shughuli za mtandao na vigezo vingine muhimu. Kuelewa mienendo na mizigo ya kilele huruhusu kutambua vikwazo na kuboresha ugawaji wa rasilimali, hivyo kuongeza uthabiti na utendakazi wa miundombinu ya seva.

Kwa utatuzi wa awali wa upakiaji wa seva ya juu, tunapendekeza kufanya a utambuzi wa seva ya jumla. Ikiwa hii haitoshi, basi maelezo zaidi uchambuzi wa rasilimali ni muhimu. Kama zana msaidizi, kuchunguza kumbukumbu za Linux seva inaweza kusaidia, kwani hapa ndipo chanzo cha shida kinapatikana katika hali nyingi.

Kuboresha Seva ya Apache/Nginx

Kuongezeka kwa Mzigo wa Seva Kwa Sababu ya Kuorodhesha

Kuongezeka kwa mzigo kutokana na indexing kwenye seva inaweza kutokea, kwa mfano, wakati injini za utafutaji zinatafuta idadi kubwa ya kurasa kwenye tovuti yako. Hii inaweza kusababisha kuongezeka kwa matumizi ya rasilimali za seva na, kwa hiyo, kupunguza kasi ya utendaji wa tovuti. Kutambua sababu ni rahisi; unahitaji kufungua faili iliyoko:

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

Inapoorodheshwa na injini za utafutaji, mtumiaji ataona maingizo ya asili ifuatayo:

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

Kama suluhisho la kwanza la kupunguza mzigo, unaweza kutumia mpangilio wa vitambulisho vya meta "noindex" na "usifuate" kwenye kurasa ambazo hazihitaji kuorodheshwa. Suluhisho la pili ni . Htaccess faili, ambapo maingizo yanayolingana na injini maalum za utafutaji yanahitajika kuongezwa, kwa mfano, kujificha kutoka kwa Yandex na Google:

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

Vile vile, uhariri unahitaji kufanywa kwa injini nyingine za utafutaji. Ikumbukwe kwamba uwezo wa .htaccess sio mdogo tu kuzuia indexing. Tunapendekeza kufahamiana zaidi na sifa zake kuu katika makala.

Kutumia Mipangilio ya Uhifadhi

Mipangilio isiyo sahihi ya caching kwenye seva pia inaweza kusababisha mzigo wa juu. Ili kuboresha parameta hii, mabadiliko yanayolingana yanahitajika kufanywa katika faili za usanidi au . Htaccess. Katika kesi ya Apache, chaguo la mwisho ni vyema, kwa Nginx - ya zamani.

Kwenye Apache seva, unahitaji kufungua .htacess faili na ingiza nambari ifuatayo:

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

Kisha, wezesha Muda wake unaisha moduli kwa kutumia amri:

sudo a2enmod expires

Baada ya hapo, anzisha tena seva ya wavuti:

sudo service apache2 restart

Na kuamsha moduli kwa kubainisha:

ExpiresActive On

Juu ya Nginx seva, inatosha kuongeza nambari ifuatayo kwenye faili ya usanidi:

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

Na fanya upakiaji upya wa huduma:

sudo service nginx restart

Kumbuka kuwa na mipangilio hii, faili ya Kuruhusu na Piga maelekezo yatapuuzwa.

Kutumia Ukandamizaji wa Data

Inawezesha ukandamizaji wa data kwa kutumia gzip kwenye seva za wavuti za Apache na Nginx husaidia kupunguza kiasi cha data inayotumwa kati ya seva na mteja, ambayo inaboresha utendaji na kupunguza muda wa upakiaji wa ukurasa wa wavuti.

Ili kuwezesha gzip on Apache, unahitaji kuamilisha mod_deflate moduli:

sudo a2enmod deflate

Kisha, anzisha tena seva ya wavuti:

sudo service apache2 restart

Na hatimaye, ongeza kizuizi kifuatacho kwenye faili ya usanidi au .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>

Mipangilio hii huwezesha mbano kwa aina fulani za faili na kuizima kwa picha.

Katika kesi ya Nginx, usanidi hutokea katika http kizuizi cha faili ya usanidi. Nambari ifuatayo inahitaji kuongezwa:

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;

Sawa na Apache, hapa vigezo vya compression kwa aina fulani za faili zimewekwa. Baada ya kufanya mabadiliko kwa seva yoyote ya wavuti, upakiaji upya wa huduma unahitajika:

sudo service apache2 restart

Or

sudo service nginx restart

Shambulio la DDOS kwenye Seva

Mzigo wa juu wa seva unaweza kutokea kama matokeo ya shambulio la DDoS. Kutambua kuwepo kwa shambulio la DDoS kunaweza kufanywa kupitia ufuatiliaji wa ongezeko la ghafla la trafiki, maombi yasiyo ya kawaida, na kushuka kwa utendaji wa seva. Kukagua kumbukumbu za maombi yanayorudiwa kutoka kwa anwani moja ya IP au ukaguzi wa mlangoni kunaweza pia kuonyesha uwezekano wa shambulio la DDoS. Kuna hatua nyingi za ulinzi, lakini tutajadili tu mambo ya msingi.

Kutumia CDN (Mtandao wa Uwasilishaji wa Maudhui). CDN inaweza kutumika kama mpatanishi kati ya seva yako ya wavuti na watumiaji, kusambaza trafiki na maudhui ya akiba ili kupunguza athari za shambulio la DDoS. CDN pia zinaweza kuwa na mifumo ya ulinzi ya DDoS iliyojengewa ndani, ikijumuisha usambazaji wa mzigo na uchujaji wa trafiki.

Kusanidi ngome na mifumo ya kugundua uingiliaji (IDS/IPS). Firewalls zinaweza kusanidiwa ili kuchuja trafiki kulingana na vigezo mbalimbali, kama vile anwani za IP na bandari. IDS/IPS inaweza kugundua tabia isiyo ya kawaida ya trafiki na kuzuia miunganisho ya kutiliwa shaka. Zana hizi zinaweza kuwa na ufanisi katika kufuatilia na kuzuia trafiki inayoweza kuwa mbaya.

Inasanidi seva za wavuti za Apache na Nginx ili kupunguza athari za mashambulizi ya DDoS.

Kama suluhisho la Apache, tunawezesha faili ya mod_evasive moduli. Ili kufanya hivyo, toa maoni au ongeza laini ifuatayo kwenye faili ya httpd.conf or apache2.conf faili ya usanidi:

LoadModule evasive20_module modules/mod_evasive.so

Katika faili sawa, unahitaji kuongeza kizuizi cha mipangilio:

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

Vile vile, sisi kuamsha mod_ratelimit moduli:

LoadModule ratelimit_module modules/mod_ratelimit.so

Na ongeza usanidi:

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

Mpangilio wa Nginx ni sawa na Apache. Ndani ya nginx.conf faili ya usanidi, maagizo yafuatayo yanahitajika kutumika:

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;

        ...
    }
}

Baada ya kufanya mabadiliko kwa kila huduma, zinahitaji kupakiwa tena:

sudo systemctl restart apache2

Au:

sudo systemctl restart nginx

Mifano hizi hutoa usanidi wa msingi tu, ambao unaweza kubadilishwa zaidi kulingana na mahitaji maalum na hali ya mashambulizi.

Kuboresha Maswali ya MySQL

Kuboresha maswali ya hifadhidata ya MySQL kwenye seva ya wavuti kunaweza kupatikana kwa njia mbalimbali, na mojawapo ni usanidi sahihi wa faili ya usanidi. Kwa kawaida, faili hii inaitwa yangu.cnf or yangu.ini na iko katika /na kadhalika/ or /etc/mysql/ saraka. Unahitaji kuifungua na kufanya mabadiliko yafuatayo:

[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

Wacha pia tuzingatie mapendekezo ya ziada ambayo yanaweza kuwezesha mwingiliano na hifadhidata ya seva:

1. Kutumia Fafanua amri kabla ya swala la SQL kuchambua utekelezaji wake. Hii hukuruhusu kupata mpango wa utekelezaji wa swala na kuamua ni faharisi gani zinazotumiwa, ni meza gani zimechanganuliwa, nk.
2. Faharasa huharakisha utafutaji wa data, kwa hivyo faharasa zilizoundwa ipasavyo zinaweza kuboresha utendaji wa hoja kwa kiasi kikubwa. Zingatia safu wima ambazo hutumiwa mara kwa mara katika WAPI or JOIN masharti.
3. Epuka kutumia SELECT *. Bainisha tu safu wima ambazo ni muhimu sana kwa hoja yako, badala ya kuchagua safu wima zote kwenye jedwali.
4. Epuka kutumia vipengele katika WAPI masharti. Kutumia vitendaji (kama vile LOWER, UPPER, LEFT, HAKI) WAPI masharti yanaweza kufanya faharisi kutokuwa na maana. Jaribu kuepuka matumizi yao ya moja kwa moja katika hali.
5. Kutumia INNER JOIN inapowezekana, kwani kwa kawaida huwa na ufanisi zaidi. Pia, hakikisha kuwa safu wima zinazolingana za kujiunga zina faharasa.
6. Kutumia LIMIT ili kuzuia idadi ya safu mlalo zilizorejeshwa ikiwa unahitaji kupata idadi fulani tu ya matokeo.
7. Zingatia matokeo ya hoja ya akiba, haswa ikiwa hubadilika mara chache sana, ili kupunguza upakiaji wa seva.

Seva ya Barua Inaunda Mzigo wa Juu kwenye Seva

Katika sehemu hii, tutachunguza jinsi ya kuamua kuwa seva ya barua inakabiliwa na mzigo mkubwa na ni hatua gani zinaweza kuchukuliwa ili kuboresha uendeshaji wake, ikiwa ni pamoja na kuangalia foleni ya ujumbe na kusanidi vigezo vya seva. Anza kwa kuangalia foleni ya ujumbe. The barua pepe matumizi inaweza kusaidia na hii, ili kuiwasha, ingiza amri inayolingana kwenye terminal:

mailq

Hii itaonyesha orodha ya ujumbe kwenye foleni, ikiwa ipo. Kila ujumbe utaonyeshwa na kitambulisho chake cha kipekee na taarifa kuhusu hali ya kutuma. Matokeo sawa yanaweza kupatikana kwa kukagua kumbukumbu za mteja wa barua.

Mara nyingi, mzigo mkubwa hutokea katika tukio la maelewano ya seva wakati inapoanza kutuma barua taka. Walakini, ikiwa baada ya kuangalia msimamizi ana uhakika kuwa seva haijashambuliwa kutoka nje na watumiaji hawapuuzi barua taka, ni wakati wa kuendelea na uboreshaji wa seva ya barua. Hapa kuna hatua ambazo zitasaidia:

1. Hakikisha kuwa rekodi za DNS za kikoa chako zimesanidiwa ipasavyo, ikijumuisha SPF, DKIM, na DMARC rekodi ili kuboresha uwasilishaji wa barua na kulinda dhidi ya barua taka. Configuration sahihi ya vigezo inaweza kupatikana katika makala juu uchunguzi wa seva ya barua.
2. Angalia mipangilio ya mtandao, ikiwa ni pamoja na usanidi wa ngome na sheria za uelekezaji, ili kuepuka vizuizi na kuharakisha uwasilishaji wa barua.
3. Sanidi vigezo vya foleni ya ujumbe kulingana na mzigo wa seva. Hii inaweza kujumuisha kuweka ukubwa wa juu zaidi wa foleni na muda wa kuisha.
4. Fikiria masuluhisho tuliyojadili katika makala hii hapo awali. Boresha hifadhidata ya seva ya barua mara kwa mara ili kuboresha utendakazi, tumia mbinu za kuweka akiba ili kuharakisha utafutaji na uchakataji wa data, kama vile hoja za DNS.
5. Ikiwa seva ya barua bado inapata upakiaji wa juu mara kwa mara, zingatia chaguo za kuongeza ukubwa, kama vile kutumia kundi la seva za barua au suluhu za wingu.

Hitimisho

Kuongezeka kwa mzigo wa seva huathiri moja kwa moja kasi ya upakiaji wa tovuti, hatimaye kuathiri uzoefu wa mtumiaji na sifa katika injini za utafutaji. Kwa hivyo, kusimamia mzigo huu kwa ufanisi kuna jukumu muhimu katika kuhakikisha utendakazi endelevu wa rasilimali na kuongeza ufikiaji wake kwa wageni.