Który hosting wybrać — Hosting WWW (shared), VPS czy Serwer Dedykowany?

Wprowadzenie — prosty wybór, wiele zmiennych

Wybór między hostingiem WWW (shared), VPS (Virtual Private Server) a serwerem dedykowanym nie powinien być emocjonalny ani “czytałem gdzieś, że…”. To decyzja techniczno-biznesowa — zależy od ruchu strony, charakteru aplikacji (statyczna strona, WordPress, sklep e-commerce, aplikacja webowa), wymagań bazy danych, poziomu bezpieczeństwa, budżetu i zasobów do utrzymania serwera.

Poniżej znajdziesz:

• jak porównywać te opcje wg konkretnych metryk (CPU, rdzenie, RAM, I/O, sieć),
• modele estymacji obciążenia (konkretne przykłady),
• zalety i wady każdego modelu,
• checklistę decyzji i rekomendacje.

Krótkie przypomnienie: co to jest każdy model

Hosting WWW (shared hosting)

• Jeden fizyczny serwer dzieli wielu klientów. Panel (np. cPanel/DirectAdmin) upraszcza zarządzanie kontem.
• Zasoby (CPU, RAM, I/O) współdzielone. Operator zwykle ogranicza limity (procesy PHP, inodes, mailbox size).
• Zalecany dla małych stron, blogów, prostych stron firmowych.

VPS (Virtual Private Server)

• Wirtualna maszyna z przydzielonymi zasobami (vCPU, RAM, dysk). Izolacja jest lepsza niż w shared, masz root/administrator.
• Możliwość dopasowania stacku (NGINX, PHP-FPM, MariaDB) i instalacji własnych usług.
• Dobre dla średnich serwisów, sklepów o umiarkowanym ruchu, aplikacji.

Serwer Dedykowany

• Cały fizyczny serwer na wyłączność. Maksymalna kontrola nad sprzętem i konfiguracją.
• Najlepsze dla ciężkich baz danych, dużego ruchu, specyficznych wymagań (np. NVMe RAID, duża pamięć RAM).
• Wyższe koszty i potrzeba administracji (lub wykupionego managed service).

Jakimi metrykami się kierować — techniczne kryteria

CPU: częstotliwość vs liczba rdzeni

• Częstotliwość (GHz) wpływa na wydajność pojedynczego wątku. Dla aplikacji wysoko-jednowątkowych (np. niektóre skrypty PHP, single-threaded tasks) ważny jest szybki rdzeń.
• Liczba rdzeni (i wątki/Hyper-Threading) decyduje o zdolności do równoczesnej obsługi wielu zapytań / workerów (np. wiele procesów PHP-FPM, wiele zapytań DB).
• Zasada praktyczna: jeśli masz wiele równoczesnych użytkowników/workerów (np. e-commerce, API) — więcej rdzeni; jeśli aplikacja ma ciężkie operacje single-threaded — lepszy pojedynczy clock.

RAM

• Krytyczny dla serwerów baz danych (buffer pool dla MySQL/MariaDB/InnoDB), cache’ów (Redis/Memcached) i równoczesnych procesów.
• Zasada: baza > 1 GB => daj DB co najmniej 25–50% więcej RAM niż rozmiar aktywnych working set; dla MySQL/InnoDB wartość innodb_buffer_pool_size powinna zbliżać się do rozmiaru aktywnej części danych (ale nie dopełniać całego RAMu).

Dysk i I/O (IOPS)

• Rodzaj dysku (HDD vs SSD vs NVMe) i konfiguracja (RAID10, RAID1) dramatycznie wpływają na wydajność bazy i latencję I/O.
• Dla baz produkcyjnych i sklepów: NVMe lub szybkie SSD z RAID10/enterprise controller. Małe VPSy z wolnym dyskiem mogą stać się wąskim gardłem.

Sieć (bandwidth, throughput, latency)

• Uplink 1 Gbps to dziś standard dedykowanych serwerów; VPSy w cloudach mogą mieć ograniczony throughput lub wspólny uplink.
• Dla mediów (video, pliki do pobrania) i dużego ruchu konieczne jest planowanie transferu i ewentualny CDN.

Ilość jednoczesnych połączeń / współbieżnych zapytań

• Ważna dla konfiguracji PHP-FPM / workerów serwera WWW

