Strona może działać wolno mimo dysku NVMe i pakietu opisanego jako „wydajny”. Powód jest prosty: NVMe, RAM i vCPU nie przyspieszają witryny w ten sam sposób, a specyfikacje hostingu często nie pokazują limitów, które faktycznie zatrzymują WordPressa, WooCommerce czy aplikację PHP.
Dysk odpowiada głównie za operacje wejścia i wyjścia, pamięć przechowuje aktywne dane oraz cache, a procesor wykonuje kod. Jeżeli jedno z tych ogniw nie nadąża, pozostałe zasoby niewiele pomagają. Serwer z szybkim NVMe, ale z limitem jednego procesu PHP, nadal będzie kolejkował żądania. VPS z czterema vCPU i 2 GB RAM może z kolei zacząć korzystać ze swapu, gdy jednocześnie uruchomią się MySQL, PHP-FPM, kopia zapasowa i skan bezpieczeństwa.
Dlatego parametrów hostingu nie należy porównywać wyłącznie według zasady „więcej znaczy lepiej”. Trzeba sprawdzić, który zasób jest wąskim gardłem, jak długo może być obciążony i czy podana wartość jest gwarantowana, czy tylko chwilowo dostępna.
NVMe przyspiesza operacje na danych, ale nie naprawia wolnego kodu
NVMe jest protokołem przygotowanym dla pamięci masowej korzystającej między innymi z magistrali PCI Express. Obsługuje wiele kolejek poleceń, dzięki czemu sprawniej radzi sobie z równoległymi operacjami niż starsze rozwiązania oparte na SATA.
Na hostingu ma to znaczenie podczas:
- odczytywania dużej liczby małych plików PHP,
- wykonywania zapytań do bazy MySQL lub PostgreSQL,
- zapisywania sesji, logów i plików cache,
- generowania miniaturek zdjęć,
- rozpakowywania aktualizacji WordPressa,
- tworzenia kopii zapasowych,
- importowania produktów lub zamówień,
- pracy wielu stron na tym samym fizycznym serwerze.
Różnica między HDD a NVMe jest zwykle wyraźna. Przejście z poprawnie działającego SSD SATA na NVMe nie zawsze daje natomiast spektakularny efekt widoczny w przeglądarce. Jeżeli wygenerowanie dokumentu HTML zajmuje 1,5 sekundy z powodu nieoptymalnej wtyczki, brakujących indeksów w bazie albo zewnętrznego API, szybszy dysk może skrócić tylko część tego czasu.
W praktyce ważniejsze od deklarowanego transferu rzędu kilku gigabajtów na sekundę bywają:
- IOPS, czyli liczba operacji wejścia i wyjścia wykonywanych w ciągu sekundy,
- opóźnienie pojedynczej operacji,
- limit transferu przypisany do konta,
- limit liczby jednoczesnych operacji,
- stopień obciążenia wspólnej macierzy,
- rodzaj i kondycja użytych nośników,
- konfiguracja RAID oraz systemu plików.
Hosting może reklamować NVMe, a jednocześnie ograniczać konto do kilku lub kilkunastu MB/s albo narzucać niski limit IOPS. W takim środowisku sama nazwa technologii niewiele mówi. Szczególnie irytujące są oferty, w których limity I/O pojawiają się dopiero w regulaminie, panelu administracyjnym albo dokumentacji technicznej.
Szybki dysk pomaga najbardziej wtedy, gdy strona regularnie czeka na dane. Można to rozpoznać po wysokim I/O wait, spowolnieniach podczas importu, długim wykonywaniu zapytań SQL, opóźnionym panelu administratora lub wyraźnym pogorszeniu pracy w czasie backupu.
Nie należy natomiast zaczynać optymalizacji od zmiany SSD SATA na NVMe, jeżeli:
- procesor stale pracuje przy limicie,
- kończą się procesy PHP,
- zapytania do zewnętrznych usług trwają po kilka sekund,
- strona pobiera kilka megabajtów skryptów i zdjęć,
- cache strony nie działa,
- baza zawiera niezaindeksowane tabele,
- TTFB jest dobre, ale przeglądarka długo renderuje front-end.
TTFB poniżej około 800 ms jest traktowane jako dobry poziom orientacyjny, natomiast wynik powyżej 1,8 sekundy wskazuje już na poważny problem z odpowiedzią serwera lub warstwą sieciową. Sam TTFB nie jest jednak Core Web Vitalem i nie pokazuje całej szybkości strony.
RAM decyduje, czy serwer pracuje z pamięci, czy zaczyna ratować się dyskiem
Pamięć RAM jest potrzebna nie tylko systemowi operacyjnemu. Korzystają z niej procesy PHP, serwer WWW, baza danych, Redis, OPcache, panel hostingowy, narzędzia bezpieczeństwa, harmonogram zadań oraz mechanizmy tworzenia kopii.
Największy błąd polega na porównywaniu wyłącznie liczby gigabajtów. 2 GB RAM na VPS-ie oznacza coś innego niż „2 GB dostępnej pamięci” w hostingu współdzielonym. Na VPS-ie z tej puli trzeba utrzymać cały system i wszystkie usługi. Na hostingu współdzielonym klient zwykle otrzymuje limit na procesy konta, ale nie zarządza pamięcią serwera jako całością.
Dla typowego VPS-a sensowne punkty startowe wyglądają następująco:
- 1 GB RAM — bardzo mała strona statyczna, prosty serwis lub środowisko testowe; pełny WordPress z bazą na tym samym serwerze działa już bez dużego zapasu;
- 2 GB RAM — mała strona WordPress, blog lub wizytówka z umiarkowaną liczbą wtyczek;
- 4 GB RAM — kilka stron, rozbudowany WordPress, mały sklep WooCommerce albo aplikacja z lokalną bazą;
- 8 GB RAM — sklep z większym katalogiem, kilka usług, Redis, kolejki, intensywniejsze zadania cron;
- 16 GB i więcej — większe sklepy, portale, aplikacje z dużą bazą, wiele kontenerów albo oddzielne procesy robocze.
Nie są to gwarantowane progi. WordPress z ciężkim kreatorem, wielojęzycznością, rozbudowanym filtrowaniem produktów i kilkudziesięcioma wtyczkami może zużywać więcej zasobów niż autorska aplikacja obsługująca znacznie większy ruch.
Trzeba też policzyć pamięć przypisaną do procesów PHP. Jeżeli jeden proces PHP-FPM podczas obsługi ciężkiego żądania zużywa 150 MB, a pula dopuszcza 20 procesów, teoretyczne zapotrzebowanie może dojść do 3 GB. Do tego dochodzą MySQL, cache i system. Ustawienie wysokiego pm.max_children bez sprawdzenia rzeczywistego zużycia pamięci jest prostą drogą do przeciążenia serwera.
Gdy fizycznego RAM-u zaczyna brakować, Linux może przenosić część stron pamięci do obszaru wymiany. Swap chroni system przed natychmiastowym zatrzymaniem procesów, ale korzystanie z nośnika danych jest znacznie wolniejsze niż dostęp do RAM-u.
Krótkie, sporadyczne użycie swapu nie oznacza jeszcze awarii. Problem zaczyna się wtedy, gdy serwer stale przenosi dane między pamięcią a dyskiem. Objawy są charakterystyczne:
- panel administracyjny raz działa szybko, a raz zatrzymuje się na kilka sekund,
- czas odpowiedzi rośnie pod niewielkim obciążeniem,
- procesy PHP kończą się błędami,
- MySQL jest ubijany przez mechanizm OOM,
- zadania cron blokują zwykły ruch,
- backup powoduje wyraźne spowolnienie całej strony.
RAM umożliwia również skuteczne buforowanie. OPcache przechowuje skompilowany kod PHP w pamięci współdzielonej, dzięki czemu interpreter nie musi ponownie wczytywać i analizować skryptów przy każdym żądaniu. Redis może przechowywać wyniki zapytań i obiekty aplikacji, ale nie należy go traktować jako automatycznego przyspieszacza. Źle skonfigurowany object cache potrafi zwiększyć zużycie pamięci, a przy niestabilnym połączeniu z usługą Redis także wydłużyć obsługę żądań.
Najpierw trzeba ustalić, czy pamięci rzeczywiście brakuje. Na VPS-ie sprawdza się między innymi:
- zajętość RAM-u i swapu,
- pamięć procesów PHP-FPM,
- bufor InnoDB,
- wykorzystanie OPcache,
- liczbę restartów usług,
- komunikaty OOM w logach systemowych,
- zużycie pamięci podczas backupu i importu.
Na hostingu współdzielonym należy szukać w panelu statystyk limitów pamięci, procesów PHP, liczby procesów wejściowych oraz przypadków ograniczenia konta. Sam wykres wykorzystania przestrzeni dyskowej nie wystarczy.
vCPU odpowiada za kod i równoległość, ale jego liczba bywa myląca
vCPU jest jednostką mocy procesora przydzieloną maszynie wirtualnej lub kontenerowi. Nie musi odpowiadać całemu fizycznemu rdzeniowi. W zależności od platformy może reprezentować wątek sprzętowy, udział rdzenia albo zasób współdzielony z innymi klientami.
Dlatego 4 vCPU w dwóch różnych ofertach nie muszą zapewniać podobnej wydajności. Wynik zależy między innymi od:
- generacji i taktowania procesora,
- wydajności pojedynczego rdzenia,
- stopnia współdzielenia hosta,
- limitów czasu procesora,
- sposobu naliczania obciążenia,
- chwilowego obciążenia innych maszyn,
- konfiguracji hypervisora,
- limitów termicznych i energetycznych fizycznego serwera.
Dla WordPressa i wielu aplikacji PHP wydajność pojedynczego rdzenia pozostaje bardzo ważna. Obsługa konkretnego żądania często wykonuje znaczną część pracy sekwencyjnie. Dodanie kolejnych vCPU pozwala obsłużyć więcej żądań równolegle, ale nie musi skrócić czasu wykonania pojedynczego ciężkiego zapytania.
Przykład: strona produktu generuje się przez 1,2 sekundy z powodu nieefektywnego kodu. Zwiększenie serwera z 2 do 4 vCPU może poprawić zachowanie przy kilku jednoczesnych użytkownikach, ale pojedynczy użytkownik nadal będzie czekał około sekundy. Dopiero usunięcie wolnego zapytania, cache strony albo uproszczenie logiki skróci czas generowania dokumentu.
Więcej vCPU daje wyraźny efekt, gdy równolegle działają:
- procesy PHP obsługujące użytkowników,
- kolejki zamówień,
- importy i eksporty,
- generowanie miniatur,
- indeksowanie produktów,
- zadania cron,
- wyszukiwanie,
- kompresja plików,
- skanowanie antywirusowe,
- tworzenie kopii zapasowej.
Dla niewielkiej strony firmowej punktem startowym jest zwykle 1–2 vCPU. Rozbudowany WordPress lub mały WooCommerce powinien mieć co najmniej 2 vCPU i 4 GB RAM, o ile baza, poczta i pozostałe usługi działają na tej samej maszynie. Sklep obsługujący regularne zamówienia, integracje kurierskie, płatności, synchronizację magazynu i zadania w tle często potrzebuje 4 vCPU oraz 8 GB RAM. Większe instalacje powinny być dobierane na podstawie pomiarów, nie liczby produktów czy miesięcznych odsłon.
Istotne jest obciążenie chwilowe. Średnie użycie CPU na poziomie 20% może wyglądać bezpiecznie, mimo że serwer co kilka minut osiąga 100% podczas zadań cron. Użytkownik trafiający na taki moment zobaczy wolną stronę albo błąd 503, choć miesięczny wykres nie pokaże niczego alarmującego.
Na hostingu współdzielonym trzeba pytać nie tylko o liczbę vCPU, lecz także o:
- maksymalny procent CPU dostępny dla konta,
- czas, przez jaki limit może być wykorzystywany,
- sposób reakcji po jego przekroczeniu,
- liczbę jednoczesnych procesów PHP,
- limit procesów wejściowych,
- czas wykonywania skryptu,
- limity dla zadań cron,
- możliwość zmiany wersji PHP i ustawień OPcache.
Częsty problem polega na tym, że dostawca deklaruje dwa lub cztery vCPU, ale ogranicza konto małą liczbą równoległych procesów. W efekcie procesor nie jest w pełni wykorzystany, ponieważ nowe żądania czekają w kolejce. Podobnie działa niski limit PHP workers w usługach zarządzanych.
Do oceny hostingu nie wystarczy PageSpeed Insights wykonany raz. Trzeba połączyć kilka pomiarów:
- Sprawdzić TTFB strony bez cache oraz po rozgrzaniu cache.
- Zmierzyć czas generowania dokumentu HTML.
- Obserwować CPU, RAM, swap i I/O podczas ruchu.
- Przejrzeć logi wolnych zapytań bazy.
- Sprawdzić liczbę aktywnych i oczekujących procesów PHP.
- Powtórzyć test podczas importu, backupu lub zadań cron.
- Porównać wyniki w godzinach małego i dużego obciążenia.
Jeżeli strona jest szybka bez ruchu, ale zwalnia przy kilku równoczesnych żądaniach, problemem zwykle jest liczba procesów, CPU albo brak skutecznego cache. Jeżeli wolna jest także przy pojedynczym wejściu, najpierw należy sprawdzić kod, bazę, zewnętrzne integracje i wydajność jednego rdzenia. Gdy spowolnienia pojawiają się podczas operacji na plikach lub bazie, podejrzenie pada na I/O i pamięć.
FAQ: NVMe, RAM i vCPU
Czy hosting NVMe zawsze jest szybszy od hostingu SSD?
Nie. NVMe zapewnia lepsze warunki techniczne dla operacji dyskowych, ale niski limit IOPS, przeciążona macierz, wolny procesor lub mała liczba procesów PHP mogą zniwelować przewagę.
Ile RAM-u potrzebuje zwykły WordPress?
Na samodzielnym VPS-ie rozsądnym minimum są zwykle 2 GB, a bezpieczniejszym punktem startowym 4 GB. Na hostingu współdzielonym ważniejszy od nominalnej liczby jest limit pamięci przypisany do konta i pojedynczego procesu PHP.
Czy zwiększenie liczby vCPU przyspieszy stronę produktu?
Tylko wtedy, gdy problemem jest brak mocy procesora lub kolejka równoległych żądań. Wolnego zapytania SQL albo opóźnionego API dodatkowe rdzenie zwykle nie naprawią.
Co jest ważniejsze: RAM czy vCPU?
Zależy od objawów. Stale pełna pamięć i aktywny swap wskazują na brak RAM-u. CPU utrzymujące się przy limicie oraz kolejka procesów wskazują na brak mocy obliczeniowej. Kupowanie obu zasobów bez pomiarów często tylko podnosi rachunek.
Czy 1 vCPU i 1 GB RAM wystarczą dla strony firmowej?
Dla lekkiej strony z cache — czasem tak. Dla WordPressa z panelem, bazą danych, pocztą, backupem i skanerem bezpieczeństwa taki serwer będzie pracował bez zapasu i może zwalniać podczas aktualizacji albo zadań cron.
Czy CDN zastąpi lepszy hosting?
CDN odciąża serwer w zakresie plików statycznych i może podawać cache HTML, ale nie przyspieszy niezbuforowanego panelu administracyjnego, koszyka, logowania ani ciężkich operacji w bazie.
Pierwszym krokiem nie powinien być zakup większego pakietu. Najpierw zmierz TTFB bez cache, sprawdź wykorzystanie CPU, pamięci, swapu i I/O w czasie spowolnienia, a następnie przejrzyj limity procesów PHP. Jeżeli serwer ma wolne zasoby, usuń problem w aplikacji. Jeżeli dobija do konkretnego limitu, zwiększ właśnie ten zasób — nie cały pakiet na ślepo.
