Choisir son serveur
Nous avons soumis une instance en production à une charge réelle avec un funnel complet et tout mesuré. Résultat : même sur le VPS le plus modeste à ~20 $/mois (4 vCPU / 8 Go), Qubix sert ~1 900 pages d'atterrissage par seconde — soit des dizaines de millions de visites par mois — en ~25 ms chacune et sans la moindre erreur sous charge. L'ensemble du service tient dans ~1,3 Go de RAM, ne présente aucune fuite mémoire et est conçu pour fonctionner 24h/24, 7j/7.
Et ce n'est pas le plafond : sur 12 cœurs, on atteint déjà ~6 800 pages par seconde — le débit évolue linéairement avec le nombre de cœurs.
Ci-dessous : quel serveur choisir selon votre trafic, et les résultats complets des tests qui justifient ces chiffres.
Quel serveur choisir
| Votre trafic (approximatif) | Serveur | Débit |
|---|---|---|
| jusqu'à ~5 M visites/jour (pics jusqu'à ~1 000/s) | 4 vCPU / 8 Go (~20 $/mois) | ~1 900 pages/s — mesuré, chargement en ~25 ms |
| ~5–15 M/jour (pics ~1 000–3 000/s) | 8 vCPU / 16 Go | ~4 000 pages/s — estimé (~500 par cœur) |
| 15 M+/jour (pics 5 000+/s) | 12 vCPU / 16 Go | ~6 800 pages/s — mesuré |
Règle simple : cœurs ≈ pics de visites par seconde ÷ 500. 8 Go de RAM suffisent pour la configuration recommandée, 16 Go offrent de la marge.
Ce que ça supporte — et comment nous l'avons mesuré
Conditions du test :
- Serveur testé : un VPS cloud DigitalOcean — 4 vCPU / 8 Go, SSD, Debian 13 (noyau 6.12), région Francfort. Une machine ordinaire, sans configuration particulière, à ~20 $/mois.
- Générateur de charge : un serveur séparé (12 cœurs) — afin que l'instance ne consacre ses ressources qu'à son propre travail, pas au test lui-même. Outil : bombardier (HTTP avec keep-alive), montée de 50 à 1 000 connexions simultanées, 15 à 30 secondes par cycle.
- Ce que nous avons chargé : un funnel configuré en production — un vrai domaine servant une page d'atterrissage cloquée (~45 Ko) avec une décision de cloaking fonctionnelle, plus des postbacks de conversion.
- Ce que nous avons observé : CPU, mémoire, swap et latence — en temps réel tout au long du test.
- Pour la montée en charge, nous avons répété le même test sur un serveur 12 vCPU / 64 Go.
Serveur recommandé, 4 vCPU / 8 Go :
| Type de requête | Capacité | Latence | Erreurs |
|---|---|---|---|
| Page d'atterrissage complète (cloquée, ~45 Ko) | ~1 900/s | ~25 ms (même à 250 connexions simultanées — 0,13 s) | 0 |
| Postback de conversion | ~13 000/s | ~25 ms | 0 |
| Requête légère | ~16 000/s | ~20 ms | 0 |
Pas une seule erreur jusqu'à 1 000 connexions simultanées. En surcharge, l'instance ne plante pas et ne rejette pas de requêtes — seule la latence augmente (de ~25 ms à 0,13–0,26 s quand la charge dépasse largement le dimensionnement), et dès que le pic se dissipe, le temps de réponse revient à la normale.
Ce qui limite en pic. Les 4 cœurs tournent à 95–100 % — la limite est le CPU, ce qui explique pourquoi la capacité évolue avec le nombre de cœurs. La mémoire est restée stable : environ 1,1–1,3 Go sous charge, aucun swap, toujours plus de 3,8 Go libres.
Pas de fuite mémoire. Nous avons effectué séparément quatre cycles de charge consécutifs avec des pauses et observé la mémoire : au repos, le service utilisait environ 0,7 Go ; en pic de charge, il montait à environ 1,2 Go ; dans les pauses, il revenait à ~0,8 Go — sans accumulation d'un cycle à l'autre. L'instance est parfaitement adaptée à un fonctionnement continu 24h/24, 7j/7.
Montée en charge par cœurs. Le même test sur un serveur 12 vCPU :
| Serveur | Page complète | Requête légère |
|---|---|---|
| 4 vCPU | ~1 900/s | ~16 000/s |
| 12 vCPU | ~6 800/s | ~80 000/s |
Le débit évolue proportionnellement au nombre de cœurs — environ 500 pages d'atterrissage par seconde par vCPU (mesuré : 475 à 567). D'où la règle de dimensionnement en cœurs ci-dessus.
Avec Cloudflare — encore plus rapide, et gratuit
Qubix sert chaque domaine via Cloudflare — un réseau mondial de serveurs — et gère DNS et SSL à votre place. Le chargement accéléré est activé par défaut (gérez-le dans Paramètres → Cloudflare) : les fichiers statiques de votre site (scripts, styles, icônes et captures d'écran) sont servis au visiteur depuis le serveur Cloudflare le plus proche.
- Bien plus rapide pour le visiteur — les fichiers de la page proviennent du serveur Cloudflare le plus proche, pas de votre serveur à l'autre bout du monde. Les pages d'atterrissage s'ouvrent quasi instantanément partout dans le monde.
- Des dizaines de fois moins de charge sur votre serveur — chaque page charge des dizaines de fichiers statiques (scripts, styles, icônes, captures d'écran), et Cloudflare les sert depuis ses propres serveurs. Votre serveur ne traite que la partie dynamique — sur le même matériel, vous servez des dizaines de fois plus de visiteurs.
- Gratuit — le réseau Cloudflare et le cache ne coûtent rien, et Qubix configure tout pour vous.
La partie dynamique — la décision de cloaking et la page d'atterrissage elle-même — s'exécute toujours sur votre serveur (c'est exactement ce que mesurent les chiffres ci-dessus) ; Cloudflare prend en charge tout ce qui l'entoure. Plus d'informations dans Domaines.
Quelle capacité disque prévoir
À pleine utilisation — enregistrement d'écran de chaque visite, toutes les statistiques et le funnel, plus votre bibliothèque de créatifs — 20 Go couvrent environ 300 000 visites par mois et tiennent des années : les enregistrements de plus d'un an sont supprimés automatiquement, et l'historique du trafic n'ajoute que ~0,5 Go par an. Le vrai consommateur d'espace disque, ce sont vos créatifs (conservés en permanence) : plus la bibliothèque est grande, plus il faut de place. Qubix économise quand même de l'espace — il ne stocke jamais deux fois le même créatif (la déduplication détecte même les copies légèrement modifiées), et cette même fonctionnalité alimente vos statistiques (un créatif utilisé dans des centaines de publicités ne compte qu'une seule fois, avec un ROAS cumulé). 20 Go représentent environ 2 500 vidéos ou 30 000 images ; si vous en chargez beaucoup plus (un million de créatifs, c'est déjà des téraoctets), prenez un disque proportionnellement plus grand — que vous pouvez agrandir à tout moment.
SSD ou HDD — vous pouvez économiser ici. Les pages s'ouvrent aussi vite pour les visiteurs sur n'importe quel disque, vous pouvez donc opter sans risque pour un serveur HDD moins cher. La différence avec le SSD n'apparaît qu'à l'intérieur du panneau d'administration et uniquement à grands volumes : les rapports lisent l'historique depuis le disque et se génèrent un peu plus lentement sur HDD — cela n'affecte pas la vitesse de chargement des pages d'atterrissage pour les visiteurs.