Quand une machine seule ne suffit plus
Boutique en ligne, site événementiel ou vitrine sous forte affluence : la solution est construite sur mesure, en fonction de ce que votre application demande réellement. Hébergeur depuis 2001.
- Hébergements distribués et dédiés, dans plusieurs centres de données
- Caches, bases spécialisées et files de messages selon le besoin
- Cluster à ressources dédiées, haute disponibilité native
- Sauvegarde possible toutes les 15 minutes
Le principe
Regarder l’application avant de dimensionner la machine
Le moment d’y venir
Il n’y a pas de seuil chiffré, mais trois symptômes reviennent. Les pages ralentissent aux heures de pointe alors qu’elles sont rapides le reste du temps. La base de données devient le goulot, et ajouter du cache de page n’y change plus rien. Ou bien une opération commerciale — soldes, campagne, passage média — concentre en deux heures le trafic d’un mois.
Dans les deux premiers cas, il arrive que la réponse ne soit pas une machine plus grosse mais une architecture différente : un cache au bon endroit, une base spécialisée pour la recherche, une file pour sortir les traitements lourds du temps de réponse. C’est ce que nous regardons avant de dimensionner.
Un hébergement bâti pour votre application
La maîtrise complète de notre infrastructure et notre présence dans plusieurs centres de données nous permettent de proposer des hébergements distribués et dédiés, dimensionnés selon vos contraintes.
Selon les besoins, nous déployons des caches avancés — Varnish, LiteSpeed Cache — des bases spécialisées comme MongoDB, Elasticsearch ou OpenSearch, et des caches en mémoire comme Redis, KeyDB ou Memcached. Si votre application repose sur une file de messages, nous savons mettre en place RabbitMQ ou NATS.
Nous pouvons également nous appuyer sur Cloudflare ou sur tout autre fournisseur de réseau de diffusion.
Serveur virtuel sur cluster
Notre technologie de cluster nous permet de vous allouer et de vous dédier processeur, mémoire et stockage. Ces machines virtuelles peuvent être sauvegardées toutes les 15 minutes si nécessaire, et la puissance s’ajoute rapidement.
La haute disponibilité est native : en cas d’avarie sur un nœud de traitement, un autre reprend l’exécution de votre machine virtuelle.
Cluster multi-datacenter
Pour les besoins les plus exigeants, deux datacenters physiques sont unifiés virtuellement pour n’en former qu’un. Toutes les machines virtuelles bâties sur cette architecture bénéficient alors d’une très haute disponibilité.
Où cela se place
C’est le dernier palier de nos hébergements, et il ne se justifie pas d’emblée :
- L’hébergement mutualisé couvre la grande majorité des sites, y compris des boutiques, avec des ressources dédiées et garanties.
- Un serveur privé répond au besoin de choisir sa configuration et ses versions, avec des ressources dédiées ; un serveur virtuel y ajoute son propre noyau, donc Docker, et la reprise par un autre nœud en cas de panne.
- Le fort trafic commence là où une machine seule ne suffit plus : quand il faut répartir la charge, doubler les nœuds, ou tenir un pic sans dégrader le service.
Si vous hésitez entre les trois, décrivez-nous votre trafic réel et ce que fait votre application. Il arrive que la réponse soit le palier d’en dessous.
Le tarif
Sur mesure : il dépend entièrement des ressources et de l’architecture retenues. Nous chiffrons après avoir regardé l’application, pas avant.
Le socle
Ce que nous déployons selon le besoin
-
Caches avancés
Varnish ou LiteSpeed Cache devant l’application : ce qui n’a pas besoin d’être recalculé ne l’est pas.
-
Bases spécialisées
MongoDB, Elasticsearch ou OpenSearch quand la recherche ou le volume mettent la base principale à genoux.
-
Caches en mémoire
Redis, KeyDB ou Memcached, partagés entre instances, pour que les sessions et les résultats coûteux ne soient calculés qu’une fois.
-
Files de messages
RabbitMQ ou NATS pour sortir les traitements lourds du temps de réponse : le visiteur n’attend plus l’export ni l’e-mail.
-
Cluster à ressources dédiées
Processeur, mémoire et stockage alloués et réservés, sauvegarde possible toutes les 15 minutes, puissance ajoutée rapidement.
-
Haute disponibilité native
En cas d’avarie sur un nœud, un autre reprend la machine virtuelle. Et en multi-datacenter, deux sites physiques n’en forment qu’un.
Questions fréquentes
Fort trafic : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
À partir de combien de visiteurs faut-il y passer ?
Il n’y a pas de seuil chiffré, et se fier à un nombre de visiteurs induit en erreur. Trois symptômes comptent : les pages ralentissent aux heures de pointe seulement, la base devient le goulot et le cache de page n’y change plus rien, ou une opération commerciale concentre en deux heures le trafic d’un mois.
Une machine plus puissante ne suffirait-elle pas ?
Parfois si, souvent non. Quand la base est le goulot, doubler le processeur ne fait que déplacer l’attente. La réponse est alors une architecture différente : un cache au bon endroit, une base spécialisée pour la recherche, une file pour sortir les traitements lourds du temps de réponse. C’est ce que nous regardons avant de dimensionner.
Que se passe-t-il si un serveur tombe ?
La haute disponibilité est native sur notre cluster : en cas d’avarie sur un nœud de traitement, un autre reprend l’exécution de votre machine virtuelle. Pour les besoins les plus exigeants, deux datacenters physiques sont unifiés virtuellement pour n’en former qu’un.
Combien ça coûte ?
Sur mesure : le tarif dépend entièrement des ressources et de l’architecture retenues. Nous chiffrons après avoir regardé l’application, pas avant — annoncer un prix sans savoir ce que fait le code reviendrait à le deviner.
Sommes-nous sûrs d’en avoir besoin ?
Pas forcément, et nous vous le dirons. Le mutualisé à ressources dédiées couvre la grande majorité des sites, y compris des boutiques ; un serveur privé répond au besoin de choisir sa configuration. Le fort trafic commence là où une machine seule ne suffit plus. Décrivez-nous votre trafic réel : il arrive que la réponse soit le palier d’en dessous.
Que se passe-t-il exactement quand ça ralentit ?
Les pages, la base, ou un traitement précis ? La réponse oriente l’architecture — et décide si vous avez besoin de ce palier ou du précédent.