Mengurangkan beban pelayan

Dalam artikel ini, kami akan menyelidiki sebab peningkatan beban pelayan berlaku dan membincangkan pelbagai cara untuk mengoptimumkan proses beban tinggi. Perhatian khusus akan diberikan kepada pengoptimuman kod dalam Apache/Nginx dan MySQL, kita akan bercakap tentang caching sebagai alat tambahan, dan juga mempertimbangkan kemungkinan ancaman luaran, seperti serangan DDOS, dan cara untuk menghalangnya.

Mengapa Pelayan Muatan Berlaku

Sebelum meneruskan ke pengoptimuman pelayan, adalah perlu untuk menjalankan analisis menyeluruh terhadap beban semasa pada sumber. Ini termasuk mengukur beban CPU, penggunaan RAM, aktiviti rangkaian dan parameter utama lain. Memahami dinamik dan beban puncak membolehkan mengenal pasti kesesakan dan mengoptimumkan peruntukan sumber, sekali gus meningkatkan kestabilan dan prestasi infrastruktur pelayan.

Untuk penyelesaian masalah awal beban pelayan yang tinggi, kami mengesyorkan anda menjalankan a diagnostik pelayan umum. Jika ini tidak mencukupi, lebih terperinci analisis sumber adalah perlu. Sebagai alat bantu, meneroka log Linux pelayan boleh membantu, kerana di sinilah sumber masalah ditemui dalam kebanyakan kes.

Mengoptimumkan Pelayan Apache/Nginx

Peningkatan Pelayan Kerana Pengindeksan

Peningkatan beban disebabkan pengindeksan pada pelayan boleh berlaku, sebagai contoh, apabila enjin carian mengimbas sejumlah besar halaman di tapak anda. Ini boleh membawa kepada peningkatan penggunaan sumber pelayan dan, akibatnya, memperlahankan prestasi tapak. Mengenal pasti punca adalah agak mudah; anda perlu membuka fail yang terletak di:

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

Apabila diindeks oleh enjin carian, pengguna akan melihat entri seperti berikut:

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

Sebagai penyelesaian pertama untuk mengurangkan beban, anda boleh menggunakan tetapan tag meta "noindex" and "nofollow" pada halaman yang tidak perlu diindeks. Penyelesaian kedua ialah . Htaccess fail, di mana entri yang sepadan dengan enjin carian tertentu perlu ditambah, sebagai contoh, untuk menyembunyikan daripada Yandex dan Google:

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

Begitu juga, suntingan perlu dibuat untuk enjin carian lain. Perlu diingatkan bahawa keupayaan .htaccess tidak terhad kepada hanya menyekat pengindeksan. Kami mengesyorkan agar anda lebih mengenali ciri utamanya dalam artikel.

Menggunakan Tetapan Caching

Tetapan caching yang salah pada pelayan juga boleh membawa kepada beban yang tinggi. Untuk mengoptimumkan parameter ini, perubahan yang sepadan perlu dibuat dalam fail konfigurasi atau . Htaccess. Dalam kes Apache, pilihan terakhir adalah lebih baik, untuk Nginx - yang pertama.

Pada suatu Apache pelayan, anda perlu membuka .htacess fail dan masukkan kod berikut:

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

Kemudian, dayakan tamat tempoh modul menggunakan arahan:

sudo a2enmod expires

Selepas itu, mulakan semula pelayan web:

sudo service apache2 restart

Dan aktifkan modul dengan menyatakan:

ExpiresActive On

Pada Nginx pelayan, adalah memadai untuk menambah kod berikut pada fail konfigurasi:

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

Dan lakukan muat semula perkhidmatan:

sudo service nginx restart

Ambil perhatian bahawa dengan tetapan ini, Benarkan and Deny arahan akan dipintas.

Menggunakan Pemampatan Data

Mendayakan pemampatan data menggunakan Gzip pada pelayan web Apache dan Nginx membantu mengurangkan jumlah data yang dihantar antara pelayan dan klien, yang meningkatkan prestasi dan mengurangkan masa memuatkan halaman web.

Bagi membolehkan Gzip on Apache, anda perlu mengaktifkan mod_deflate modul:

