Zmniejszanie obciążenia serwera

W tym artykule zagłębimy się w to, dlaczego występuje zwiększone obciążenie serwera i omówimy różne sposoby optymalizacji procesów o dużym obciążeniu. Szczególną uwagę poświęcimy optymalizacji kodu w Apache/Nginx i MySQL, porozmawiamy o buforowaniu jako narzędziu pomocniczym, a także rozważymy możliwe zagrożenia zewnętrzne, takie jak ataki DDOS, i sposoby ich zapobiegania.

Dlaczego występuje obciążenie serwera

Przed przystąpieniem do optymalizacji serwera konieczne jest przeprowadzenie dokładnej analizy bieżącego obciążenia zasobów. Obejmuje to pomiar obciążenia procesora, użycia pamięci RAM, aktywności sieciowej i innych kluczowych parametrów. Zrozumienie dynamiki i obciążeń szczytowych pozwala na identyfikację wąskich gardeł i optymalizację alokacji zasobów, zwiększając w ten sposób stabilność i wydajność infrastruktury serwera.

W celu wstępnego rozwiązania problemu dużego obciążenia serwera zalecamy przeprowadzenie ogólnej diagnostyki serwera . Jeśli to okaże się niewystarczające, konieczna będzie bardziej szczegółowa analiza zasobów . Pomocne może okazać się również sprawdzenie logów serwera Linux , ponieważ to właśnie tam w większości przypadków znajduje się źródło problemu.

Optymalizacja serwera Apache/Nginx

Zwiększone obciążenie serwera z powodu indeksowania

Zwiększone obciążenie spowodowane indeksowaniem na serwerze może wystąpić na przykład, gdy wyszukiwarki skanują dużą liczbę stron w witrynie. Może to prowadzić do zwiększonego wykorzystania zasobów serwera, a w konsekwencji spowolnienia działania witryny. Zidentyfikowanie przyczyny jest stosunkowo proste; należy otworzyć plik znajdujący się w:

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

Po zindeksowaniu przez wyszukiwarki użytkownik zobaczy wpisy o następującym charakterze:

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

Pierwszym rozwiązaniem, które pozwoli zmniejszyć obciążenie, jest ustawienie metatagów „noindex” i „nofollow” na stronach, które nie wymagają indeksowania. Drugim rozwiązaniem jest plik .htaccess , do którego należy dodać wpisy odpowiadające konkretnym wyszukiwarkom, na przykład w celu ukrycia ich przed Yandexem i Google:

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

Podobnie, konieczne są zmiany w przypadku innych wyszukiwarek. Należy pamiętać, że możliwości pliku .htaccess nie ograniczają się tylko do blokowania indeksowania. Zalecamy zapoznanie się z jego głównymi funkcjami w tym artykule.

Korzystanie z ustawień buforowania

Nieprawidłowe ustawienia buforowania na serwerze mogą również prowadzić do dużego obciążenia. Aby zoptymalizować ten parametr, należy wprowadzić odpowiednie zmiany w plikach konfiguracyjnych lub .htaccess . W przypadku Apache’a preferowana jest ta druga opcja, w przypadku Nginx – ta pierwsza.

Na serwerze Apache należy otworzyć plik .htacess i wstawić następujący kod:

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

Następnie włącz moduł Expires za pomocą polecenia:

sudo a2enmod expires

Następnie należy ponownie uruchomić serwer WWW:

sudo service apache2 restart

Następnie aktywuj moduł poprzez podanie następujących informacji:

ExpiresActive On

Na serwerze Nginx wystarczy dodać następujący kod do pliku konfiguracyjnego:

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

I wykonaj ponowne załadowanie usługi:

sudo service nginx restart

Należy pamiętać, że przy tych ustawieniach dyrektywy Allow i Deny zostaną pominięte.

Korzystanie z kompresji danych

Włączenie kompresji danych za pomocą Gzip na serwerach internetowych Apache i Nginx pomaga zmniejszyć ilość danych przesyłanych pomiędzy serwerem i klientem, co poprawia wydajność i skraca czas ładowania stron internetowych.

