Dlaczego hosting współdzielony nie utrzyma sklepu
Opselis
Pakiet z porównywarki obiecuje WooCommerce i PrestaShop. Dostajesz klatkę LVE: ułamek CPU, wspólny dysk i MySQL sąsiada. Jak zmierzyć limit i kiedy zejść na własną VM.
Hosting współdzielony z porównywarki to pakiet: domena, skrzynka, cPanel albo DirectAdmin, PHP i MySQL na hoście z setkami innych kont. Oferta obiecuje WooCommerce albo PrestaShop w kilka kliknięć. Zasób, który kupujesz, to limit LVE: CPU, RAM, I/O, entry processes, inode. To nie jest rdzeń, którego nikt nie rusza. Checkout, indexer i pik kampanii potrzebują stałego kwantu procesora i bazy, której nie zjada sąsiad. Narzędziem jest panel Resource Usage oraz TTFB koszyka, nie gwiazdki w rankingu.
Do czego służy ten model
Konto współdzielone ma sens przy wizytówce, blogu i niskim ruchu. Jeden Apache albo LiteSpeed obsługuje wiele stron. Koszt jest niski, bo CPU, dysk i MySQL są overcommitowane. Sklep ma inny profil. PHP trzyma worker na czas requestu. InnoDB trzyma bufor. Cron i indexer chcą I/O w tle. Limit 100 procent CPU w panelu to często ułamek jednego vCPU z throttlingiem. Po przekroczeniu LVE request dostaje 508 albo czeka. Sąsiad, który odpala backup albo import XML, podbija await na tym samym wolumenie. Ty widzisz wolny koszyk. On mieści się w swoim limicie.
Magento Open Source na takim koncie zwykle nie wstanie porządnie: brak Redis i OpenSearch, cron ucinany, za mało workerów. WooCommerce i PrestaShop wstają. Przy kilkudziesięciu równoległych checkoutach padają na limicie procesów i na współdzielonej bazie.
Jak działa podział CPU i I/O
CloudLinux albo analog zamyka konto w klatce. CPU to procent fizycznego rdzenia, nie dedykowany core. Po limicie scheduler ucina, nie oddaje wolnego EPYC. RAM jest overcommitowany, potem swap hosta albo OOM konta. I/O ma pułap MB/s i liczby operacji. Entry processes mówią, ile PHP może pracować naraz. Inodes liczą pliki, nie gigabajty. Katalog ze zdjęciami i cache obrazków wyczerpuje inode wcześniej niż miejsce na dysku.
MySQL często stoi na osobnym hoście współdzielonym. `max_connections` i `innodb_buffer_pool` są wspólne. Wolny SELECT sąsiada trzyma lock, Twój checkout czeka. Nie zrestartujesz mysqld. Nie przeniesiesz tabeli na inny wolumen.
Nie masz root. `lscpu` i `vmstat` albo nie ma, albo pokazują hosta, nie Twoją klatkę. Steal time z wpisu o tanim VPS tu nawet nie zobaczysz. Panel sprzedawcy rysuje 40 procent CPU. Klatka już throttluje.
Jak sprawdzić i kiedy zejść
W cPanel: Metrics, Resource Usage. CPU, I/O, entry processes i RAM z ostatnich 24 h, w godzinie kampanii, nie w nocy. Entry processes przy 80 do 100 procent przy zwykłym ruchu dyskwalifikują konto pod sklep. `php -i` albo panel: `memory_limit`, `max_execution_time`. Magento prosi o 2 GB i cron co minutę. Konto ze 128 MB i cronem co 30 minut nie utrzyma indeksu.
Zmierz TTFB na `/checkout` i na listingu z filtrami, z cache i bez. Homepage z CDN nic nie mówi. Jeśli nie wgrasz Redis, Varnish i osobnej bazy, nie dokładasz wtyczki cache. Zmieniasz model: VPS z nazwaną rodziną CPU, VM na Proxmox albo instancja w chmurze. Opieka stacku: ecommerce. Gdy masz root: polecenia Linux. Eskalacja, gdy sklep stoi: kolejka supportu.