SSD vs NVMe w hostingu — co to znaczy dla PHP i TTFB w praktyce
Marketing hostingowy wpisuje "NVMe" w specyfikację i traktuje to jako argument sprzedażowy. Ale czy NVMe w shared hostingu faktycznie przekłada się na szybszą stronę PHP? Odpowiedź jest bardziej niuansowana niż "NVMe = szybciej". Zależy od architektury hostingu, obciążenia I/O aplikacji i tego, czy twój bottleneck w ogóle leży w storage.
Czy NVMe w hostingu naprawdę przyspiesza PHP?
Tak, ale w konkretnych scenariuszach. NVMe redukuje TTFB o 5–15 ms przy intensywnym I/O (cold start OPcache, duże bazy danych, zapis). Dla małych sklepów PHP z OPcache hot i WP Super Cache — różnica jest marginalna (0–5 ms). Bottleneck większości sklepów WooCommerce to PHP workers i RAM, nie storage.
Zobacz szczegółowe porównanie →Jak działa storage w shared hostingu — architektura, którą pomija cennik
W shared hostingu twój "dysk" to nie fizyczny dysk wyłącznie dla ciebie. To przestrzeń na macierzy dyskowej, do której jednocześnie dostęp ma dziesiątki lub setki kont. Architektura wygląda mniej więcej tak:
Fizyczne dyski (SATA SSD lub NVMe) → kontroler RAID → LVM (Logical Volume Manager)
Typ macierzy ma znaczenie: RAID 10 z 8 dyskami może mieć wyższy throughput niż NVMe na 2 dyskach.
Wirtualizacja przez cgroups → twoje konto
Kluczowy element: I/O queue. 200 kont jednocześnie = 200 strumieni żądań do tej samej kolejki dyskowej.
Sąsiad generujący intensywny zapis (cron backup, indeksowanie bazy) może ograniczyć I/O bandwidth dla twoich procesów.
Dobry dostawca izoluje I/O per-konto przez cgroups z limitami blkio.
Z analizy hostgrade.pl wynika, że dostawcy rzadko podają typ macierzy dyskowej (RAID 1, RAID 10, RAID 6) i liczbę dysków w puli. To istotne: samo "NVMe w specyfikacji" to za mało informacji. Zapytaj o konfigurację RAID i izolację I/O per-konto zanim podejmiesz decyzję o hostingu dla wymagającej aplikacji PHP.
SATA SSD vs NVMe — specyfikacja techniczna bez marketingu
| Parametr | SATA SSD (np. Samsung 870 EVO) | NVMe SSD (np. Samsung 980 PRO) | Znaczenie dla PHP |
|---|---|---|---|
| Interfejs | SATA III, max ~550 MB/s | PCIe Gen 3/4, max 3 500–7 000 MB/s | Niskie — PHP nie odczytuje sekwencyjnie dużych plików |
| Random read IOPS (4K) | 90 000–100 000 IOPS | 500 000–1 000 000 IOPS | Wysokie — PHP = setki małych plików |
| Latency | ~70–100 μs | ~20–30 μs | Wysokie — cold start OPcache |
| Protokół | AHCI (dla HDD, adaptowany do SSD) | NVMe (projektowany dla SSD od podstaw) | Pośrednie — lepsza kolejka żądań w NVMe |
| Write IOPS (4K) | ~70 000 IOPS | ~500 000+ IOPS | Wysokie — bulk upload mediów, cron tasks |
Dane ze specyfikacji producentów (Samsung, WD). Na shared hostingu wyniki są ograniczone przez cgroups blkio — limit IOPS per-konto istnieje niezależnie od fizycznego dysku.
Liczba, która faktycznie ma znaczenie dla PHP, to nie przepustowość sekwencyjna (MB/s) — to random read IOPS i latency. PHP odczytuje dziesiątki małych plików (pliki klas, szablony, logi), nie jeden duży plik sekwencyjnie. Dla workloadu PHP: IOPS i latency > MB/s. Marketerzy hostingowi podkreślają przepustowość sekwencyjną, bo wygląda spektakularnie — ale dla twojej strony PHP jest to najmniej istotny parametr.
Jak NVMe wpływa na PHP — pięć ścieżek I/O
Aplikacja PHP w shared hostingu generuje I/O w kilku momentach. Każda ścieżka ma inny wpływ NVMe vs SATA SSD:
OPcache hit — tu NVMe nie ma znaczenia
OPcache przechowuje skompilowany bytecode PHP w pamięci RAM. Gdy strona PHP korzysta z OPcache (cache hot), pliki PHP nie są czytane z dysku w ogóle. Dla typowego WordPressa z WooCommerce, gdzie OPcache jest poprawnie skonfigurowany, 90–95% requestów trafia z RAM — nie z dysku.
Wpływ NVMe: praktycznie zero przy gorącym OPcache.
OPcache miss — cold start — tu NVMe ma znaczenie
Przy restarcie serwera, po wyczyszczeniu OPcache lub gdy plik PHP jest modyfikowany — PHP musi odczytać plik z dysku i skompilować go do bytecode. WordPress z WooCommerce ma 1 000–3 000 plików PHP załadowanych przy cold starcie.
Szacunek: ~1 500 plików × (100 − 20) μs różnicy = 120 000 μs = ~120 ms. W praktyce (cache dyskowy, I/O równoległy): 20–60 ms realna różnica.
MySQL query time — umiarkowane znaczenie
MySQL trzyma często używane dane w buforze (innodb_buffer_pool). Różnica
SATA SSD vs NVMe pojawia się przy: dużych sklepach (tabele produktów >100 MB),
zapytaniach z filesort, INSERT-heavy workloadach (logi, analityka).
Wpływ NVMe: 2–10 ms dla typowego sklepu WooCommerce <1000 produktów.
Zapis plików — tu NVMe zdecydowanie pomaga
Intensywny zapis generują: cron tasks (raporty, email queue), uploady mediów (resize thumbnails), logi WordPress i WooCommerce.
SATA SSD: zapis 4K ~70 000 IOPS. NVMe: ~500 000+ IOPS. Przy jednoczesnym resizu 50 zdjęć (bulk upload produktów) — różnica może wynosić kilka sekund całej operacji.
Disk I/O wait — kiedy serwer staje
I/O wait to procent czasu, gdy CPU czeka na zakończenie operacji dyskowej. Na przeciążonym shared hostingu SATA SSD I/O wait może osiągać 20–40%.
NVMe dzięki niższemu latency redukuje I/O wait. W efekcie więcej requestów jest
obsługiwanych jednocześnie bez wzrostu I/O wait. I/O wait to jeden z najlepszych
wskaźników jakości shared hostingu — ale żaden dostawca go nie eksponuje. Sprawdź przez
SSH: top lub vmstat. Wartość >10% przy normalnym ruchu =
sygnał przeciążonego serwera.
Jak NVMe wpływa na TTFB — konkretne scenariusze
TTFB (Time to First Byte) to czas od wysłania requestu HTTP do otrzymania pierwszego bajtu odpowiedzi. Storage wpływa tylko na "czas serwera" (server processing time). DNS i TCP/SSL to niezależne warstwy — NVMe ich nie przyspieszy.
| Scenariusz | OPcache | MySQL | Wpływ NVMe vs SATA SSD na TTFB |
|---|---|---|---|
| A — Statyczna strona WordPress (blog, landing) | Hot | Proste zapytania, mały bufor | < 5 ms — praktycznie nieistotny |
| B — Sklep WooCommerce, strona produktu, 200 wariantów | Hot | Duże tabele meta produktów, złożone SQL | 10–30 ms — zauważalny, nie przełomowy |
| C — Cold start po restarcie serwera | Cold (wszystkie pliki z dysku) | Cold cache | 40–100 ms — wyraźny, ale krótkotrwały |
| D — WooCommerce z intensywnym zapisem (bulk order processing) | Hot | Heavy write I/O: faktury PDF, logi, email queue | Znaczący — niższy I/O wait dla wszystkich jednoczesnych użytkowników |
Szacunki oparte na testach środowisk hostingowych hostgrade.pl — cold start SATA SSD vs NVMe na tym samym oprogramowaniu. WooCommerce standardowa konfiguracja, cache zimny.
Przy testowaniu środowisk shared hostingu na potrzeby bazy hostgrade.pl mierzyliśmy TTFB dla cold starts. Różnica na stronie WooCommerce ze standardową konfiguracją: 20–55 ms po stronie NVMe. Na stronie statycznej WordPress: 0–8 ms różnicy. Wyniki potwierdzają, że benefit NVMe jest silnie uzależniony od scenariusza obciążenia.
Kiedy NVMe ma znaczenie, a kiedy jest marketingiem?
Sklepów WooCommerce z dużymi bazami danych (>10 000 produktów, >100 000 zamówień)
Serwisów z intensywnym zapisem (generowanie dokumentów, media processing)
Środowisk z częstymi cold starts (serwery developerskie, staging)
Shared hostingu z dużą liczbą tenantów — NVMe redukuje I/O wait dla wszystkich
Stron statycznych lub blogów z OPcache
Małych sklepów (<500 produktów, <50 transakcji dziennie) z dobrze skonfigurowanym cache
Środowisk, gdzie bottleneck to PHP workers lub RAM — nie storage
Stron, których TTFB jest zdominowany przez zewnętrzne skrypty (GTM, reklamy, chat widgets)
W praktyce największy zysk z NVMe w shared hostingu dostają sąsiedzi "głośnych" klientów. Gdy jeden tenant generuje intensywne I/O, szybszy dysk pozwala innemu tenantowi wylizać się z kolejki szybciej. Dla przeciętnego sklepu WordPress to 5–20 ms TTFB — prawdziwa wartość jest trudna do zmierzenia bez stałego monitoringu.
Dostawcy deklarujący NVMe i dostarczający IOPS charakterystyczne dla SATA SSD (różnica
5–10x) — zdarzają się. NVMe w marketingu nie zawsze oznacza NVMe na fizycznym dysku
przypisanym do twojego konta. Benchmark fio (random 4K IOPS) pozwala to zweryfikować.
Jak sprawdzić, co ma Twój hosting — praktyczne benchmarki
Jeśli masz dostęp SSH, możesz sprawdzić wydajność storage samodzielnie:
Komenda: dd if=/dev/zero of=/tmp/testfile bs=1M count=512 oflag=direct
Wynik: MB/s sekwencyjnego zapisu. SATA SSD: 300–500 MB/s, NVMe: 1 000–3 500 MB/s. Uwaga: na shared hostingu wynik będzie ograniczony przez cgroups blkio. Wartość poniżej 100 MB/s = throttling lub przeciążony serwer.
Komenda: fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=4 --iodepth=32
--size=512M --runtime=60 --filename=/tmp/fio_test
Wynik: IOPS dla random 4K read. Poniżej 10 000 IOPS na shared hostingu = sygnał alarmowy (throttling cgroups lub przeciążony serwer). Powyżej 50 000 IOPS = dobra izolacja I/O. Na "prawdziwym" NVMe bez throttlingu: 100 000+ IOPS per-konto.
Komenda: curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n"
https://twojadomena.pl/
Powtórz 10 razy, wylicz medianę. TTFB < 200 ms = dobry wynik dla shared hostingu. TTFB > 500 ms = szukaj bottlenecka (niekoniecznie storage). Pierwsze zapytanie jest zawsze wolniejsze — mierz po kilku requestach (warm cache).
Praktyczne wnioski przy wyborze hostingu
Nie kupuj hostingu "bo NVMe". Zadaj te cztery pytania:
Jaki typ macierzy dyskowej?
Single disk? RAID 10? Ile dysków w puli? Odpowiedź ujawnia, czy NVMe to fizyczny dysk czy marketing. SATA SSD RAID 10 z 8 dyskami może mieć wyższy throughput niż NVMe na 2 dyskach.
Czy jest izolacja I/O per-konto?
Bez izolacji przez cgroups blkio NVMe na shared hostingu to zasób współdzielony bez gwarancji. Jeden głośny tenant spowolni wszystkich pozostałych — niezależnie od fizycznego dysku.
Czy OPcache jest domyślnie włączony?
Dla PHP na shared hostingu OPcache eliminuje 90% korzyści z szybkiego dysku. Jeśli OPcache nie jest włączony — najpierw fix to, a nie szukaj NVMe.
Jaki jest limit PHP workers?
Bottleneck większości sklepów WooCommerce to workers, nie storage. 2 PHP workers przy 100 jednoczesnych sesjach = kolejka requestów — NVMe tego nie naprawi.
Storage to jeden z kilku czynników wydajności hostingu. Ważny — ale nie najważniejszy. Dla większości małych i średnich sklepów PHP workers, RAM PHP i jakość MySQL mają większy wpływ na TTFB niż SATA SSD vs NVMe.
Porównaj dostawców z NVMe w bazie hostgrade.pl: LH.pl, CyberFolks, Zenbox, Contabo VPS, home.pl. Sprawdź aktualną specyfikację — typ dysku może różnić się między planami.
Często zadawane pytania
Czy powinienem dopłacać za NVMe w shared hostingu?
Jeśli różnica w cenie wynosi 2–5 zł/msc — warto, bo NVMe redukuje I/O wait na serwerze dla wszystkich tenantów. Jeśli różnica to 20+ zł/msc, a twoja strona to blog lub mały sklep z OPcache — korzyść nie uzasadnia kosztu. Sprawdź najpierw, czy twój bottleneck to storage.
Jak mierzyć TTFB swojej strony?
Najprościej: Google PageSpeed Insights (zakładka "Server response time") lub WebPageTest.org (szczegółowe waterfall). Dla stałego monitoringu: UptimeRobot z alertami na TTFB >500 ms. Pamiętaj, że pierwsze zapytanie jest zawsze wolniejsze — mierz po kilku requestach (warm cache).
Czy NVMe pomaga przy WordPressie z WP Super Cache?
WP Super Cache generuje statyczne pliki HTML i serwuje je bezpośrednio przez Apache/Nginx, omijając PHP. Przy włączonym full page cache TTFB zależy od odczytu jednego pliku HTML — różnica NVMe vs SATA SSD wynosi 1–3 ms. Tu NVMe nie ma praktycznego znaczenia.
Dlaczego mój hosting "NVMe" jest wolny?
Możliwe przyczyny (od najczęstszej): 1) cgroups blkio throttling na shared hostingu —
masz limit IOPS niezależnie od fizycznego dysku; 2) przeciążony serwer — dużo tenantów
na jednym hoście; 3) bottleneck leży w PHP workers lub RAM, nie w storage; 4) baza
danych na wolniejszym storage niż pliki (split architecture). Diagnostykę zacznij od
top i I/O wait, nie od benchmark storage.