Aby włączyć Gzip na serwerze Apache , należy aktywować moduł mod_deflate :

sudo a2enmod deflate

Następnie uruchom ponownie serwer WWW:

sudo service apache2 restart

Na koniec dodaj poniższy blok do pliku konfiguracyjnego lub .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>

Ta konfiguracja włącza kompresję dla niektórych typów plików i wyłącza ją dla obrazów.

W przypadku Nginx konfiguracja odbywa się w bloku http pliku konfiguracyjnego. Należy dodać następujący kod:

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;

Podobnie jak w Apache , tutaj ustawiane są parametry kompresji dla określonych typów plików. Po wprowadzeniu zmian na dowolnym serwerze WWW wymagane jest ponowne załadowanie usługi:

sudo service apache2 restart

Or

sudo service nginx restart

Atak DDOS na serwer

Wysokie obciążenie serwera może wystąpić w wyniku ataku DDoS. Identyfikacja obecności ataku DDoS może zostać przeprowadzona poprzez monitorowanie nagłego wzrostu ruchu, nietypowych żądań i spadków wydajności serwera. Przeglądanie dzienników pod kątem powtarzających się żądań z jednego adresu IP lub skanowanie portów może również wskazywać na możliwy atak DDoS. Istnieje wiele środków ochrony, ale omówimy tylko podstawowe.

Korzystanie z CDN (sieci dostarczania treści) . CDN może służyć jako pośrednik między serwerem internetowym a użytkownikami, dystrybuując ruch i buforując zawartość, aby złagodzić skutki ataku DDoS. Sieci CDN mogą również posiadać wbudowane mechanizmy ochrony przed atakami DDoS, w tym dystrybucję obciążenia i filtrowanie ruchu.

Konfigurowanie zapór sieciowych i systemów wykrywania włamań (IDS/IPS) . Zapory sieciowe można skonfigurować tak, aby filtrowały ruch na podstawie różnych kryteriów, takich jak adresy IP i porty. Systemy IDS/IPS wykrywają nietypowe zachowania w ruchu i blokują podejrzane połączenia. Narzędzia te mogą skutecznie śledzić i blokować potencjalnie złośliwy ruch.

Konfigurowanie serwerów internetowych Apache i Nginx w celu złagodzenia skutków ataków DDoS.

Rozwiązaniem dla Apache'a jest włączenie modułu mod_evasive . Aby to zrobić, usuń komentarz lub dodaj następujący wiersz w pliku konfiguracyjnym httpd.conf lub apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

W tym samym pliku należy dodać blok ustawień:

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

Podobnie aktywujemy moduł mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

I dodaj konfigurację:

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

Konfiguracja Nginx jest podobna do konfiguracji Apache . W pliku konfiguracyjnym nginx.conf należy użyć następujących dyrektyw:

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;

        ...
    }
}

Po wprowadzeniu zmian w każdej z usług konieczne jest ich ponowne załadowanie:

sudo systemctl restart apache2

Lub:

sudo systemctl restart nginx

Przedstawione przykłady przedstawiają jedynie podstawową konfigurację, którą można dostosować do konkretnych wymagań i charakteru ataków.

Optymalizacja zapytań MySQL

Optymalizację zapytań do bazy danych MySQL na serwerze WWW można osiągnąć na różne sposoby, a jednym z nich jest odpowiednia konfiguracja pliku konfiguracyjnego. Zazwyczaj plik ten nosi nazwę my.cnf lub my.ini i znajduje się w katalogu /etc/ lub /etc/mysql/ . Należy go otworzyć i wprowadzić następujące zmiany:

[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

Rozważmy również dodatkowe zalecenia, które mogą ułatwić interakcję z bazą danych serwera:

1. Użyj WYJAŚNIJ polecenie przed zapytaniem SQL w celu analizy jego wykonania. Pozwala to uzyskać plan wykonania zapytania i określić, które indeksy są używane, które tabele są skanowane itd.
2. Indeksy przyspieszają wyszukiwanie danych, więc odpowiednio zaprojektowane indeksy mogą znacznie poprawić wydajność zapytań. Zwróć uwagę na kolumny, które są często używane w WHERE or DOŁĄCZ warunki.
3. Unikaj używania WYBIERZ *. Określ tylko te kolumny, które są naprawdę niezbędne dla zapytania, zamiast wybierać wszystkie kolumny w tabeli.
4. Unikaj używania funkcji w WHERE warunki. Używanie funkcji (takich jak NIŻSZY, GÓRNY, LEWA, PRAWO) w WHERE warunki mogą sprawić, że indeksy staną się bezużyteczne. Staraj się unikać ich bezpośredniego użycia w warunkach.
5. Zastosowanie INNER JOIN gdzie to możliwe, ponieważ jest to zazwyczaj bardziej wydajne. Upewnij się również, że odpowiednie kolumny do łączenia mają indeksy.
6. Zastosowanie LIMIT aby ograniczyć liczbę zwracanych wierszy, jeśli potrzebujesz uzyskać tylko określoną liczbę wyników.
7. Rozważ buforowanie wyników zapytań, zwłaszcza jeśli rzadko ulegają zmianom, aby zmniejszyć obciążenie serwera.

Serwer pocztowy powoduje duże obciążenie serwera

W tej sekcji dowiesz się, jak rozpoznać, że serwer pocztowy jest obciążony i jakie kroki można podjąć, aby zoptymalizować jego działanie, w tym sprawdzić kolejkę wiadomości i skonfigurować parametry serwera. Zacznij od sprawdzenia kolejki wiadomości. Narzędzie mailq może w tym pomóc. Aby je aktywować, wpisz odpowiednie polecenie w terminalu:

mailq

Spowoduje to wyświetlenie listy wiadomości w kolejce, jeśli takie istnieją. Każda wiadomość zostanie wyświetlona z jej unikalnym identyfikatorem i informacjami o statusie wysyłania. Podobny wynik można uzyskać, przeglądając dzienniki klienta poczty.

W większości przypadków wysokie obciążenie występuje w przypadku naruszenia bezpieczeństwa serwera, gdy zaczyna on wysyłać spam. Jeśli jednak po sprawdzeniu administrator jest pewien, że serwer nie został zaatakowany z zewnątrz, a użytkownicy nie zaniedbują spamu, czas przejść do optymalizacji serwera pocztowego. Oto kroki, które pomogą:

1. Upewnij się, że rekordy DNS Twojej domeny są poprawnie skonfigurowane, w tym: SPF, rozszerzenie dkim, DMARC rekordy w celu usprawnienia dostarczania poczty i ochrony przed spamem. Prawidłową konfigurację parametrów można znaleźć w artykule na diagnostyka serwera pocztowego.
2. Sprawdź ustawienia sieciowe, w tym konfigurację zapory sieciowej i reguły routingu, aby uniknąć blokad i przyspieszyć dostarczanie poczty.
3. Skonfiguruj parametry kolejki komunikatów zgodnie z obciążeniem serwera. Może to obejmować ustawienie maksymalnego rozmiaru kolejki i limitów czasu.
4. Rozważ rozwiązania, które omówiliśmy wcześniej w tym artykule. Okresowo optymalizuj bazę danych serwera poczty, aby poprawić wydajność, używaj mechanizmów buforowania, aby przyspieszyć wyszukiwanie i przetwarzanie danych, takich jak zapytania DNS.
5. Jeśli serwer pocztowy nadal regularnie napotyka na duże obciążenia, należy rozważyć opcje skalowania, takie jak użycie klastra serwerów pocztowych lub rozwiązań w chmurze.

Wniosek

Zwiększone obciążenie serwera bezpośrednio wpływa na szybkość ładowania witryny, co ostatecznie wpływa na doświadczenie użytkownika i reputację w wyszukiwarkach. Dlatego skuteczne zarządzanie tym obciążeniem odgrywa kluczową rolę w zapewnieniu ciągłej funkcjonalności zasobu i zwiększeniu jego dostępności dla odwiedzających.