Knowledgebase Parentah basajan pikeun digawe sareng jasa Profitserver
utama Knowledgebase Ngurangan beban server

Ngurangan beban server


Dina artikel ieu, urang bakal delve kana naha ngaronjat beban server lumangsung sarta ngabahas sagala rupa cara pikeun ngaoptimalkeun prosés-beban tinggi. Perhatian khusus bakal dipasihan ka optimasi kode dina Apache / Nginx sareng MySQL, urang bakal ngobrol ngeunaan cache salaku alat bantu, sareng ogé mertimbangkeun kamungkinan ancaman éksternal, sapertos serangan DDOS, sareng cara pikeun nyegahna.

Naha Server beban lumangsung

Sateuacan neraskeun kana optimasi server, perlu pikeun ngalaksanakeun analisa lengkep ngeunaan beban ayeuna dina sumber. Ieu kalebet ngukur beban CPU, pamakean RAM, kagiatan jaringan, sareng parameter konci anu sanés. Ngartos dinamika sareng beban puncak ngamungkinkeun ngidentipikasi bottlenecks sareng ngaoptimalkeun alokasi sumberdaya, sahingga ningkatkeun stabilitas sareng kinerja infrastruktur server.

Pikeun ngungkulan masalah awal beban server anu luhur, kami nyarankeun pikeun ngalaksanakeun diagnostik server umum . Upami ieu teu cekap, analisis sumber daya anu langkung rinci diperyogikeun. Salaku alat bantu, ngajalajah log server Linux tiasa ngabantosan, sabab di dieu sumber masalahna kapanggih dina kalolobaan kasus.

Ngaoptimalkeun Apache / Nginx Server

Ngaronjat Beban Server Kusabab Indexing

Ngaronjat beban alatan indexing dina server bisa lumangsung, contona, nalika mesin pencari nyeken sajumlah badag kaca dina situs anjeun. Ieu bisa ngakibatkeun ngaronjat pamakéan sumberdaya server jeung, akibatna, ngalambatkeun kinerja situs urang. Identipikasi cukang lantaranana relatif basajan; Anjeun kedah muka file anu aya di:

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

Nalika diindeks ku mesin pencari, pangguna bakal ningali éntri sapertos kieu:

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

Salaku solusi munggaran pikeun ngirangan beban, anjeun tiasa nganggo setélan meta tag "noindex" sareng "nofollow" dina halaman anu henteu kedah diindeks. Solusi kadua nyaéta file .htaccess , dimana entri anu saluyu sareng mesin pencari khusus kedah ditambahkeun, contona, pikeun nyumput tina Yandex sareng Google:

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

Sarua kitu, éditan kedah dilakukeun pikeun mesin pencari anu sanés. Perlu dicatet yén kamampuan .htaccess henteu dugi ka ngan ukur meungpeuk indéks. Kami nyarankeun pikeun langkung kenal sareng fitur utama na dina tulisan éta.

Ngagunakeun Setélan Caching

Setélan caching anu salah dina server ogé tiasa nyababkeun beban anu luhur. Pikeun ngaoptimalkeun parameter ieu, parobihan anu saluyu kedah dilakukeun dina file konfigurasi atanapi .htaccess . Dina kasus Apache, pilihan anu terakhir langkung dipikaresep, pikeun Nginx - anu sateuacanna.

Dina server Apache , anjeun kedah muka file .htacess teras lebetkeun kode ieu:

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

Teras, aktipkeun modul Expires nganggo paréntah:

sudo a2enmod expires

Saatos éta, balikan deui pangladén wéb:

sudo service apache2 restart

Sareng aktipkeun modul ku netepkeun:

ExpiresActive On

Dina server Nginx , cekap nambihan kode ieu kana file konfigurasi:

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

Sareng laksanakeun ulang jasa:

sudo service nginx restart

Catet yén ku setélan ieu, paréntah Allow sareng Deny bakal dilewati.

Ngagunakeun Data Komprési

Ngaktipkeun komprési data nganggo Gzip dina server wéb Apache sareng Nginx ngabantosan ngirangan jumlah data anu dikirimkeun antara server sareng klien, anu ningkatkeun kinerja sareng ngirangan waktos muka halaman wéb.