sudo a2enmod deflate

Kemudian, mulakan semula pelayan web:

sudo service apache2 restart

Dan akhirnya, tambahkan blok berikut pada fail konfigurasi atau .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 ini membolehkan pemampatan untuk jenis fail tertentu dan melumpuhkannya untuk imej.

Dalam kes Nginx, konfigurasi berlaku dalam http blok fail konfigurasi. Kod berikut perlu ditambah:

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;

Sama seperti Apache, di sini parameter mampatan untuk jenis fail tertentu ditetapkan. Selepas membuat perubahan pada mana-mana pelayan web, muat semula perkhidmatan diperlukan:

sudo service apache2 restart

Or

sudo service nginx restart

Serangan DDOS pada Pelayan

Beban pelayan yang tinggi boleh berlaku akibat serangan DDoS. Mengenal pasti kehadiran serangan DDoS boleh dilakukan melalui pemantauan peningkatan mendadak dalam trafik, permintaan yang tidak normal dan penurunan prestasi pelayan. Menyemak log untuk permintaan berulang daripada satu alamat IP atau pengimbasan port juga boleh menunjukkan kemungkinan serangan DDoS. Terdapat banyak langkah perlindungan, tetapi kita hanya akan membincangkan perkara asas.

Menggunakan CDN (Rangkaian Penghantaran Kandungan). CDN boleh berfungsi sebagai perantara antara pelayan web anda dan pengguna, mengedarkan trafik dan kandungan caching untuk mengurangkan kesan serangan DDoS. CDN juga boleh mempunyai mekanisme perlindungan DDoS terbina dalam, termasuk pengagihan beban dan penapisan trafik.

Mengkonfigurasi tembok api dan sistem pengesanan pencerobohan (IDS/IPS). Firewall boleh dikonfigurasikan untuk menapis trafik berdasarkan pelbagai kriteria, seperti alamat IP dan port. IDS/IPS boleh mengesan tingkah laku trafik yang tidak normal dan menyekat sambungan yang mencurigakan. Alat ini boleh berkesan dalam menjejak dan menyekat trafik yang berpotensi berniat jahat.

Mengkonfigurasi pelayan web Apache dan Nginx untuk mengurangkan kesan serangan DDoS.

Sebagai penyelesaian untuk Apache, kami membolehkan mod_evasive modul. Untuk melakukan ini, nyahkomen atau tambah baris berikut dalam httpd.conf or apache2.conf fail konfigurasi:

LoadModule evasive20_module modules/mod_evasive.so

Dalam fail yang sama, anda perlu menambah blok tetapan:

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

Begitu juga, kami mengaktifkan mod_ratelimit modul:

LoadModule ratelimit_module modules/mod_ratelimit.so

Dan tambah 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 untuk Nginx adalah sama dengan Apache. Di dalam nginx.conf fail konfigurasi, arahan berikut perlu digunakan:

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;

        ...
    }
}

Selepas membuat perubahan pada setiap perkhidmatan, perkhidmatan tersebut perlu dimuat semula:

sudo systemctl restart apache2

atau:

sudo systemctl restart nginx

Contoh-contoh ini hanya menyediakan konfigurasi asas, yang boleh disesuaikan lagi bergantung pada keperluan khusus dan sifat serangan.

Mengoptimumkan Pertanyaan MySQL

Mengoptimumkan pertanyaan pangkalan data MySQL pada pelayan web boleh dicapai dalam pelbagai cara, dan salah satunya ialah konfigurasi fail konfigurasi yang betul. Biasanya, fail ini dinamakan my.cnf or my.ini dan terletak di /dan lain-lain/ or /etc/mysql/ direktori. Anda perlu membukanya dan membuat perubahan berikut:

