Annonce concernant la stabilité du service

[MassiveHoster]

Nous avons reçu cette nuit plusieurs notifications mentionnant des pics de charge sur l'infrastructure actuelle.

L'analyse des logs est claire :
l'utilisation faite du service est dans la norme, mais nous atteignons les limites de ressources de l'infrastructure actuelle. Autrement dit, nous venons de rencontrer le plafond de l'infrastructure actuelle. 
Ces données complètes et fiables sont d'ailleurs l'occasion de faire les comptes et d'évaluer concrètement la rentabilité du projet qui, nous pouvons déjà vous le dire, est positive ✔️ sans pour autant être gargantuesque. 

Cette évaluation va nous permettre d'aller de l'avant ! 

À très court terme (en urgence même !) nous devons déployer globalement notre solution de « Cache Booster », déjà en test sur un échantillon de sites depuis quelques semaines. Ce déploiement sera accompagné d'une automatisation qui encourage par e-mail chaque site WordPress dénué de plugin de cache à activer AccelerateWP ou toute autre solution de cache. 

L'objectif de cette ultime action vise à stabiliser la consommation de ressources de l'infrastructure actuelle. 

En parallèle, nous allons planifier, dès la semaine prochaine, le provisionnement de deux fois plus de ressources pour satisfaire la demande élevée de nouveaux plans d'hébergement. Demande qui risque encore de croître pendant les mois d'octobre et novembre qui, de notre expérience, sont assez intenses dans le secteur de l'hébergement web. 

En résumé, le projet passe les étapes et suit son cours, avec quelques balbutiements inévitables en cours de route, bien qu'il offre un rapport qualité-prix qui reste très correct pour une première année de vie, il nous semble ? 🤔

À ce stade et avec toute l'expérience acquise sur ce format, nous espérons que l'année prochaine sera encore meilleure pour MassiveHoster et ses utilisateurs. 

Nous vous tiendrons informés ici lorsque les différents déploiements auront été réalisés. 

Souhaitez-nous bonne chance ! 

Merci pour votre confiance 🙏

[MassiveHoster]

[Update 📢]

Fin de semaine dernière, nous avons communiqué sur le fait que nous avions constaté des perturbations qui nous ont conduit à déterminer qu'il était temps de scaler techniquement l'infrastructure :

rien d'anormal en termes d'utilisation, nous avons simplement rencontré la limite de ce qui pouvait être encaissé avec les moyens mis en place.

Bien que de nouvelles optimisations vont venir alléger la charge du serveur sous 48h (cf. « Cache Booster », voir ci-dessous), nous devons ASAP doubler les ressources à disposition pour assumer les nouvelles commandes qui arrivent en nombre à un rythme inattendu !

Les travaux finaux sur la V1 de notre « Cache Booster » sont en cours (là, en ce moment...).

Ce système développé en interne va notamment placer la plupart des « wp-content/cache » et cache PrestaShop sur une partition séparée disposant de sa propre bande passante I/O, afin d'alléger le reste et offrir plus de réactivité à la plupart des sites mis en cache.

Les graphiques et logs de ce lundi matin sont une seconde confirmation qu'il n'est pas trop tôt pour passer à cette 2e phase (détails ci-dessous).

Tous ces travaux sont en cours et nous faisons au plus vite !

Dans l'intervalle, malheureusement, certaines perturbations inhabituelles peuvent encore être constatées.

Par exemple, en lisant les rapports de ce lundi matin, nous avons pu constater qu'hier soir, des lenteurs ont été expérimentées sur notre infrastructure pendant exactement 25 minutes :

- à 22:00,
tous les dimanches, nous lançons un second backup complet de toutes les bases de données MySQL.

Ce second système de backup développé en interne est hebdomadaire et est utile pour notre second DRP, car chez MassiveHoster, nous n'avons pas seulement un, mais deux DRP pour sécuriser vos données au cas (rare) où le premier système de backup (JetBackup5) serait éventuellement défaillant.

On s'inspire de la règle du 3-2-1 pour les sauvegardes, pour ne jamais avoir à dire à un client que nous avons perdu ses données 💀 😱

C'est cher, mais dormir tranquille n'a pas de prix !

- à 23:12,
le serveur a expérimenté une charge trop élevée due à un cumul de "consommation légitime" de nos utilisateurs, alors que le backup de toutes les bases MySQL était toujours en cours...

