Przed zakupem hostingu nie wystarczy sprawdzić pojemności dysku i ceny odnowienia. Dla WordPressa i innych aplikacji znaczenie mają również limity CPU, pamięci, procesów, współbieżności oraz operacji dyskowych. Problem polega na tym, że operatorzy nie zawsze pokazują te parametry w ten sam sposób. To checklista wyboru planu przed zakupem; diagnozę limitu osiąganego już na działającym koncie opisuje osobny poradnik. Przy wyborze planu dla sklepu odnieś te parametry do dynamicznych operacji opisanych w poradniku o hostingu dla WooCommerce.
Najbardziej użyteczne porównanie zaczyna się więc od dwóch pytań: które limity są jawnie podane dla konkretnego pakietu i co dokładnie oznaczają w środowisku danego operatora? CloudLinux pozwala osobno ograniczać między innymi CPU/SPEED, PMEM, I/O, IOPS, EP i NPROC. LVE Manager pokazuje te parametry jako odrębne limity konta.
Jakie limity hostingu warto sprawdzić przed zakupem?
| Parametr | Co opisuje | O co zapytać operatora |
|---|---|---|
| CPU / SPEED | Przydział procesora dostępny dla konta | Jaki jest limit dla tego pakietu i w jaki sposób jest liczony? |
| PMEM / RAM | Maksymalną pamięć fizyczną używaną przez procesy konta | Czy podana pamięć jest limitem PMEM całego konta? |
| PHP workers | Współbieżność wykonywania żądań PHP według konfiguracji operatora | Co dokładnie oznacza worker w tej usłudze i dla jakiego zakresu jest liczony? |
| EP | Entry Processes w CloudLinux | Jaki jest limit EP i czy operator pokazuje jego wykorzystanie? |
| NPROC | Maksymalną liczbę procesów i wątków w LVE | Jaki jest limit i czy dotyczy całego konta? |
| I/O | Przepustowość operacji dyskowych | Jaki limit KB/s lub MB/s ma konkretne konto? |
| IOPS | Liczbę operacji odczytu i zapisu na sekundę | Jaki limit IOPS obowiązuje dla pakietu? |
| INODES | Maksymalną liczbę plików i katalogów objętych limitem konta | Jaki jest limit inode, czy istnieje limit miękki i twardy oraz czy obejmuje całe konto? |
SPEED, PMEM, I/O, IOPS, NPROC i EP są w CloudLinux odrębnymi zasobami z różnymi skutkami osiągania limitu. Dlatego pojedyncza etykieta „hosting zoptymalizowany pod WordPress” nie zastępuje danych o przydziale zasobów.
CPU w hostingu — jak porównywać procenty i rdzenie?
CloudLinux może określać SPEED jako procent CPU albo wartość częstotliwości. W tym modelu 100% odpowiada jednemu pełnemu rdzeniowi CPU dostępnym dla LVE, a wyższy procent zwiększa przydział w ramach limitu SPEED.
Nie zakładaj jednak, że każda oferta z napisem „200% CPU” używa dokładnie tego samego modelu. Operator może prezentować zasoby własnym językiem albo stosować dodatkowe ograniczenia. Przy porównaniu dwóch ofert najlepiej mieć potwierdzenie, że liczby dotyczą tego samego rodzaju limitu.
Nawet wtedy 100% CPU u dwóch operatorów nie oznacza identycznej wydajności. W CloudLinux jest to wielkość przydziału względem rdzenia, ale nie wyrównuje wydajności różnych procesorów. Dwa pakiety mogą więc mieć taki sam limit procentowy i różnić się rzeczywistym czasem wykonania PHP.
Nie oceniaj też całego hostingu tylko po CPU. Większy przydział procesora nie rozwiązuje braku pamięci, niskiego I/O, kolejki PHP workers ani ograniczenia EP.
RAM, PMEM i pamięć PHP — czego nie mieszać?
PMEM w CloudLinux to limit pamięci fizycznej przypisanej do LVE. W raportowaniu CloudLinux obejmuje również między innymi pamięć współdzieloną i cache dyskowy. Nie jest tym samym co limit pamięci pojedynczego skryptu PHP ustawiany przez memory_limit. Te dwie wartości mogą istnieć równocześnie i ograniczać inne rzeczy.
Przykładowo wysoki memory_limit PHP nie gwarantuje, że wiele równoległych procesów będzie mogło zużyć taką wartość jednocześnie. Całe konto może wcześniej dojść do PMEM. Po przekroczeniu tego limitu system może zakończyć procesy konta, co może prowadzić do błędów aplikacji w modelu LVE.
Do operatora warto więc wysłać proste pytanie: „Czy podane X GB RAM oznacza PMEM całego konta, limit pojedynczego procesu czy inną wartość?”. Bez takiego doprecyzowania dwa pakiety z napisem „2 GB RAM” nie muszą być porównywalne.
PHP workers — kiedy liczba z cennika naprawdę coś mówi?
Liczba PHP workers ma znaczenie dopiero wtedy, gdy wiadomo, co operator nazywa workerem. W PHP-FPM najbliższym odpowiednikiem limitu równocześnie obsługiwanych żądań jest zwykle pm.max_children, czyli maksymalna liczba procesów potomnych obsługujących równoczesne żądania, ale hosting może używać innego mechanizmu lub własnego sposobu prezentowania limitu.
Nie przeliczaj workers na użytkowników online. Jedno wolne żądanie może zajmować proces przez kilka sekund, a odpowiedź z page cache może w ogóle nie uruchamiać pełnego WordPressa. Dlatego „10 workers” bez informacji o czasie wykonania żądań nie opisuje maksymalnego ruchu strony.
Szczegółowe różnice między workers, EP i NPROC opisuje poradnik o PHP workers.
EP i NPROC — podobne nazwy, inne ograniczenia
EP i NPROC w CloudLinux dotyczą innych rzeczy. EP ogranicza wejścia do środowiska LVE, a NPROC całkowitą liczbę procesów i wątków w LVE; oba limity są konfigurowane i raportowane niezależnie.
Nie próbuj więc ustalać EP na podstawie NPROC ani odwrotnie. Jeżeli oferta pokazuje tylko jeden z tych parametrów, zapytaj o drugi, jeśli jest istotny dla Twojej aplikacji. Przy WordPressie szczególnie ważne staje się to wtedy, gdy wcześniej występowały błędy 508, 503 albo problemy z równoczesnymi żądaniami — przy czym sam kod błędu nie wskazuje jeszcze, który limit został osiągnięty.
Diagnostykę po błędzie opisują osobne poradniki: 508 Resource Limit Reached oraz 503 Service Unavailable. Gdy problem już występuje, zacznij od poradnik o diagnozowaniu limitów CPU, RAM, procesów i I/O.
I/O i IOPS — dlaczego samo NVMe nie wystarcza?
NVMe opisuje technologię nośnika w serwerze, natomiast I/O i IOPS mogą być limitami przypisanymi do konkretnego konta. Szybki sprzęt nie oznacza więc automatycznie, że użytkownik otrzymuje wysoki przydział operacji dyskowych.
I/O ogranicza przepustowość operacji dyskowych, a IOPS ich liczbę na sekundę. CloudLinux rozdziela oba parametry. I/O jest mierzone jako przepustowość, a IOPS jako liczba operacji odczytu i zapisu.
Jeżeli strona pracuje na wielu małych plikach, cache plikowym, backupach czy importach, IOPS może mieć większe znaczenie niż sama liczba MB/s. Więcej przykładów znajdziesz w poradniku o I/O i IOPS.
Inode — limit liczby plików też może mieć znaczenie
Limit inode określa, ile plików i katalogów może obejmować konto. Dla WordPressa staje się istotny szczególnie wtedy, gdy na jednym koncie działa wiele instalacji, przechowywana jest poczta, cache plikowy, lokalne backupy albo duża liczba miniaturek.
Przed zakupem zapytaj, czy operator stosuje limit inode, czy ma on próg miękki i twardy oraz czy obejmuje całe konto. Sama duża pojemność w GB nie oznacza, że można przechowywać dowolną liczbę małych plików.
Co zrobić, gdy operator nie publikuje limitów?
Brak parametru w tabeli nie oznacza, że limit nie istnieje. Na serwerze CloudLinux administrator może ustawić SPEED, PMEM, I/O, IOPS, EP i NPROC dla użytkownika lub pakietu. LVE Manager udostępnia te limity w konfiguracji pakietów i kont.
Jeżeli wartości nie są publiczne, wyślij przed zakupem konkretne pytanie:
Rozważam pakiet [nazwa]. Proszę podać limity CPU/SPEED, PMEM, I/O, IOPS, EP, NPROC i inode dla tego pakietu. Jeśli podajecie PHP workers, proszę również wyjaśnić, co dokładnie oznacza ten parametr w Waszej konfiguracji i czy dotyczy całego konta, domeny czy osobnej puli. Proszę też wskazać, gdzie po zakupie można sprawdzić bieżące i historyczne wykorzystanie tych zasobów.
Operator może stosować również osobne ograniczenia bazy danych, np. przez MySQL Governor albo własną konfigurację. Jeśli baza jest istotna dla aplikacji, zapytaj również, czy obowiązują oddzielne limity MySQL i jak są mierzone.
Takie pytanie jest bardziej użyteczne niż ogólne „czy hosting nadaje się do WordPressa?”. Operator może odpowiedzieć konkretnymi wartościami, które później da się porównać z inną ofertą.
Gdzie po zakupie sprawdzać wykorzystanie zasobów?
Na cPanelu z CloudLinux operator może udostępnić ekran CPU and Concurrent Connection Usage, czyli widok wykorzystania zasobów konta, który dostawca może włączyć lub wyłączyć.
CloudLinux przechowuje również statystyki średnie, maksymalne i liczniki faults dla różnych zasobów. Narzędzia CloudLinux raportują osobno między innymi CPU, PMEM, NPROC, EP, I/O i IOPS oraz odpowiadające im limity i liczniki zdarzeń.
Przed zakupem warto więc zapytać nie tylko o sam limit, ale również o dostęp do historii wykorzystania. Parametr, którego nie można później obserwować, jest trudniejszy do wykorzystania przy diagnozie.
Czy warto wybierać pakiet po najwyższych limitach?
Nie ma sensu kupować największych wartości każdego parametru bez związku z potrzebami strony. Wyższe limity zwiększają zapas, ale nie naprawiają wolnych zapytań SQL, błędów aplikacji, zewnętrznego API ani złej konfiguracji cache.
Z drugiej strony bardzo niski przydział zasobu może stać się wąskim gardłem nawet dla poprawnie działającej aplikacji. Dlatego najlepsze porównanie opiera się na znanym scenariuszu: typie strony, ruchu, wcześniejszych problemach i danych z obecnego hostingu, jeśli takie są dostępne.
Jeżeli WordPress już działa i jest wolny, najpierw przejdź przez diagnostykę wolnego WordPressa. Jeżeli dopiero wybierasz hosting, skup się na jawności limitów i możliwości ich późniejszego monitorowania.
Jak porównać dwa pakiety bez udawania, że liczby mówią wszystko?
Najpierw ujednolić zakres danych. Porównuj CPU do CPU, PMEM do PMEM, I/O do I/O i IOPS do IOPS. Jeżeli jedna firma podaje PHP workers, a druga tylko EP, nie traktuj tych liczb jak bezpośrednich odpowiedników.
Następnie dodaj warunki, które nadal mają znaczenie dla wyboru: cenę odnowienia, pojemność, backup, wersje PHP, pocztę i zasady migracji. Limit techniczny jest jednym kryterium, nie pełną oceną usługi.
Do zestawienia ofert możesz użyć porównywarki hostingu. Koszt pierwszych lat opisuje poradnik o cenie pierwszego okresu i odnowieniu, a potrzebną pojemność policzysz w kalkulatorze przestrzeni. Po zebraniu wymagań możesz też dobierz hosting do swoich wymagań.
Jeśli masz już wybrany konkretny pakiet, możesz sprawdzić plan hostingowy przed zakupem: zobaczyć, które parametry mamy potwierdzone i o co warto zapytać operatora.
Krótka checklista przed zakupem hostingu
- Sprawdź cenę pierwszego okresu i odnowienia.
- Ustal potrzebną pojemność strony, baz i poczty.
- Poproś o CPU/SPEED i sposób jego liczenia.
- Ustal, co oznacza podany RAM i czy jest to PMEM konta.
- Jeśli oferta podaje PHP workers, poproś o ich definicję.
- Sprawdź EP i NPROC, jeśli operator korzysta z CloudLinux.
- Sprawdź I/O i IOPS zamiast opierać się wyłącznie na haśle SSD/NVMe.
- Sprawdź limit inode, szczególnie jeśli konto będzie przechowywać pocztę, cache, backupy albo wiele stron.
- Zapytaj, czy po zakupie zobaczysz historię wykorzystania zasobów.
- Dopiero potem porównaj wyższy pakiet z konkretnym ograniczeniem, które rzeczywiście może mieć znaczenie dla Twojej strony.
Najlepsza oferta nie musi mieć najwyższej liczby przy każdym limicie. Ważniejsze jest, żeby operator jasno określał parametry, pozwalał sprawdzić ich wykorzystanie i dawał zasoby odpowiadające rzeczywistemu sposobowi działania strony. Taki zestaw danych można później wykorzystać zarówno przy zakupie, jak i przy diagnozie problemów.