Wybór serwera
Przeprowadzono test na działającej instancji z rzeczywistym lejkiem i zmierzono wszystko. Wynik: nawet na najskromniejszym VPS za ~20 USD/miesiąc (4 vCPU / 8 GB) Qubix obsługuje ~1 900 wyświetleń landing page na sekundę — to dziesiątki milionów odwiedzin miesięcznie — każde w ~25 ms i bez żadnych błędów pod obciążeniem. Cała usługa zajmuje ~1,3 GB RAM, nie dopuszcza do wycieków pamięci i jest zbudowana z myślą o pracy 24/7.
To nie jest górna granica: na 12 rdzeniach osiąga się już ~6 800 wyświetleń na sekundę — przepustowość rośnie liniowo wraz z liczbą rdzeni.
Poniżej: jaki serwer wybrać przy danym ruchu oraz pełne wyniki testów stojące za tymi liczbami.
Jaki serwer wybrać
| Ruch (orientacyjnie) | Serwer | Przepustowość |
|---|---|---|
| do ~5M odwiedzin/dzień (szczyty do ~1 000/s) | 4 vCPU / 8 GB (~20 USD/mies.) | ~1 900 wyświetleń/s — zmierzone, landing w ~25 ms |
| ~5–15M/dzień (szczyty ~1 000–3 000/s) | 8 vCPU / 16 GB | ~4 000 wyświetleń/s — szacowane (~500 na rdzeń) |
| 15M+/dzień (szczyty 5 000+/s) | 12 vCPU / 16 GB | ~6 800 wyświetleń/s — zmierzone |
Prosta zasada: rdzenie ≈ szczytowa liczba odwiedzin na sekundę ÷ 500. 8 GB RAM wystarczy dla zalecanej konfiguracji, 16 GB zapewnia margines bezpieczeństwa.
Jaka jest przepustowość i jak ją zmierzono
Warunki testu:
- Testowany serwer: wirtualny serwer DigitalOcean — 4 vCPU / 8 GB, SSD, Debian 13 (kernel 6.12), region Frankfurt. Zwykła, niemodyfikowana maszyna za ~20 USD/miesiąc.
- Generator obciążenia: osobny serwer (12 rdzeni) — dzięki temu instancja poświęca zasoby wyłącznie na własną pracę, nie na sam test. Narzędzie — bombardier (HTTP z keep-alive), od 50 do 1000 jednoczesnych połączeń, 15–30 sekund na przebieg.
- Co testowano: działający, skonfigurowany lejek — rzeczywista domena serwująca cloakowany landing (~45 KB) z działającą decyzją cloakingową oraz postbacki konwersji.
- Co obserwowano: CPU, pamięć, swap i opóźnienia — w czasie rzeczywistym przez cały test.
- Na potrzeby skalowania ten sam test przeprowadzono na serwerze 12 vCPU / 64 GB.
Zalecany serwer, 4 vCPU / 8 GB:
| Typ żądania | Przepustowość | Opóźnienie | Błędy |
|---|---|---|---|
| Pełny landing (cloakowany, ~45 KB) | ~1 900/s | ~25 ms (nawet przy 250 równoległych — 0,13 s) | 0 |
| Postback konwersji | ~13 000/s | ~25 ms | 0 |
| Lekkie żądanie | ~16 000/s | ~20 ms | 0 |
Ani jeden błąd przy 1000 jednoczesnych połączeń. W warunkach przeciążenia instancja nie ulega awarii ani nie odrzuca żądań — rośnie jedynie opóźnienie (z ~25 ms do 0,13–0,26 s, gdy obciążenie znacznie przekracza nominał), a gdy szczyt mija, czas odpowiedzi wraca do normy.
Co ogranicza wydajność przy szczycie. Wszystkie 4 rdzenie pracują na poziomie 95–100% — ograniczeniem jest CPU, dlatego pojemność rośnie wraz z liczbą rdzeni. Pamięć pozostawała spokojna: około 1,1–1,3 GB pod obciążeniem, bez swapu, ponad 3,8 GB zawsze wolne.
Brak wycieków pamięci. Przeprowadzono osobno cztery cykle obciążeniowe pod rząd z przerwami i obserwowano pamięć: w stanie spoczynku usługa zużywała około 0,7 GB, w szczycie wzrastała do mniej więcej 1,2 GB, a w przerwach wracała do ~0,8 GB — bez kumulacji z cyklu na cykl. Instancja nadaje się do ciągłej pracy 24/7.
Skalowanie przez rdzenie. Ten sam test na serwerze 12 vCPU:
| Serwer | Pełny landing | Lekkie żądanie |
|---|---|---|
| 4 vCPU | ~1 900/s | ~16 000/s |
| 12 vCPU | ~6 800/s | ~80 000/s |
Przepustowość rośnie proporcjonalnie do liczby rdzeni — około 500 wyświetleń landing page na sekundę na vCPU (zmierzone: od 475 do 567). Stąd powyższa zasada doboru rdzeni.
Z Cloudflare — jeszcze szybciej i bezpłatnie
Qubix obsługuje każdą domenę przez Cloudflare — globalną sieć serwerów — i przejmuje zarządzanie DNS oraz SSL. Szybsze ładowanie jest domyślnie włączone (można zarządzać w Ustawienia → Cloudflare): statyczne pliki witryny (skrypty, style, ikony i zrzuty ekranu) są dostarczane odwiedzającemu z najbliższego serwera Cloudflare.
- Znacznie szybciej dla odwiedzającego — pliki strony pochodzą z najbliższego serwera Cloudflare, a nie z serwera po drugiej stronie świata. Strony landing otwierają się niemal natychmiast na całym świecie.
- Kilkadziesiąt razy mniejsze obciążenie serwera — każda strona pobiera dziesiątki plików statycznych (skrypty, style, ikony, zrzuty ekranu), a Cloudflare dostarcza je ze swoich serwerów. Serwer obsługuje wyłącznie część dynamiczną — na tym samym sprzęcie można obsłużyć kilkadziesiąt razy więcej odwiedzających.
- Bezpłatnie — zarówno sieć Cloudflare, jak i cache nic nie kosztują, a Qubix konfiguruje wszystko automatycznie.
Część dynamiczna — decyzja cloakingowa i sam landing — nadal działa na serwerze (to dokładnie to, co mierzą powyższe liczby); Cloudflare zajmuje się wszystkim wokół niej. Więcej w Domeny.
Ile miejsca na dysku potrzeba
Przy pełnym obciążeniu — nagrywanie ekranu każdej wizyty, pełne statystyki i lejek oraz biblioteka kreacji — 20 GB obsługuje około 300 000 odwiedzin miesięcznie i wystarcza na lata: nagrania starsze niż rok są usuwane automatycznie, a historia ruchu przybywa zaledwie ~0,5 GB rocznie. Prawdziwym konsumentem dysku jest biblioteka kreacji (przechowywana na stałe): im większa biblioteka, tym więcej miejsca potrzeba. Nawet tu Qubix oszczędza przestrzeń — ta sama kreacja nigdy nie jest przechowywana dwukrotnie (deduplikacja wychwytuje nawet nieznacznie zmienione kopie), a ta sama funkcja napędza statystyki (jedna kreacja w setkach reklam liczy się jako jedna, ze zbiorczym ROAS). 20 GB to około 2 500 filmów lub 30 000 obrazów; przy znacznie większej liczbie (milion kreacji to już terabajty) należy wybrać proporcjonalnie większy dysk — który można powiększyć w dowolnym momencie.
SSD czy HDD — tutaj można zaoszczędzić. Strony otwierają się dla odwiedzających jednakowo szybko na dowolnym dysku, więc można bezpiecznie wybrać tańszy serwer HDD. Różnica między SSD a HDD widoczna jest wyłącznie w panelu administracyjnym i tylko przy dużych wolumenach: raporty odczytują historię z dysku i budują się nieco wolniej na HDD — nie wpływa to na szybkość otwierania landing page'ów dla odwiedzających.