Pikeun ngaktipkeun Gzip dina Apache , anjeun kedah ngaktipkeun modul mod_deflate :

sudo a2enmod deflate

Teras, balikan deui pangladén wéb:

sudo service apache2 restart

Tungtungna, tambahkeun blok di handap ieu kana file konfigurasi atanapi .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>

Konfigurasi ieu ngamungkinkeun komprési pikeun sababaraha jinis file sareng nganonaktipkeun pikeun gambar.

Dina kasus Nginx , konfigurasi lumangsung dina blok http tina file konfigurasi. Kode ieu kedah ditambahkeun:

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;

Sarupa sareng Apache , di dieu parameter komprési pikeun jinis file anu tangtu disetel. Saatos ngadamel parobihan kana server wéb naon waé, peryogi ngamuat ulang layanan:

sudo service apache2 restart

Or

sudo service nginx restart

Serangan DDOS dina Server

beban server tinggi bisa lumangsung salaku hasil tina serangan DDoS. Ngidentipikasi ayana serangan DDoS tiasa dilakukeun ku ngawas kanaékan lalu lintas anu ngadadak, paménta anu teu normal, sareng turunna kinerja server. Reviewing log pikeun requests ulang ti hiji alamat IP atawa port scanning ogé bisa nunjukkeun kamungkinan serangan DDoS. Aya seueur ukuran panyalindungan, tapi urang ngan ukur ngabahas dasarna.

Ngagunakeun CDN (Content Delivery Network) . CDN tiasa janten perantara antara server wéb anjeun sareng pangguna, nyebarkeun lalu lintas sareng nyimpen eusi dina caching pikeun ngirangan dampak serangan DDoS. CDN ogé tiasa gaduh mékanisme panyalindungan DDoS bawaan, kalebet distribusi beban sareng panyaringan lalu lintas.

Ngonpigurasikeun firewall sareng sistem deteksi intrusi (IDS/IPS) . Firewall tiasa dikonfigurasi pikeun nyaring lalu lintas dumasar kana rupa-rupa kriteria, sapertos alamat IP sareng port. IDS/IPS tiasa ngadeteksi paripolah lalu lintas anu teu normal sareng meungpeuk sambungan anu curiga. Alat-alat ieu tiasa efektif dina ngalacak sareng meungpeuk lalu lintas anu berpotensi jahat.

Ngonpigurasikeun pangladén wéb Apache sareng Nginx pikeun ngirangan dampak serangan DDoS.

Salaku solusi pikeun Apache, urang ngaktipkeun modul mod_evasive . Pikeun ngalakukeun ieu, hapus koméntar atanapi tambahkeun baris ieu dina file konfigurasi httpd.conf atanapi apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

Dina file anu sami, anjeun kedah nambihan blok setelan:

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

Sarua kitu, urang ngaktipkeun modul mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

Sareng tambahkeun konfigurasi:

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

Konfigurasi pikeun Nginx sami sareng Apache . Dina file konfigurasi nginx.conf , diréktif ieu kedah dianggo:

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;

        ...
    }
}

Saatos ngadamel parobihan kana unggal jasa, aranjeunna kedah dimuat deui:

sudo systemctl restart apache2

atawa:

sudo systemctl restart nginx

Conto ieu ngan nyadiakeun konfigurasi dasar, nu bisa salajengna diadaptasi gumantung kana sarat husus sarta sipat serangan.

Ngaoptimalkeun MySQL Query

Ngaoptimalkeun pamundut database MySQL dina server wéb tiasa dilakukeun ku sababaraha cara, salah sahijina nyaéta konfigurasi file konfigurasi anu leres. Biasana, file ieu dingaranan my.cnf atanapi my.ini sareng ayana dina diréktori /etc/ atanapi /etc/mysql/ . Anjeun kedah muka éta sareng ngadamel parobihan ieu:

[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

Hayu urang ogé mertimbangkeun saran tambahan nu bisa mempermudah interaksi jeung database server:

  1. nganggo Ngadeg paréntah sateuacan query SQL pikeun nganalisis palaksanaan na. Ieu ngamungkinkeun anjeun kéngingkeun rencana palaksanaan pikeun pamundut sareng nangtoskeun indéks mana anu dianggo, tabel mana anu discan, jsb.
  2. Indéks nyepetkeun pamilarian data, ku kituna indéks anu dirarancang leres tiasa ningkatkeun kinerja query sacara signifikan. Nengetan kolom anu sering dianggo dina WHERE or gabung kaayaan.
  3. Hindarkeun nganggo PILIH *. Sebutkeun ukur kolom anu leres-leres dipikabutuh pikeun pamundut anjeun, tibatan milih sadaya kolom dina méja.
  4. Hindarkeun ngagunakeun fungsi dina WHERE kaayaan. Ngagunakeun fungsi (sapertos LEUWIH, luhur, ditinggalkeun, bener) di WHERE kaayaan bisa nyieun indexes gunana. Coba ulah pamakéan langsung maranéhanana dina kondisi.
  5. make Jero gabung mana mungkin, sabab biasana leuwih efisien. Ogé, pastikeun yén kolom pakait pikeun gabung boga indéks.
  6. make Watesan pikeun ngawatesan jumlah baris balik lamun kudu meunang ngan sababaraha hasil.
  7. Mertimbangkeun cache hasil query, utamana lamun aranjeunna jarang robah, pikeun ngurangan beban server.

Server Surat Nyiptakeun Beban Tinggi dina Server

Dina bagian ieu, urang bakal nalungtik kumaha nangtukeun yén server surélék ngalaman beban anu luhur sareng léngkah-léngkah naon anu tiasa dilaksanakeun pikeun ngaoptimalkeun operasina, kalebet mariksa antrian pesen sareng ngonpigurasikeun parameter server. Mimitian ku mariksa antrian pesen. Utilitas mailq tiasa ngabantosan ieu, pikeun ngaktipkeunana, lebetkeun paréntah anu saluyu dina terminal:

mailq

Ieu bakal ningalikeun daptar pesen dina antrian, upami aya. Tiap pesen bakal dipintonkeun kalawan identifier unik sarta informasi ngeunaan status ngirim. Hasil anu sami tiasa dicandak ku marios log klien surat.

Dina kalolobaan kasus, beban tinggi lumangsung dina acara kompromi server nalika dimimitian ngirim spam. Nanging, upami saatos mariksa administrator yakin yén server henteu diserang ti luar sareng pangguna henteu ngalalaworakeun spam, éta waktuna pikeun ngaoptimalkeun pangladén surat. Ieu léngkah-léngkah anu bakal ngabantosan:

  1. Pastikeun yén rékaman DNS domain anjeun dikonpigurasi leres, kalebet SPF, DKIM, sarta DMARC rékaman pikeun ngaronjatkeun pangiriman mail jeung ngajaga ngalawan spam. Konfigurasi parameter anu leres tiasa dipendakan dina tulisan dina diagnostics mail server.
  2. Pariksa setelan jaringan, kaasup konfigurasi firewall jeung aturan routing, pikeun nyegah blok jeung nyepetkeun pangiriman surat.
  3. Konpigurasikeun parameter antrian pesen nurutkeun beban server. Ieu tiasa kalebet netepkeun ukuran antrian maksimum sareng waktosna.
  4. Pertimbangkeun solusi anu kami bahas dina tulisan ieu sateuacana. Périodik ngaoptimalkeun database server mail pikeun ngaronjatkeun kinerja, make mékanisme cache pikeun nyepetkeun pilarian data jeung ngolah, kayaning queries DNS.
  5. Upami pangladén surat masih rutin ngalaman beban anu luhur, pertimbangkeun pilihan skala, sapertos nganggo gugusan pangladén surat atanapi solusi awan.

kacindekan

Ngaronjatkeun beban server langsung mangaruhan kagancangan loading halaman wéb, pamustunganana mangaruhan pangalaman pangguna sareng reputasi dina mesin pencari. Ku kituna, éféktif ngatur beban ieu muterkeun hiji peran konci dina mastikeun fungsionalitas kontinyu sumberdaya sarta ngaronjatkeun aksés ka sémah.

❮ Artikel saméméhna Certbot: Pasang Let's Encrypt Certificate
Artikel salajengna ❯ Diagnostics beban server

Tanya kami ngeunaan VPS

Kami salawasna siap ngajawab patarosan anjeun iraha wae beurang atawa peuting.