- à 23:15,
notre script de surveillance de charge automatisé à "*/5" (vous savez, celui développé récemment) a été alerté et s'est mis en mode surveillance avancée

- à 23:20,
voyant que la charge du serveur ne revenait pas à la normale, notre script a mis le serveur en mode « protection » pour éviter un DOWN en réduisant la charge générée par les utilisateurs du serveur et les principaux processus consommateurs.

(c'est le moment où, sans une telle automatisation, un technicien aurait dû sortir du lit pour agir à la main)

- à 23:37,
la charge du serveur était revenue en dessous du seuil critique, et la vie du serveur a progressivement repris son cours normalement...

- à 1:38,
le backup des bases MySQL s'est terminé avec succès, laissant place au backup des fichiers, planifié à 2h, et qui était encore en cours (à 7:58 au moment d'écrire ce rapport), car défini en basse priorité (donc volontairement lent).

Donc, désolé à tous pour les quelques perturbations expérimentées hier soir 🙏 Elles sont directement liées au fait que l'infrastructure soit pleinement utilisée depuis moins d'une semaine, alors que nous n'avons pas encore eu le temps de finaliser les toutes dernières optimisations.

Nous sommes conscients que la situation actuelle peut générer des perturbations aux moments où des tâches lourdes sont exécutées en parallèle, comme ici, pendant les indispensables backups MySQL... ce qui n'est pas normal, et c'est en cours de résolution 🤞

Le déploiement d'une seconde infrastructure a déjà débuté...

Cependant, puisque nous faisons le choix de configurer nos serveurs manuellement (les technologies évoluant très vite) pour éviter toute erreur d'automatisation et conserver la meilleure qualité possible, ce travail nécessite plusieurs jours :
entre 5 et 10 jours pour pouvoir annoncer un nouveau serveur 100% stable et suffisamment testé.

L'équipe est sur tous les fronts et est au maximum pour continuer de vous offrir un service aussi stable et performant que possible sur ce format, jeune et à tarifs compétitifs.

Le support est disponible par Ticket et/ou DM pour tout complément.

Merci pour votre patience et collaboration... on y retourne ! 🔥

[MassiveHoster]

[Annonce & Opportunité]

IMPORTANT pour tous les utilisateurs MassiveHoster.

Nous y sommes et grâce à votre collaboration, nous allons pouvoir mitiger la surcharge d'infrastructure que nous n'avions pas pu anticiper !

L'infrastructure de base dont nous ne pouvions connaître les limites réelles a atteint sa pleine capacité début-octobre, alors que nous étions toujours en train de finaliser quelques dernières optimisations pour les performances des sites hébergés, inclut la fin du développement de notre « Cache Booster » : partition ultra-rapide aux ressources dédiées au stockage de vos fichiers "wp-content/cache".

Nous n'avons pas attendu très longtemps pour conclure que l'infrastructure avait atteint sa capacité idéale, mais un choix se présentait à nous...

Dans quel ordre réaliser ces actions ?

① finaliser le déploiement du Cache Booster qui devait stabiliser l'infrastructure en réduisant la charge sur la partition principale

② stopper les améliorations et scaler immédiatement l'infrastructure en doublant les ressources à disposition

Puisque la première option semblait bien plus rapide à déployer et avec effet immédiat sans devoir solliciter la collaboration de nos hébergés, nous avons choisi de mettre le focus sur la finalisation en urgence du Cache Booster.

Mais c'était sans compter sur la complexité actuelle des plugins de cache WordPress.

Ce qui devait être une simple automatisation d'un déplacement de dossier s'est transformé en un système complexe :
~ 5000 lignes de code,
8 scripts indépendants,
génération de fichiers de processing en CSV...
le tout basé en grande partie sur des commandes WP CLI exécutées individuellement sur les comptes utilisateurs via "su", pour chaque instance de Cache Booster 😵�💫

Aujourd'hui, le système fonctionne bien et les résultats côté performance sont assez impressionnants sur la visite de cache à froid. Certains tests de TTFB sont presque divisés par 10.

Le problème, c'est le temps.