• Przyjmuje się, że przy dynamicznych stronach bez agresywnego cache’a dużym problemem jest liczba jednoczesnych PHP-FPM workers. Kalkuluj ją względem pamięci jednego worker’a * liczba worker’ów < dostępny RAM.

Jak oszacować obciążenie — praktyczne wzory i przykład

Podstawna formuła przybliżająca liczbę konkurentnych użytkowników (simultaneous users)

concurrent ≈ (daily_visits × avg_session_duration_seconds) / (24×3600)

Przykład A — mały blog:

• 5 000 odwiedzin / miesiąc → ≈167 odwiedzin / dzień
• średnia sesja: 90 s
• concurrent ≈ (167 × 90) / 86400 ≈ 0.17 → praktycznie zawsze < 1 równoczesny użytkownik → Hosting WWW jest OK.

Przykład B — średni portal firmowy:

• 50 000 odwiedzin / miesiąc → 1 667 / dzień
• średnia sesja 120 s
• concurrent ≈ (1 667×120)/86400 ≈ 2.3 → sporadycznie 2–5 równoczesnych użytkowników → VPS (2 vCPU, 4–8 GB RAM) z cache i CDN.

Przykład C — sklep e-commerce:

• 200 000 odwiedzin / miesiąc → 6 667 / dzień
• średnia sesja 180 s (więcej interakcji)
• concurrent ≈ (6667×180)/86400 ≈ 13.9 → realne 10–50 równoczesnych użytkowników podczas peaków → zalecany VPS wysokiej klasy lub serwer dedykowany; najlepiej skalowalna infra: load-balancer + 2–4 web nodes (po 4–8 vCPU), DB na dedykowanym serwerze z 32–64 GB RAM i NVMe RAID10.

Jak liczyć potrzebne worker’y PHP-FPM

• Jeden worker zużywa X MB RAM (zmierzony empiricznie w testowym środowisku).
• workers = floor( (available_RAM_for_php) / (avg_worker_memory_MB) )

Przykład: jeśli worker ≈ 50 MB, i masz 4 GB RAM, ale 2 GB musisz zostawić na DB i system -> available = 2 GB = 2048 MB → workers ≈ 2048/50 ≈ 40 (teoretyczne). Realnie weź 30–35, zostaw nadmiar na nagłe wzrosty.

Rekomendacje wg scenariuszy (konkretne konfiguracje)

1) Mały blog / strona firmowa (5–20k odwiedzin/miesiąc)

• Rekomendacja: Shared hosting (hosting WWW) lub mały VPS.
• Przykład spec: Shared z 1-2 GB RAM, PHP 8.x, opcja HTTP/2, SSD.
• Dlaczego: najtańsze, bez admin-overhead, panel, automatyczne backupy i SSL.

2) Rosnący portal / mały e-commerce (50–200k odwiedzin/miesiąc)

• Rekomendacja: VPS (cloud or KVM) lub managed VPS.
• Przykładowe zasoby: 4 vCPU @ 2.5–3.0 GHz, 8–16 GB RAM, NVMe 80–200 GB, wejście 1 Gbps, opcjonalny managed DB.
• Dlaczego: potrzeba izolacji, możliwość tuningu PHP-FPM i DB, skalowanie pionowe.

3) Duży sklep, aplikacja z dużą bazą (200k+ odwiedzin/miesiąc, DB > 10–50 GB)

• Rekomendacja: architektura rozproszona: dedykowany serwer DB (NVMe RAID10, 32–128 GB RAM), web nodes (VPS/VM z 4–8 vCPU, 16–32 GB RAM) za load balancerem; CDN do assetów.
• Przykład phys server spec DB: 8-16 rdzeni @ 3.0+ GHz, 64 GB RAM, 2×NVMe RAID1 (plus backup target).
• Dlaczego: DB intensywnie I/O-bound; dedykowany sprzęt minimalizuje latencję i zapewnia wysokie IOPS.

4) Aplikacje krytyczne/mające specjalne wymagania (np. finansowe)

• Rekomendacja: serwer dedykowany + zarządzanie (managed), własne SAN/NAS dla backupów, dedykowane łącze, audyty bezpieczeństwa.
• Dodatkowo: rozwiązania HA (replication), DR (disaster recovery).

Zalety i wady — szybkie porównanie

Shared hosting (hosting WWW)

