Ilu jednoczesnych użytkowników obsłuży VPS: jak to policzyć

Od użytkowników do żądań

„Jednocześni użytkownicy” to trzy różne wielkości, zależnie od tego, kto o nich mówi:

• Zarejestrowane konta: nic nie kosztują serwera, dopóki się nie logują.
• Użytkownicy aktywni w tym samym czasie: osoby, które przeglądają, czytają, wypełniają formularz. Każda z nich od czasu do czasu wysyła żądanie, zwykle co 10 do 30 sekund, plus kilka wywołań API na ekran w nowoczesnej aplikacji.
• Żądania w trakcie przetwarzania: te, które serwer oblicza w danej chwili. To jedyna wielkość, która zużywa procesor i pamięć.

Od jednej wielkości do drugiej przechodzi się dzięki prawu Little’a: liczba żądań w toku równa się przepustowości, w żądaniach na sekundę, pomnożonej przez średni czas trwania żądania.

Przykład. 600 użytkowników aktywnych jednocześnie, z których każdy wysyła żądanie co 20 sekund, daje 30 żądań na sekundę. Jeśli każde żądanie trwa 100 ms, serwer ma średnio tylko 3 żądania w toku. Wyzwanie leży gdzie indziej: w szczytach i w wolnych żądaniach.

Ile obsłuży jeden vCPU

Żądanie zajmuje procesor przez czas swoich obliczeń: wykonanie kodu, zapytanie do bazy, zbudowanie odpowiedzi. Jeden vCPU przetwarza więc najwyżej 1 000 ÷ t żądań na sekundę, gdzie t to czas obliczeń jednego żądania w milisekundach. Czas oczekiwania (na zewnętrzne API, na dysk) nie zajmuje procesora, ale zajmuje workera.

Przy tych rzędach wielkości 30 żądań API na sekundę po 10 ms obliczeń zajmuje 30 % jednego vCPU. Te same 30 żądań na sekundę na stronach WordPress bez pamięci podręcznej wymaga od 3 do 9 vCPU. Pamięć podręczna stron służy właśnie do tego, aby przenieść stronę z czwartego wiersza tabeli do drugiego.

Ile zmieści pamięć

Każde żądanie w toku obsługuje worker, a workery zajmują pamięć bez względu na to, czy pracują. To często pamięć, bardziej niż procesor, wyznacza liczbę żądań przetwarzanych równolegle:

• PHP-FPM: jeden proces na żądanie w toku, od 40 do 80 MB każdy. pm.max_children wyznacza limit: 20 procesów to od 800 MB do 1,6 GB.
• Python (Gunicorn, Uvicorn): dokumentacja Gunicorna proponuje zacząć od (2 × liczba rdzeni) + 1 workerów, po 80 do 200 MB każdy. Worker asynchroniczny utrzymuje wiele oczekujących żądań kosztem jednego procesu.
• Node.js: jeden proces utrzymuje tysiące oczekujących połączeń, ale korzysta tylko z jednego rdzenia; tryb cluster lub PM2 uruchamia jeden proces na vCPU.
• Baza danych: PostgreSQL otwiera jeden proces na połączenie i domyślnie przyjmuje ich 100. Powyżej kilkudziesięciu aktywnych połączeń lepiej sprawdza się pula połączeń, taka jak PgBouncer, niż podniesienie max_connections.

Połączenia stałe (websockety, powiadomienia w czasie rzeczywistym) liczy się osobno: otwarte bez przerwy, zajmują niewiele procesora i po kilkadziesiąt kilobajtów pamięci każde. Serwer Node.js utrzymuje ich tysiące w kilkuset MB.

Prawdziwe wąskie gardła

W rzeczywistej aplikacji serwer rzadko osiąga limit tam, gdzie się tego spodziewamy. Najczęstsze przyczyny, w kolejności, w jakiej warto ich szukać:

1. Wolne zapytanie SQL: brakujący indeks zamienia zapytanie trwające 2 ms w zapytanie trwające 2 sekundy, które blokuje workera i połączenie. Wskazuje je pg_stat_statements w PostgreSQL lub dziennik wolnych zapytań MySQL.
2. Zapytania kaskadowe (problem N+1): strona, która wysyła jedno zapytanie na każdy wyświetlany wiersz, wysyła ich setki.
3. Synchroniczne wywołanie zewnętrzne: API płatności lub AI, które odpowiada w 3 sekundy, blokuje synchronicznego workera na 3 sekundy.
4. Ciężkie operacje wewnątrz żądania: wysyłka e-maili, zmiana rozmiaru obrazów, generowanie PDF, do przeniesienia do kolejki zadań.
5. Brak pamięci podręcznej: strony identyczne dla wszystkich odwiedzających serwuje się z pamięci podręcznej, a pliki statyczne z serwera WWW.

Sprawdzenie: test obciążeniowy

Rzędy wielkości dają pierwszy rozmiar; test obciążeniowy daje rzeczywisty. Zasada: symulować coraz większą liczbę użytkowników na kopii aplikacji i odnotować moment, w którym czas odpowiedzi gwałtownie rośnie.

wrk -t2 -c50 -d30s --latency https://test.panstwa-strona.com/

Dla pełnej ścieżki (logowanie, nawigacja, wyszukiwanie) k6 opisuje scenariusz w JavaScripcie i zwiększa obciążenie etapami:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 300 },
    { duration: '5m', target: 300 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'] },
};

export default function () {
  http.get('https://test.panstwa-strona.com/');
  sleep(15);
}

• Proszę testować kopię, a nie produkcję, i uprzedzić firmę hostingową, jeśli test dotyczy serwera, którym ona zarządza.
• Proszę uruchamiać test z innej maszyny niż testowany serwer, w przeciwnym razie narzędzie zabiera mu jego własne zasoby.
• Proszę patrzeć na 95. percentyl czasu odpowiedzi, a nie na średnią: tego doświadczają najgorzej obsłużeni użytkownicy.
• Proszę obserwować serwer podczas testu: htop dla procesora, free -h dla pamięci, logi dla błędów.

Gdy obciążenie rośnie

Kolejność, która kosztuje najmniej i daje najwięcej:

1. Umieścić w pamięci podręcznej to, co się da (strony, fragmenty, wyniki zapytań), i poprawić wolne zapytania.
2. Dostosować liczbę workerów do dostępnej pamięci i procesora.
3. Przejść na większy rozmiar: więcej vCPU i pamięci, bez żadnych zmian w aplikacji.
4. Przenieść bazę danych na osobny serwer.
5. Rozłożyć aplikację na kilka serwerów za systemem równoważenia obciążenia (load balancer).

Pierwsze trzy kroki obejmują zdecydowaną większość aplikacji biznesowych, stron i API: kilkuset użytkowników aktywnych jednocześnie mieści się na jednym dobrze skonfigurowanym serwerze.