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 ajili ya utatuzi wa awali wa mzigo mkubwa wa seva, tunapendekeza kufanya uchunguzi wa jumla wa seva . Ikiwa hii haitoshi, uchambuzi wa kina zaidi wa rasilimali ni muhimu. Kama zana saidizi, kuchunguza kumbukumbu za seva ya Linux kunaweza kusaidia, kwani hapa ndipo chanzo cha tatizo kinapatikana katika visa vingi.

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 mipangilio ya meta tagi "noindex" na "nofollow" kwenye kurasa ambazo hazihitaji kuorodheshwa. Suluhisho la pili ni faili ya .htaccess , ambapo maingizo yanayolingana na injini maalum za utafutaji yanahitaji kuongezwa, kwa mfano, ili 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, marekebisho yanahitaji kufanywa kwa injini zingine za utafutaji. Ikumbukwe kwamba uwezo wa .htaccess hauzuiliwi tu kuzuia uorodheshaji. Tunapendekeza ujue zaidi vipengele vyake vikuu katika makala.

Kutumia Mipangilio ya Uhifadhi

Mipangilio isiyo sahihi ya kuhifadhi data kwenye seva inaweza pia kusababisha mzigo mkubwa. Ili kuboresha kigezo hiki, mabadiliko yanayolingana yanahitaji kufanywa katika faili za usanidi au .htaccess . Katika kesi ya Apache, chaguo la mwisho ni bora zaidi, kwa Nginx - la kwanza.

Kwenye seva ya Apache , unahitaji kufungua faili ya .htacess na kuingiza msimbo ufuatao:

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

Kisha, wezesha moduli ya Expires 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

Kwenye seva ya Nginx , inatosha kuongeza msimbo ufuatao 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 kwamba kwa mipangilio hii, maagizo ya Ruhusu na Kataa yatapuuzwa.

Kutumia Ukandamizaji wa Data

Kuwezesha kubana data kwa kutumia Gzip kwenye seva za wavuti za Apache na Nginx husaidia kupunguza kiasi cha data kinachosambazwa kati ya seva na mteja, jambo ambalo huboresha utendaji na hupunguza muda wa kupakia kurasa za wavuti.

Ili kuwezesha Gzip kwenye Apache , unahitaji kuamilisha moduli ya mod_deflate :

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 kizuizi cha http cha faili ya usanidi. Msimbo ufuatao unahitaji 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 kubana kwa aina fulani za faili vimewekwa. Baada ya kufanya mabadiliko kwenye 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, ikisambaza trafiki na kuhifadhi maudhui ili kupunguza athari za shambulio la DDoS. CDN zinaweza pia kuwa na mifumo ya ulinzi ya DDoS iliyojengewa ndani, ikiwa ni pamoja na usambazaji wa mzigo na uchujaji wa trafiki.

Kusanidi ngome na mifumo ya kugundua uvamizi (IDS/IPS) . Ngome zinaweza kusanidiwa kuchuja trafiki kulingana na vigezo mbalimbali, kama vile anwani za IP na milango. IDS/IPS inaweza kugundua tabia isiyo ya kawaida ya trafiki na kuzuia miunganisho inayotiliwa shaka. Zana hizi zinaweza kuwa na ufanisi katika kufuatilia na kuzuia trafiki inayoweza kuwa na madhara.

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

Kama suluhisho la Apache, tunawezesha moduli ya mod_evasive . Ili kufanya hivi, ondoa maoni au ongeza mstari ufuatao katika faili ya usanidi ya httpd.conf au apache2.conf :

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, tunawasha moduli ya mod_ratelimit :

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>

Usanidi wa Nginx unafanana na Apache . Katika faili ya usanidi wa nginx.conf , maagizo yafuatayo yanahitaji 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 hoja za 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 huitwa my.cnf au my.ini na iko katika saraka ya /etc/ au /etc/mysql/ . 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 kubaini kuwa seva ya barua pepe inapitia mzigo mkubwa na ni hatua gani zinaweza kuchukuliwa ili kuboresha utendaji wake, ikiwa ni pamoja na kuangalia foleni ya ujumbe na kusanidi vigezo vya seva. Anza kwa kuangalia foleni ya ujumbe. Huduma ya mailq inaweza kusaidia na hili, ili kuiwasha, ingiza amri inayolingana katika 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.