• Plusy: niski koszt, brak administracji, prostota, automatyczne aktualizacje, kopie zapasowe.
• Minusy: ograniczona kontrola, współdzielone zasoby → ryzyko noisy neighbor, ograniczenia w konfiguracjach servera.

VPS

• Plusy: izolacja, root access, elastyczność, łatwość skalowania pionowego, przyzwoity koszt.
• Minusy: wymaga pewnej wiedzy admina (konfiguracja, bezpieczeństwo) lub dodatkowego managed support; I/O może być współdzielone w niektórych providerach.

Serwer dedykowany

• Plusy: pełna kontrola, maksymalna wydajność I/O i CPU, najlepszy dla dużych DB i aplikacji krytycznych.
• Minusy: koszt, odpowiedzialność za utrzymanie, skalowanie poziome wymaga architektury rozproszonej.

Optymalizacje, które zmniejszają wymagania zasobów

Zanim podniesiesz klasę usług — spróbuj optymalizacji:

• Cache na poziomie edge i serwera: CDN + cache HTTP + Redis/Memcached.
• OPcache dla PHP: znacząco zmniejsza obciążenie CPU.
• Lazy loading i optymalizacja assetów (obrazy w WebP/AVIF, minify).
• Query tuning i indeksy w DB — często największe wąskie gardło.
• Asynchroniczne przetwarzanie zadań (queue worker) poza request-response path.

Te optymalizacje często pozwalają pozostać na VPS zamiast przechodzić na drogi dedykowany serwer.

Koszty — co wliczyć (TCO)

• Opłata za sam serwer (hosting plan, VPS instance, amortyzacja sprzętu).
• Transfer danych (liczony miesięcznie).
• Backup & storage (zimne kopie, replicae).
• Zarządzanie / admin (jeśli korzystasz z managed services).
• CDN i inne usługi (LoadBalancer, DDoS protection).
• Licencje (np. cPanel, Microsoft SQL, komercyjne DB).

Checklist przed wyborem

1. Jaka jest przewidywana liczba odwiedzin miesięcznie i peaków (RPS)?
2. Jaka jest wielkość bazy danych i charakter zapytań (read-heavy vs write-heavy)?
3. Ile jednoczesnych użytkowników/workerów spodziewasz się?
4. Czy aplikacja jest cache-friendly? Czy możesz zredukować load przez cache?
5. Jaki jest budżet CAPEX/OPEX i poziom wsparcia, którego potrzebujesz?
6. Czy potrzebujesz SLA, dedykowanego łącza lub compliance (RODO, PCI)?
7. Czy chcesz mieć pełną kontrolę nad stackiem (root) czy wolisz „bezobsługowy” serwis?

Garść ciekawostek i praktycznych porad

• “Noisy neighbor” — w shared hosting i niektórych VPSach spotykasz problem: inny kontener może zająć I/O i spowolnić całe hosty. Monitoruj IOPS i dyskowy latency.
• CPU bursts vs sustained — niektóre VPSy dają burst CPU (krótkie okresy wysokiej częstotliwości). Jeśli masz długotrwałe obciążenie — wybierz instance z gwarantowanymi vCPU.
• Caching potrafi zredukować koszty o rząd wielkości — przerzucenie assetów na CDN i ustawienie cache-control zmniejsza wymogi na CPU i I/O.
• RDS / managed DB — w chmurach wiele firm korzysta z managed DB (AWS RDS, Managed MariaDB) by odseparować skomplikowane backupy i replikacje od web nodes.
• Testuj w warunkach zbliżonych do produkcji — load testy (k6, JMeter) odpowiednio skonfigurowane wykryją bottleneck zanim klienci to odczują.

Podsumowanie i rekomendacja skrócona

• Mały / prosty serwis (do ~20k odwiedzin/miesiąc): Shared hosting — najprostszy i najtańszy wybór.
• Średni serwis / rosnący sklep (20k–200k/mies.): VPS lub managed VPS — elastyczność i kontrola. Zainwestuj w NVMe i 8–16 GB RAM dla e-commerce.
• Duży ruch, duża baza, wymagania I/O: architektura rozproszona + dedykowany serwer DB lub dedykowany serwer aplikacyjny (RAID10 NVMe, 32–128 GB RAM).
• Krytyczne aplikacje: dedykowany + managed security + DR/HA.