Deweloperzy obserwują, jak ich nowo uruchomiona aplikacja zwalnia w momencie, gdy kilka tysięcy użytkowników klika „start”, i rzadko kiedy spowolnienie wynika z błędu w kodzie – to raczej walka procesora (CPU) i pamięci RAM o zasoby. Wąskie gardło objawia się dłuższym czasem ładowania stron, przekroczeniami czasu połączenia (timeoutami) lub całkowitymi awariami, co negatywnie wpływa na doświadczenia użytkowników, przychody i zaufanie do marki.

Dlaczego serwer, który działał sprawnie w laboratorium, może stanąć w miejscu na produkcji

Podczas rozwoju oprogramowania pojedynczy deweloper wysyła zaledwie kilka zapytań, więc zasoby serwera przez większość czasu pozostają niewykorzystane. Gdy aplikacja trafia do użytku, każdy odwiedzający generuje zapytanie, które wymaga dwóch kluczowych składników:

  • CPU (central processing unit) – procesor, który wykonuje każdą pętlę, funkcję i obliczenie. Można go porównać do szefa kuchni, który może przygotować tylko ograniczoną liczbę dań jednocześnie. Jedno zamówienie jest realizowane natychmiast; sto zamówień oznacza, że szef nadal pracuje z tą samą prędkością, ale klienci czekają dłużej.
  • RAM (random-access memory) – pamięć operacyjna, czyli tymczasowy magazyn danych, których CPU potrzebuje podczas obsługi zapytania. To jak biurko, na którym szef kuchni trzyma składniki do każdego dania. Jeśli biurko jest pełne, szef musi przestać przyjmować nowe zamówienia, dopóki nie zwolni się miejsce.

Gdy tysiące użytkowników loguje się jednocześnie, każde zapytanie zajmuje własny fragment czasu procesora i własną porcję pamięci RAM. Skończona pula obu tych zasobów zostaje podzielona między zapytania, a kolejka rośnie. Sam serwer nie stał się wolniejszy

Spowolnienie serwera po uruchomieniu to zazwyczaj problem z rywalizacją o zasoby, a nie błąd w kodzie. Cykle procesora i sloty pamięci RAM są ograniczone, a gdy przychodzi wiele zapytań jednocześnie, ustawiają się one w kolejce, co wydłuża czas odpowiedzi. Skalowanie pionowe zapewnia nieco większy zapas wydajności, ale wkrótce napotyka bariery fizyczne i ekonomiczne. Skalowanie poziome — dodawanie mniej wydajnych serwerów za load balancerem — oferuje tańszą i bardziej odporną ścieżkę wraz ze wzrostem ruchu. W momencie, gdy zauważysz wydłużanie się kolejki, nadejdzie czas na ocenę, czy wystarczy kilka dodatkowych rdzeni, czy też należy zacząć rozdzielać obciążenie na wiele maszyn.

Źródło: artykuł na dev.to „Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”