Les imprévus ont allongé le délai de déploiement du Cache Booster et donc, le temps que nous pouvions allouer au scaling de l'infrastructure.
Pendant ce temps-là, environ 20 sites WordPress se créaient chaque jour sur l'infrastructure déjà borderline... de nouveaux sites embarquant tous des CRONs et du trafic qui, chaque jour, ont rajouté de la pression sur l'infrastructure existante. Pression que hélas, le Cache Booster n'a pas su compenser une fois déployé sur +80% des sites WordPress hébergés disposant d'un plugin de cache, malgré un très joli gain de performances sur les pages en cache.

Le souci, c'est que la consommation des ressources d'un serveur ne se limite pas à l'immense majorité du trafic / des visiteurs qui sont servis :
il y a les requêtes MySQL exécutées par les sites en arrière plan ;
les sauvegardes de données ;
le scan des fichiers anti-malware ;
l'import de produits eCommerce et d'innombrables autres types de tâches... ♾

Face à l'expérience acquise, nous sommes forcés de le reconnaître... notre choix stratégique n'était pas le bon.

Si vous avions eu toutes ces informations dans les mains, nous aurions remis le Cache Booster à plus tard, et priorisé le déploiement d'une nouvelle infrastructure. Mais ça, nous n'aurions pas pu l'anticiper si facilement.

Résultat, nous venons d'expérimenter quelques jours d'instabilité avec des micro-coupures (pour la plupart) et dernièrement, une saturation plus sérieuse de MySQL, trop sollicité, dont l'usage augmente chaque jour sans solution de repli disponible ; ce qui crée des perturbations plus notables que nous mitigeons manuellement à chaque fois, mais qui restent évidemment inacceptables à moyen terme.

Nous nous excusons sincèrement pour cela.

Tout cela étant dit, nous sommes enfin prêts à vous proposer, à court terme, une stabilisation de votre situation individuelle en planifiant avec chaque utilisateur qui en fait la demande, le déplacement de leur(s) compte(s) vers la nouvelle infrastructure !

L'avantage pour vous ?

Une stabilisation rapide, car forcément, la nouvelle infrastructure n'est pas victime de surcharge et le trafic y sera calme pendant plusieurs mois.

L'avantage pour nous ?

Nous permettre de transférer les +15% de surplus de sites Web hébergés sur la première infra vers la seconde infra, et donc nous aider à stabiliser la situation globalement.

L'inconvénient pour vous ?

Hélas, même si le transfert des comptes complets est assuré par notre équipe en toute transparence (sites, mails, settings avancés, etc), il vous sera nécessaire d'apporter un changement à votre configuration * DNS * chez votre registrar (changement de * NS * ou * d'adresse IP *), dès que le changement de serveur sera confirmé par notre équipe.

Pour profiter du transfert de vos comptes vers la nouvelle infra, veuillez ouvrir un Ticket au support (icône d'enveloppe sur la page d'accueil de notre site) et/ou envoyez un DM à @MassiveHoster en mentionnant l'adresse email de votre compte client pour nous aider à faire le lien.

L'équipe vous reviendra ensuite pour planifier le transfert au mieux et vous donnera tous les détails sur la manière de procéder.

Si vous êtes intéressé, ne tardez pas à nous le faire savoir, car comme vous pouvez le comprendre, l'offre de transfert reste plus particulièrement valable tant que la situation sur l'infrastructure d'origine n'est pas encore redevenue optimale.

Vous avez jusqu'au 28 octobre pour nous faire part de votre désir d'être migré si vous le souhaitez.

Si le changement de DNS est trop contraignant ou si vous pensez pouvoir patienter un peu plus, soyez sûr que tout est fait pour stabiliser l'ensemble (infra d'origine incluse) le plus rapidement possible... ! ✅

...après tout, il y a un peu plus de 3 semaines, alors que nous hébergions ~10% à 15% de sites en moins, l'infrastructure se portait plutôt bien.

Ces complications nous aurons appris une information essentielle :

« Où se situe notre limite avant de devoir scaler ? »

Nous savons maintenant, précisément, à partir de combien de plans d'hébergement "vendus" nous devons déclencher la création de nouveaux serveurs Web.

Et nous comptons bien nous servir de cette précieuse information pour améliorer le service fourni à moyen et à long terme, et éviter ce genre d'expérience très désagréable pour tout le monde !

L'équipe attend vos Tickets et DM sans tarder si vous êtes candidat pour un transfert 🤝😉

Merci pour votre collaboration et compréhension.

À très bientôt !