[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

Mari kita pertimbangkan juga cadangan tambahan yang boleh memudahkan interaksi dengan pangkalan data pelayan:

1. Menggunakan JELASKAN arahan sebelum pertanyaan SQL untuk menganalisis pelaksanaannya. Ini membolehkan anda mendapatkan pelan pelaksanaan untuk pertanyaan dan menentukan indeks yang digunakan, jadual yang diimbas, dsb.
2. Indeks mempercepatkan carian data, jadi indeks yang direka dengan betul boleh meningkatkan prestasi pertanyaan dengan ketara. Beri perhatian kepada lajur yang kerap digunakan dalam DIMANA or JOIN syarat.
3. Elakkan menggunakan PILIH *. Tentukan hanya lajur yang benar-benar diperlukan untuk pertanyaan anda, bukannya memilih semua lajur dalam jadual.
4. Elakkan menggunakan fungsi dalam DIMANA syarat. Menggunakan fungsi (seperti RENDAH, UPPER, KIRI, HAK) dalam DIMANA keadaan boleh menjadikan indeks tidak berguna. Cuba elakkan penggunaan langsung mereka dalam keadaan.
5. Penggunaan INNER JOIN jika boleh, kerana ia biasanya lebih cekap. Juga, pastikan bahawa lajur yang sepadan untuk menyertai mempunyai indeks.
6. Penggunaan HAD untuk mengehadkan bilangan baris yang dikembalikan jika anda hanya perlu mendapatkan bilangan hasil tertentu.
7. Pertimbangkan caching hasil pertanyaan, terutamanya jika mereka jarang berubah, untuk mengurangkan beban pelayan.

Pelayan Mel Mencipta Muatan Tinggi pada Pelayan

Dalam bahagian ini, kami akan meneroka cara untuk menentukan bahawa pelayan mel mengalami beban yang tinggi dan langkah yang boleh diambil untuk mengoptimumkan operasinya, termasuk menyemak baris gilir mesej dan mengkonfigurasi parameter pelayan. Mulakan dengan menyemak baris gilir mesej. The mailq utiliti boleh membantu dengan ini, untuk mengaktifkannya, masukkan arahan yang sepadan dalam terminal:

mailq

Ini akan memaparkan senarai mesej dalam baris gilir, jika ada. Setiap mesej akan dipaparkan dengan pengecam unik dan maklumat tentang status penghantaran. Keputusan yang serupa boleh diperolehi dengan menyemak log klien mel.

Dalam kebanyakan kes, beban tinggi berlaku sekiranya pelayan berkompromi apabila ia mula menghantar spam. Walau bagaimanapun, jika selepas menyemak pentadbir yakin bahawa pelayan tidak diserang dari luar dan pengguna tidak mengabaikan spam, sudah tiba masanya untuk beralih kepada mengoptimumkan pelayan mel. Berikut adalah langkah-langkah yang akan membantu:

1. Pastikan rekod DNS domain anda dikonfigurasikan dengan betul, termasuk SPF, DKIM, dan DMARC rekod untuk meningkatkan penghantaran mel dan melindungi daripada spam. Konfigurasi parameter yang betul boleh didapati dalam artikel tentang diagnostik pelayan mel.
2. Semak tetapan rangkaian, termasuk konfigurasi tembok api dan peraturan penghalaan, untuk mengelakkan sekatan dan mempercepatkan penghantaran mel.
3. Konfigurasikan parameter baris gilir mesej mengikut beban pelayan. Ini mungkin termasuk menetapkan saiz baris gilir maksimum dan tamat masa.
4. Pertimbangkan penyelesaian yang kami bincangkan dalam artikel ini sebelum ini. Optimumkan pangkalan data pelayan mel secara berkala untuk meningkatkan prestasi, gunakan mekanisme caching untuk mempercepatkan carian dan pemprosesan data, seperti pertanyaan DNS.
5. Jika pelayan mel masih kerap menghadapi beban tinggi, pertimbangkan pilihan penskalaan, seperti menggunakan kluster pelayan mel atau penyelesaian awan.

Kesimpulan

Peningkatan beban pelayan secara langsung mempengaruhi kelajuan pemuatan tapak web, akhirnya memberi kesan kepada pengalaman dan reputasi pengguna dalam enjin carian. Oleh itu, mengurus beban ini dengan berkesan memainkan peranan penting dalam memastikan kefungsian sumber yang berterusan dan meningkatkan kebolehcapaiannya untuk pelawat.