- Bienvenue sur MassiveHoster Forum.
Libérez votre créativité
Messages récents
#11
Annonces officielles / Annonce concernant la stabilit...
Dernier message par MassiveHoster - Oct 02, 2025, 09:08 AMNous 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 🙏
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 🙏
#12
MassiveHoster Academy / Changer la version de PHP pour...
Dernier message par MassiveHoster - Sep 02, 2025, 09:51 AMIdéalement, vous allez gérer la version de votre compte d'hébergement MassiveHoster via le module PHP Selector (Select PHP Version / Sélectionner une version de PHP) accessible depuis l'accueil de votre panel.
Néanmoins, certains sites Web ajoutés en tant que « noms de domaine supplémentaires » dans un compte d'hébergement existant ou dans des sous-répertoires, pourraient avoir besoin d'une version de PHP différente de celle configurée au niveau du compte d'hébergement tout entier.
Pour cela, la syntaxe est la suivante (exemple pour PHP 5.6) :
Code à ajouter en haut du fichier .htaccess présent à la racine de votre site.
Les handlers PHP actuellement disponibles sur notre infrastructure sont les suivants :
Si le handler PHP de votre choix n'est pas présent dans cette liste, veuillez contacter notre support technique. Il se peut que nous devions ajouter une ligne à notre fichier de configuration interne.
Enfin, une fois appliqué, pour vérifier la version de PHP actuellement active pour votre site Web, vous pouvez créer une fichier .php contenant simplement cette ligne...
Néanmoins, certains sites Web ajoutés en tant que « noms de domaine supplémentaires » dans un compte d'hébergement existant ou dans des sous-répertoires, pourraient avoir besoin d'une version de PHP différente de celle configurée au niveau du compte d'hébergement tout entier.
Pour cela, la syntaxe est la suivante (exemple pour PHP 5.6) :
Code Sélectionner
<FilesMatch "\.(php4|php5|php3|php2|php|phtml)$">
SetHandler application/x-lsphp56
</FilesMatch>Code à ajouter en haut du fichier .htaccess présent à la racine de votre site.
Les handlers PHP actuellement disponibles sur notre infrastructure sont les suivants :
Code Sélectionner
application/x-lsphp56
application/x-lsphp70
application/x-lsphp71
application/x-lsphp72
application/x-lsphp73
application/x-lsphp74
application/x-lsphp80
application/x-lsphp81
application/x-lsphp82
application/x-lsphp83
application/x-lsphp84Si le handler PHP de votre choix n'est pas présent dans cette liste, veuillez contacter notre support technique. Il se peut que nous devions ajouter une ligne à notre fichier de configuration interne.
Enfin, une fois appliqué, pour vérifier la version de PHP actuellement active pour votre site Web, vous pouvez créer une fichier .php contenant simplement cette ligne...
Code Sélectionner
<?php phpinfo(); ?> #13
Support Technique / CPU, RAM, I/O : attention aux ...
Dernier message par MassiveHoster - Août 22, 2025, 05:01 PMOn nous demande souvent « Combien de CPU, de RAM et d'IO » sont offerts dans nos plans « MassiveHoster » « Classique » & « Premium ».
C'est une excellente question, mais la réponse est plus complexe qu'une poignée de chiffres.
• L'analogie de la voiture :
Comparer des hébergements uniquement sur les vCPU / RAM / IO est comme comparer 2 voitures uniquement sur leur nombre de chevaux (CV) sous le capot, sans regarder... :
le poids, le châssis, les pneus, la qualité du moteur, ou si les sièges sont en « cuir » plutôt qu'en « tissu ».
Une Formule 1 n'a pas le même potentiel de course qu'un tracteur, à puissance et CV équivalents.
Dans le monde de l'hébergement mutualisé, les chiffres sont souvent utilisés pour impressionner et appâter les clients. Mais tous les chiffres ne racontent pas toute l'histoire sur les performances et la stabilité que vous obtiendrez réellement chez votre hébergeur web.
Hélas, les grosses "fiches techniques" mises en avant sur les pages de vente des gros hébergeurs web mutualisés sont souvent trompeuses. C'est un fait.
Cet article a pour but de vous donner les clés pour vous aider à faire un choix éclairé et évaluer si tester MassiveHoster est un bon choix pour vous, ou pas.
Le "Jeu" de l'Overselling (ou survente) : comprendre les pratiques de certains (gros) hébergeurs web mutualisés
Entrons dans le vif du sujet...
• Qu'est-ce que l'overselling (ou la survente), pratique courante en hébergement web ?
Très simplement, c'est comme une compagnie d'assurance qui vend de nombreuses « couvertures santé » en espérant que la majorité de leurs clients ne tombent jamais malade.
Dans l'hébergement web, il s'agit de vendre (virtuellement) un total de ressources plus élevé que ce que les serveurs physiques n'en possèdent réellement.
Concrètement, lorsque l'hébergeur abuse de cette pratique et qu'il surcharge ses serveurs web, cela peut se traduire pour vous par des lenteurs inexpliquées, des erreurs 503 (Service Unavailable), 508 (Resource Limit Is Reached), des Timeouts ou des plantages de base de données ("Error establishing a database connection"), car le serveur est tout simplement surchargé.
• Étude de cas d'hébergeur n°1 : l'illusion des ressources "indépendantes" qui s'additionnent
Un certain hébergeur très connus en France propose des plans avec, par exemple soi-disant, "12 vCPU, 48 Go de RAM et 42 MB/s d'IO" pour chaque "compte isolé", avec la possibilité d'avoir "jusqu'à 8 comptes" pour un tarif de seulement 4,25€ par mois la première année (soit 51€ HT pour 12 mois).
Le calcul est simple :
• 12 vCPU x 8 = 96 vCPU !!
• 48 Go RAM x 8 = 384 Go RAM !!
• 42 MB/s d'IO x 8 = 336 MB/s d'IO !!
Même si vous n'êtes pas un expert en informatique, vous l'avez compris en comparant ces chiffres avec les caractéristiques de votre ordinateur... :
Aucun serveur d'hébergement web mutualisé ne peut garantir de telles ressources pour un seul client, d'autant que des centaines d'autres comptes sont souvent aussi hébergés sur ce type d'infrastructure « partagée », sur chaque serveur.
Cela prouve que ces ressources ne sont ni "indépendantes" ni "dédiées", mais au mieux, puisées dans un pool commun et partagé. Au pire, inventées de toutes pièces
La promesse est donc techniquement irréalisable.
Pour le dire autrement, si seulement 3 à 5 clients utilisaient à plein régime les ressources promises sur ce type de plan, le serveur entier serait déjà à genoux. Ce qui explique les instabilités constatées chez ce genre de fournisseur, par manque de cloisonnement
• Étude de cas d'hébergeur n°2 : le piège des limites techniques cachées
Un autre hébergeur très connu mondialement est aussi un champion du marketing !
Il attire les clients avec des engagements sur plusieurs années (jusqu'à 4 ans), à des prix très bas.
Leurs offres mettent en avant de nombreux Gigaoctets de stockage et de nombreux cœurs CPU.
Quel est le problème de ces caractéristiques mises en avant... ?
Les limites qui impactent vraiment la performance d'un site WordPress moderne (comme les IOPS ou « Opérations d'Entrée/Sortie par Seconde ») sont souvent absentes des pages de vente.
Pourtant et d'après nos observations, concernant les IOPS, il y a quelques mois cette information était bien visible. Mais elle a depuis été supprimée des pages publiques pour n'apparaître qu'une fois le service commandé !
Cependant, il faut savoir qu'un site avec un constructeur de page comme Elementor ou Divi peut être rapidement paralysé par une limite d'IOPS trop basse.
D'après notre expérience, les plans d'entrée de gamme de cet hébergeur se limitent à 128 IOPS, ce qui est largement insuffisant pour un site moderne et dynamique, avec un Constructeur de Pages (Page Builder), quelques plugins installés ou un peu trop de trafic quotidien.
Leur stratégie ?
Une fois que le client est engagé sur le long terme et que son site Web commence à prendre de l'ampleur (plus de contenus, de trafic et de plugins installés), les problèmes de lenteur ou d'erreurs timeout peuvent apparaître.
La seule solution pour ne pas perdre son investissement de départ serait alors de payer pour des "upgrades" successives vers les plans les plus chers.
C'est très malin. Mais, est-ce vraiment éthique ?
Face à de telles pratiques de marketing agressif, il est difficile pour tout hébergeur honnête de se positionner par rapport à des concurrents prêts à tout, par exemple dans un tableau comparatif qui se limiterait à comparer les caractéristiques autoproclamées par les fournisseurs eux-mêmes, comme une quantité de vCPU, RAM et I/O impossible à garantir, car démesurée.
Autrement dit,
Comment répondre à un prospect qui nous compare à un hébergeur qui a le culot d'annoncer garantir 96 vCPU de ressources dédiées indépendantes (!!) pour seulement 51€ HT la première année ?
Répondre à cela est exactement ce que nous allons tenter de faire ci-dessous.
Notre Philosophie chez MassiveHoster : transparence et performances !
Nos motivations ne nous ont pas guidé vers des choix "marketing",... mais des choix "techniques".
• Le choix de la performance brute : des serveurs physiques (Bare Metal)
Même si cela faciliterait grandement nos travaux de maintenance et réduirait nos coûts, nous avons choisi de ne pas utiliser de couche de virtualisation superflue qui dégrade les performances, comme sur les VPS (serveurs virtuels).
Il n'y a donc pas chez MassiveHoster d'intermédiaire logiciel entre vos sites et notre puissance matérielle brute, ce qui est plutôt inédit pour un hébergeur mutualisé grand public.
Nos serveurs sont des machines physiques puissantes dont les performances sont au minimum « AMD EPYC™ 32 Cœurs à 3.7GHz, 128 Go de RAM DDR4 ECC » sur lesquelles vos sites Web ont un accès on-ne-peut-plus direct aux ressources.
Le résultat est simple :
De meilleures performances et plus de stabilité !
D'ailleurs, le plan Premium de MassiveHoster vous offre des outils comme :
• Une allocation des ressources juste et dynamique
Plutôt que de vous promettre des chiffres virtuels et irréalistes, nous préférons nous assurer de la santé et des performances globales de notre infrastructure sur base de l'utilisation réelle qui en est faite de la part de nos utilisateurs, constatée sur le terrain.
Par le biais de nombreux mécanismes automatisés, nous surveillons en temps réel la charge et toutes les autres metrics de nos serveurs, afin d'éviter qu'un utilisateur ne puisse impacter négativement ses voisins et afin d'adapter dynamiquement les ressources allouées aux utilisateurs sur base de leur utilisation réelle (à condition qu'aucun abus n'ait été constaté sur l'un ou l'autre compte utilisateur).
Cette approche permet à nos utilisateurs d'encaisser des pics de trafic ponctuelles, tout en assurant le respect des autres utilisateurs d'un même serveur.
Notre promesse n'est donc pas un chiffre inscrit sur un bout de papier, mais une volonté de qualité de service réelle et un suivi constant.
MassiveHoster est-il fait pour vous et votre projet ?
MassiveHoster est conçu pour une large gamme de projets web. La plupart des projets !
Mais il reste utile de vérifier si nos solutions correspondent à vos besoins, surtout s'ils sont spécifiques.
• MassiveHoster est idéal pour :
- Les créateurs de sites WordPress et PrestaShop :
qu'il s'agisse de blogs, de sites vitrines ou de boutiques eCommerce de taille moyenne, notre infrastructure est particulièrement bien optimisée pour ces CMS
- Les freelances, TPE/PME, agences et référenceurs (SEO) :
notre offre Premium, avec ses comptes cloisonnés et ses IP multiples, est parfaite pour gérer plusieurs projets clients en toute sécurité et confidentialité
- Les utilisateurs exigeants sur les performances :
si vous en avez assez des lenteurs et des erreurs (503, 504, 508, timeout ou "MySQL connection") chez les hébergeurs "low-cost", vous pourriez apprécier la stabilité et la réactivité de notre infrastructure
• MassiveHoster n'est pas toujours la meilleure solution pour :
- Les sites à trafic viral extrême :
si vous gérez un site qui reçoit plusieurs millions de visiteurs uniques par jour de manière constante, une infrastructure de serveur dédié serait peut-être plus appropriée
- les très grosses boutiques eCommerce ou sites à contenus extrêmement volumineux :
pour un catalogue "produits" ou un site à contenus de 50.000 fiches ou plus, avec un trafic très intense, une solution dédiée pourrait être recommandée pour garantir des performances optimales
- le stockage de masse ou le streaming vidéo :
notre service est optimisé pour l'hébergement de sites et de pages web, pas pour le stockage de fichiers volumineux (sauvegardes d'ordinateur, intranet, archives de photos brutes) ou par exemple l'hébergement et la diffusion de longues vidéos (il existe de nombreuses plateformes dédiées et optimisées pour le streaming)
- les projets générant un nombre excessif de fichiers/dossiers de manière non justifiée :
la plupart de nos utilisateurs consomment moins de 600k d'inodes, car c'est déjà une limite extrêmement souple.
Nous nous tenons à disposition de nos utilisateurs pour évaluer et réduire leur consommation d'inodes. Néanmoins, même si nous proposons des addons d'inodes supplémentaires, dans quelques rares situations de sites extrêmement consommateurs (plusieurs millions d'inodes), il peut nous arriver d'orienter nos utilisateurs vers des solutions d'hébergement alternatives
Conclusion : ne comparez pas les chiffres marketing, comparez les résultats !
Vous l'aurez compris, comparer des offres d'hébergement sur la base de chiffres "marketing" qui auraient pu être gonflés n'est probablement pas la démarche la plus pertinente.
Comme nous l'avons vu, « une infrastructure d'hébergement n'en vaut pas une autre », car il y a beaucoup trop de paramètres techniques à prendre en compte au delà des « vCPU », de la limite de mémoire « RAM » et du débit « d'IO » en MB/s.
Les vraies questions prioritaires sont peut-être...
> « Mes sites seront-ils rapides et stables ? »
Nos services sont monitorés 24h/24 et nous sommes très réactifs concernant tout soupçon de "perturbation".
> « Mon hébergement est-il sécurisé ? »
Nous sommes presque imbattables sur ce point grâce notamment à la Suite de Sécurité premium Imunify360 incluse dans notre plan Premium, et toutes nos autres mesures de sécurité.
> « Et l'assistance technique sera-t-elle proactive en cas de besoin ? »
Consultez les témoignages clients concernant notre jeune offre pour vous faire un avis. Notre support va bien au-delà du classique « Nos serveurs sont UP, rien à signaler... » qu'on expérimente souvent chez les grands groupes 😉
MassiveHoster reste un hébergeur à taille humaine, récent, avec de solides compétences techniques et basé sur des technologies modernes.
Chez MassiveHoster, nous sommes tellement confiants dans la performance réelle de notre infrastructure que nous vous invitons à la mettre à l'épreuve !
Profitez de notre garantie "Satisfait ou Remboursé" de 14 jours...
Migrez quelques premiers sites pour nous tester
Si vous le souhaitez pour WordPress, installez Redis sur ces sites en suivant ce tutoriel (Comment installer Redis sur WordPress chez MassiveHoster). Et comparez par vous-même la vitesse et la fluidité de vos interfaces d'administration.
C'est selon nous un bien meilleur moyen pour vous faire un avis sur les performances et la robustesse de notre solution d'hébergement web, que de croire sur parole les pages de vente de nos concurrents qui, par définition, ont été conçues pour vous persuader d'acheter leur produit.
Nous sommes à disposition pour échanger, n'hésitez pas !
C'est une excellente question, mais la réponse est plus complexe qu'une poignée de chiffres.
• L'analogie de la voiture :
Comparer des hébergements uniquement sur les vCPU / RAM / IO est comme comparer 2 voitures uniquement sur leur nombre de chevaux (CV) sous le capot, sans regarder... :
le poids, le châssis, les pneus, la qualité du moteur, ou si les sièges sont en « cuir » plutôt qu'en « tissu ».
Une Formule 1 n'a pas le même potentiel de course qu'un tracteur, à puissance et CV équivalents.
Dans le monde de l'hébergement mutualisé, les chiffres sont souvent utilisés pour impressionner et appâter les clients. Mais tous les chiffres ne racontent pas toute l'histoire sur les performances et la stabilité que vous obtiendrez réellement chez votre hébergeur web.
Hélas, les grosses "fiches techniques" mises en avant sur les pages de vente des gros hébergeurs web mutualisés sont souvent trompeuses. C'est un fait.
Cet article a pour but de vous donner les clés pour vous aider à faire un choix éclairé et évaluer si tester MassiveHoster est un bon choix pour vous, ou pas.
Le "Jeu" de l'Overselling (ou survente) : comprendre les pratiques de certains (gros) hébergeurs web mutualisés
Entrons dans le vif du sujet...
• Qu'est-ce que l'overselling (ou la survente), pratique courante en hébergement web ?
Très simplement, c'est comme une compagnie d'assurance qui vend de nombreuses « couvertures santé » en espérant que la majorité de leurs clients ne tombent jamais malade.
Dans l'hébergement web, il s'agit de vendre (virtuellement) un total de ressources plus élevé que ce que les serveurs physiques n'en possèdent réellement.
Concrètement, lorsque l'hébergeur abuse de cette pratique et qu'il surcharge ses serveurs web, cela peut se traduire pour vous par des lenteurs inexpliquées, des erreurs 503 (Service Unavailable), 508 (Resource Limit Is Reached), des Timeouts ou des plantages de base de données ("Error establishing a database connection"), car le serveur est tout simplement surchargé.
• Étude de cas d'hébergeur n°1 : l'illusion des ressources "indépendantes" qui s'additionnent
Un certain hébergeur très connus en France propose des plans avec, par exemple soi-disant, "12 vCPU, 48 Go de RAM et 42 MB/s d'IO" pour chaque "compte isolé", avec la possibilité d'avoir "jusqu'à 8 comptes" pour un tarif de seulement 4,25€ par mois la première année (soit 51€ HT pour 12 mois).
Le calcul est simple :
• 12 vCPU x 8 = 96 vCPU !!
• 48 Go RAM x 8 = 384 Go RAM !!
• 42 MB/s d'IO x 8 = 336 MB/s d'IO !!
Même si vous n'êtes pas un expert en informatique, vous l'avez compris en comparant ces chiffres avec les caractéristiques de votre ordinateur... :
Aucun serveur d'hébergement web mutualisé ne peut garantir de telles ressources pour un seul client, d'autant que des centaines d'autres comptes sont souvent aussi hébergés sur ce type d'infrastructure « partagée », sur chaque serveur.
Cela prouve que ces ressources ne sont ni "indépendantes" ni "dédiées", mais au mieux, puisées dans un pool commun et partagé. Au pire, inventées de toutes pièces
La promesse est donc techniquement irréalisable.
Pour le dire autrement, si seulement 3 à 5 clients utilisaient à plein régime les ressources promises sur ce type de plan, le serveur entier serait déjà à genoux. Ce qui explique les instabilités constatées chez ce genre de fournisseur, par manque de cloisonnement
• Étude de cas d'hébergeur n°2 : le piège des limites techniques cachées
Un autre hébergeur très connu mondialement est aussi un champion du marketing !
Il attire les clients avec des engagements sur plusieurs années (jusqu'à 4 ans), à des prix très bas.
Leurs offres mettent en avant de nombreux Gigaoctets de stockage et de nombreux cœurs CPU.
Quel est le problème de ces caractéristiques mises en avant... ?
Les limites qui impactent vraiment la performance d'un site WordPress moderne (comme les IOPS ou « Opérations d'Entrée/Sortie par Seconde ») sont souvent absentes des pages de vente.
Pourtant et d'après nos observations, concernant les IOPS, il y a quelques mois cette information était bien visible. Mais elle a depuis été supprimée des pages publiques pour n'apparaître qu'une fois le service commandé !
Cependant, il faut savoir qu'un site avec un constructeur de page comme Elementor ou Divi peut être rapidement paralysé par une limite d'IOPS trop basse.
D'après notre expérience, les plans d'entrée de gamme de cet hébergeur se limitent à 128 IOPS, ce qui est largement insuffisant pour un site moderne et dynamique, avec un Constructeur de Pages (Page Builder), quelques plugins installés ou un peu trop de trafic quotidien.
Leur stratégie ?
Une fois que le client est engagé sur le long terme et que son site Web commence à prendre de l'ampleur (plus de contenus, de trafic et de plugins installés), les problèmes de lenteur ou d'erreurs timeout peuvent apparaître.
La seule solution pour ne pas perdre son investissement de départ serait alors de payer pour des "upgrades" successives vers les plans les plus chers.
C'est très malin. Mais, est-ce vraiment éthique ?
Face à de telles pratiques de marketing agressif, il est difficile pour tout hébergeur honnête de se positionner par rapport à des concurrents prêts à tout, par exemple dans un tableau comparatif qui se limiterait à comparer les caractéristiques autoproclamées par les fournisseurs eux-mêmes, comme une quantité de vCPU, RAM et I/O impossible à garantir, car démesurée.
Autrement dit,
Comment répondre à un prospect qui nous compare à un hébergeur qui a le culot d'annoncer garantir 96 vCPU de ressources dédiées indépendantes (!!) pour seulement 51€ HT la première année ?
Répondre à cela est exactement ce que nous allons tenter de faire ci-dessous.
Notre Philosophie chez MassiveHoster : transparence et performances !
Nos motivations ne nous ont pas guidé vers des choix "marketing",... mais des choix "techniques".
• Le choix de la performance brute : des serveurs physiques (Bare Metal)
Même si cela faciliterait grandement nos travaux de maintenance et réduirait nos coûts, nous avons choisi de ne pas utiliser de couche de virtualisation superflue qui dégrade les performances, comme sur les VPS (serveurs virtuels).
Il n'y a donc pas chez MassiveHoster d'intermédiaire logiciel entre vos sites et notre puissance matérielle brute, ce qui est plutôt inédit pour un hébergeur mutualisé grand public.
Nos serveurs sont des machines physiques puissantes dont les performances sont au minimum « AMD EPYC™ 32 Cœurs à 3.7GHz, 128 Go de RAM DDR4 ECC » sur lesquelles vos sites Web ont un accès on-ne-peut-plus direct aux ressources.
Le résultat est simple :
De meilleures performances et plus de stabilité !
D'ailleurs, le plan Premium de MassiveHoster vous offre des outils comme :
- AccelerateWP, une alternative à WP Rocket
- et PHP X-Ray pour diagnostiquer les lenteurs pouvant survenir sur vos sites Web à cause de scripts PHP trop gourmands.
• Une allocation des ressources juste et dynamique
Plutôt que de vous promettre des chiffres virtuels et irréalistes, nous préférons nous assurer de la santé et des performances globales de notre infrastructure sur base de l'utilisation réelle qui en est faite de la part de nos utilisateurs, constatée sur le terrain.
Par le biais de nombreux mécanismes automatisés, nous surveillons en temps réel la charge et toutes les autres metrics de nos serveurs, afin d'éviter qu'un utilisateur ne puisse impacter négativement ses voisins et afin d'adapter dynamiquement les ressources allouées aux utilisateurs sur base de leur utilisation réelle (à condition qu'aucun abus n'ait été constaté sur l'un ou l'autre compte utilisateur).
Cette approche permet à nos utilisateurs d'encaisser des pics de trafic ponctuelles, tout en assurant le respect des autres utilisateurs d'un même serveur.
Notre promesse n'est donc pas un chiffre inscrit sur un bout de papier, mais une volonté de qualité de service réelle et un suivi constant.
MassiveHoster est-il fait pour vous et votre projet ?
MassiveHoster est conçu pour une large gamme de projets web. La plupart des projets !
Mais il reste utile de vérifier si nos solutions correspondent à vos besoins, surtout s'ils sont spécifiques.
• MassiveHoster est idéal pour :
- Les créateurs de sites WordPress et PrestaShop :
qu'il s'agisse de blogs, de sites vitrines ou de boutiques eCommerce de taille moyenne, notre infrastructure est particulièrement bien optimisée pour ces CMS
- Les freelances, TPE/PME, agences et référenceurs (SEO) :
notre offre Premium, avec ses comptes cloisonnés et ses IP multiples, est parfaite pour gérer plusieurs projets clients en toute sécurité et confidentialité
- Les utilisateurs exigeants sur les performances :
si vous en avez assez des lenteurs et des erreurs (503, 504, 508, timeout ou "MySQL connection") chez les hébergeurs "low-cost", vous pourriez apprécier la stabilité et la réactivité de notre infrastructure
• MassiveHoster n'est pas toujours la meilleure solution pour :
- Les sites à trafic viral extrême :
si vous gérez un site qui reçoit plusieurs millions de visiteurs uniques par jour de manière constante, une infrastructure de serveur dédié serait peut-être plus appropriée
- les très grosses boutiques eCommerce ou sites à contenus extrêmement volumineux :
pour un catalogue "produits" ou un site à contenus de 50.000 fiches ou plus, avec un trafic très intense, une solution dédiée pourrait être recommandée pour garantir des performances optimales
- le stockage de masse ou le streaming vidéo :
notre service est optimisé pour l'hébergement de sites et de pages web, pas pour le stockage de fichiers volumineux (sauvegardes d'ordinateur, intranet, archives de photos brutes) ou par exemple l'hébergement et la diffusion de longues vidéos (il existe de nombreuses plateformes dédiées et optimisées pour le streaming)
- les projets générant un nombre excessif de fichiers/dossiers de manière non justifiée :
la plupart de nos utilisateurs consomment moins de 600k d'inodes, car c'est déjà une limite extrêmement souple.
Nous nous tenons à disposition de nos utilisateurs pour évaluer et réduire leur consommation d'inodes. Néanmoins, même si nous proposons des addons d'inodes supplémentaires, dans quelques rares situations de sites extrêmement consommateurs (plusieurs millions d'inodes), il peut nous arriver d'orienter nos utilisateurs vers des solutions d'hébergement alternatives
Conclusion : ne comparez pas les chiffres marketing, comparez les résultats !
Vous l'aurez compris, comparer des offres d'hébergement sur la base de chiffres "marketing" qui auraient pu être gonflés n'est probablement pas la démarche la plus pertinente.
Comme nous l'avons vu, « une infrastructure d'hébergement n'en vaut pas une autre », car il y a beaucoup trop de paramètres techniques à prendre en compte au delà des « vCPU », de la limite de mémoire « RAM » et du débit « d'IO » en MB/s.
Les vraies questions prioritaires sont peut-être...
> « Mes sites seront-ils rapides et stables ? »
Nos services sont monitorés 24h/24 et nous sommes très réactifs concernant tout soupçon de "perturbation".
> « Mon hébergement est-il sécurisé ? »
Nous sommes presque imbattables sur ce point grâce notamment à la Suite de Sécurité premium Imunify360 incluse dans notre plan Premium, et toutes nos autres mesures de sécurité.
> « Et l'assistance technique sera-t-elle proactive en cas de besoin ? »
Consultez les témoignages clients concernant notre jeune offre pour vous faire un avis. Notre support va bien au-delà du classique « Nos serveurs sont UP, rien à signaler... » qu'on expérimente souvent chez les grands groupes 😉
MassiveHoster reste un hébergeur à taille humaine, récent, avec de solides compétences techniques et basé sur des technologies modernes.
Chez MassiveHoster, nous sommes tellement confiants dans la performance réelle de notre infrastructure que nous vous invitons à la mettre à l'épreuve !
Profitez de notre garantie "Satisfait ou Remboursé" de 14 jours...
Migrez quelques premiers sites pour nous tester
Si vous le souhaitez pour WordPress, installez Redis sur ces sites en suivant ce tutoriel (Comment installer Redis sur WordPress chez MassiveHoster). Et comparez par vous-même la vitesse et la fluidité de vos interfaces d'administration.
C'est selon nous un bien meilleur moyen pour vous faire un avis sur les performances et la robustesse de notre solution d'hébergement web, que de croire sur parole les pages de vente de nos concurrents qui, par définition, ont été conçues pour vous persuader d'acheter leur produit.
Nous sommes à disposition pour échanger, n'hésitez pas !
#14
Annonces officielles / Communiqué sur la Stabilité et...
Dernier message par MassiveHoster - Août 13, 2025, 12:53 PMRapport d'intervention du 14 août 2025 : Les travaux de maintenance annoncés ont pris fin vers 5h45 aujourd'hui.
La maintenance a pris plus de temps que prévu à cause d'un problème de démarrage serveur lié à d'énormes données de cache « Redis » que le serveur tentait de charger d'un coup dans la RAM au démarrage.
Veuillez nous excuser pour cet inconvénient 🙏
Nous avons eu besoin d'un peu de temps pour trouver la cause de ce problème au démarrage et supprimer ces données de cache Redis chargées inutilement.
Des mesures vont être mises en place pour à l'avenir demander à Redis de partir sur des données fraîches aux reboot, afin d'éviter que ce problème n'apparaisse lors de prochaines mises à jour de kernel + reboots.
Nos utilisateurs profitent maintenant de MariaDB 11.4.7, ainsi que d'un kernel Linux parfaitement à jour dans sa version 5.14.0-570.32.1.el9_6.
Les prochaines 48 heures nous permettront de voir l'effet de ces améliorations sur nos outils de monitoring pour envisager la suite.
Merci pour votre confiance !
____________________
Annonce initiale :
Malgré nos efforts pour éviter ce type de problème, nous avons expérimenté, en pleine nuit, de légères perturbations pour la 2e fois en moins d'une semaine.
Perturbations liées à des travaux de maintenance et des tâches réalisées de nuit...
En effet, nous avons eu cette nuit un souci relatif à nos routines de backups nocturnes.
Pour rappel, nous avons chez MassiveHoster plusieurs dispositifs de sauvegarde, car par mesure de sécurité, nous décentralisons les données vers 2 emplacements distants (alors qu'à notre connaissance, les concurrents sur notre gamme de prix le font généralement à un seul emplacement, dans la room d'à côté du même datacenter 👀).
Même si notre choix d'architecture est plus long et coûteux (réduisant notre "marge"), ce type de sécurité pour lequel nous avons opté nous tient à coeur, car c'est (bien plus sûr) indispensable en cas d'incident majeur.
Concrètement,
- Nous effectuons un backup hebdomadaire de secours du serveur au complet / non incrémental, qui démarre dans la nuit de dimanche à lundi et prend environ 24h à être complété, car la tâche est mise en priorité basse pour éviter la charge
- En parallèle, nous effectuons du mardi au dimanche, tôt dans la nuit, des backups incrémentaux vers le cloud. Il s'agissait d'une tâche généralement très rapide, entre 90 et 180 minutes par jour. Mais vu la croissance très rapide de MassiveHoster, les choses évoluent rapidement.
- Enfin, le mercredi seulement (donc aujourd'hui), tard dans la nuit, nous lançons un backup système destiné à notre DRP (son but est de nous permettre de rétablir aussi rapidement que possible un serveur qui se verrait détruit physiquement, comme par un incendie ou une autre catastrophe naturelle).
Le souci qui s'est produit cette nuit est que ce Backup DRP du mercredi (tard dans la nuit) s'est lancé alors que notre Backup quotidien (tôt dans la nuit) n'avait pas eu le temps de se compléter à 100% 😮
...ce qui a créé une superposition et une réaction en chaîne : ralentissement du backup quotidien en cours ; charge trop importante sur le serveur d'hébergement..., donc perturbations momentanées ayant pu se ressentir sur les comptes utilisateurs.
Le fait est que nous avons de plus en plus de données à sauvegarder et à décentraliser ! 🔥
Donc, les backups qui mettaient toujours uniquement quelques heures à être complétés pendant la nuit, peuvent maintenant durer toute la nuit et commencer à déborder sur la matinée, lorsque le trafic en Europe arrive sur vos sites, créant ainsi une consommation cumulée qui peut perturber nos services 😵💫
En complément, nous savons que notre clientèle de #SEO est fermement attachée à son taux de disponibilité (uptime), même nocturne, et monitor judicieusement la disponibilité de ses sites, à tel point qu'à chaque tâche de maintenance planifiée réalisée en plein milieu de la nuit (et nous en réalisons beaucoup ces dernières semaines), pour une indisponibilité approximative de 5 minutes, nous recevons déjà plusieurs DM et Tickets pour nous en informer 😅
Nous sommes toujours heureux de communiquer de manière proactive et de répondre à chaque question, en fournissant toujours les détails des raisons identifiées qui ont engendré telle ou telle perturbation... il suffit de demander 😉
Néanmoins, même si nous fournissons des services premium de hosting aux PME depuis 2009 déjà, nous savons aussi qu'en tant que jeune acteur du secteur avec « MassiveHoster » (un service ouvert en bêta depuis seulement 1 an), notre clientèle nous observe et attend de se faire un avis à long terme sur notre offre 👀
Et notre clientèle ne nous pardonnera pas de lui infliger les mêmes désagréments que ce que l'ancien fournisseur a fait subir.
Pour ces raisons,
Nous savons que le taux de disponibilité (uptime) est tellement important pour nos utilisateurs, qu'il nous arrive même de retarder certains travaux de maintenance utiles qui devraient être réalisés de nuit.
Retardés, car ils génèrent inévitablement une certaine période de downtime...
Nous pensons à des travaux tels que la mise à jour critique de MariaDB ou encore la mise à jour de Kernel (noyaux Linux) qui offrent souvent des correctifs améliorant les performances et la stabilité d'une infrastructure.
Si vous êtes arrivé jusqu'ici, vous devez certainement penser comme nous qu'il n'est pas raisonnable de retarder des mises à jour softwares utiles, uniquement pour éviter les plaintes de quelques utilisateurs... 🤔
Pourtant, lorsqu'on est une jeune offre, avec une architecture technique qui est toujours en cours d'apprentissage, chaque plainte ou avis négatif compte et peut impacter négativement la réputation, et donc, la croissance du projet ♾
C'est pourquoi nous marchons sur des oeufs.
Néanmoins, avant d'être « Entrepreneurs », nous sommes « Hébergeurs », et nous devons veiller à la stabilité de nos services et avancer...
Même si cela implique des tâches de maintenance qui peuvent frustrer certains utilisateurs qui ne connaissent pas l'envers (technique) du décor.
De toute façon, certaines interruptions arrivent toujours tôt ou tard, car une infrastructure, par définition, doit toujours réaliser des maintenances et est toujours victime d'incidents un jour ou l'autre, même si le but du jeu est que cela soit le moins fréquent possible et d'agir sans délai lorsque cela arrive.
C'est pourquoi demain, jeudi, de nuit, nous mettrons à jour l'ensemble des composants qui avaient été post-posés, avec interruption temporaire de MySQL et redémarrage physique complet.
****
Vous devrez donc vous attendre à un certain délai d'interruption pendant ces tâches, de nuit, désolé 😬
****
Nous allons également entreprendre ensuite de nouveaux travaux, comme nous le faisons depuis plusieurs mois, pour continuer d'optimiser tout ce qui peut l'être sur notre jeune infrastructure en apprentissage...
Spontanément, nous pensons à la marge de progression que nous avons pour continuer si possible de faire évoluer nos technologies "web server", ainsi qu'à revoir la manière dont sont exécutés nos routines de sauvegardes pour faire face à la quantité massive et grandissante de données dynamiques que nous sauvegardons pour vous quotidiennement.
Bien sûr, il s'agit de travaux que nous devons réaliser conformément à la structure unique de notre offre aux tarifs défiant toute concurrence.
En effet, le projet a été initié avec plusieurs priorités, dont celle de vous offrir le meilleur Rapport Qualité-Prix... et dans « Rapport Qualité-Prix », il y a aussi « PRIX ».
La même équipe mène d'autres projets « hosting » depuis plusieurs années, notamment via EasyHoster, avec des stats d'Uptime défiant toute concurrence et croyez-le, moins de défis techniques... car menés sur d'autres technologies :
Serveurs cPanel, Serveurs moins "partagés", etc.
Les défis auxquels nous faisons face progressivement sont directement liés aux tarifs concurrentiels que nous désirons maintenir afin de permettre à nos clients de réaliser des économies sur leur hébergement web.
Encore une fois, nous admettons volontiers être toujours en apprentissage sur le terrain du « low cost », avec des tarifs et un service qui se sont finalement avérés intenables par d'énormes concurrents directs, qui ont augmenté leur tarif et revu leur SAV à la baisse 👀
Nous invitons donc comme toujours, notre communauté de gentils clients, s'ils le souhaitent, à soutenir ce projet naissant et en cours d'évolution, en s'armant de patience concernant les imperfections en cours de résolution et les quelques minutes d'instabilités par ci par là, de nuit.
Nous ne pouvons pas tout faire en un jour 😅
Et pour toute demande plus spécifique, nous restons avec plaisir ouverts aux échanges en privé, par DM et via les Tickets sur notre site.
Merci pour votre intérêt et à bientôt pour la suite 😉
La maintenance a pris plus de temps que prévu à cause d'un problème de démarrage serveur lié à d'énormes données de cache « Redis » que le serveur tentait de charger d'un coup dans la RAM au démarrage.
Veuillez nous excuser pour cet inconvénient 🙏
Nous avons eu besoin d'un peu de temps pour trouver la cause de ce problème au démarrage et supprimer ces données de cache Redis chargées inutilement.
Des mesures vont être mises en place pour à l'avenir demander à Redis de partir sur des données fraîches aux reboot, afin d'éviter que ce problème n'apparaisse lors de prochaines mises à jour de kernel + reboots.
Nos utilisateurs profitent maintenant de MariaDB 11.4.7, ainsi que d'un kernel Linux parfaitement à jour dans sa version 5.14.0-570.32.1.el9_6.
Les prochaines 48 heures nous permettront de voir l'effet de ces améliorations sur nos outils de monitoring pour envisager la suite.
Merci pour votre confiance !
____________________
Annonce initiale :
Malgré nos efforts pour éviter ce type de problème, nous avons expérimenté, en pleine nuit, de légères perturbations pour la 2e fois en moins d'une semaine.
Perturbations liées à des travaux de maintenance et des tâches réalisées de nuit...
En effet, nous avons eu cette nuit un souci relatif à nos routines de backups nocturnes.
Pour rappel, nous avons chez MassiveHoster plusieurs dispositifs de sauvegarde, car par mesure de sécurité, nous décentralisons les données vers 2 emplacements distants (alors qu'à notre connaissance, les concurrents sur notre gamme de prix le font généralement à un seul emplacement, dans la room d'à côté du même datacenter 👀).
Même si notre choix d'architecture est plus long et coûteux (réduisant notre "marge"), ce type de sécurité pour lequel nous avons opté nous tient à coeur, car c'est (bien plus sûr) indispensable en cas d'incident majeur.
Concrètement,
- Nous effectuons un backup hebdomadaire de secours du serveur au complet / non incrémental, qui démarre dans la nuit de dimanche à lundi et prend environ 24h à être complété, car la tâche est mise en priorité basse pour éviter la charge
- En parallèle, nous effectuons du mardi au dimanche, tôt dans la nuit, des backups incrémentaux vers le cloud. Il s'agissait d'une tâche généralement très rapide, entre 90 et 180 minutes par jour. Mais vu la croissance très rapide de MassiveHoster, les choses évoluent rapidement.
- Enfin, le mercredi seulement (donc aujourd'hui), tard dans la nuit, nous lançons un backup système destiné à notre DRP (son but est de nous permettre de rétablir aussi rapidement que possible un serveur qui se verrait détruit physiquement, comme par un incendie ou une autre catastrophe naturelle).
Le souci qui s'est produit cette nuit est que ce Backup DRP du mercredi (tard dans la nuit) s'est lancé alors que notre Backup quotidien (tôt dans la nuit) n'avait pas eu le temps de se compléter à 100% 😮
...ce qui a créé une superposition et une réaction en chaîne : ralentissement du backup quotidien en cours ; charge trop importante sur le serveur d'hébergement..., donc perturbations momentanées ayant pu se ressentir sur les comptes utilisateurs.
Le fait est que nous avons de plus en plus de données à sauvegarder et à décentraliser ! 🔥
Donc, les backups qui mettaient toujours uniquement quelques heures à être complétés pendant la nuit, peuvent maintenant durer toute la nuit et commencer à déborder sur la matinée, lorsque le trafic en Europe arrive sur vos sites, créant ainsi une consommation cumulée qui peut perturber nos services 😵💫
En complément, nous savons que notre clientèle de #SEO est fermement attachée à son taux de disponibilité (uptime), même nocturne, et monitor judicieusement la disponibilité de ses sites, à tel point qu'à chaque tâche de maintenance planifiée réalisée en plein milieu de la nuit (et nous en réalisons beaucoup ces dernières semaines), pour une indisponibilité approximative de 5 minutes, nous recevons déjà plusieurs DM et Tickets pour nous en informer 😅
Nous sommes toujours heureux de communiquer de manière proactive et de répondre à chaque question, en fournissant toujours les détails des raisons identifiées qui ont engendré telle ou telle perturbation... il suffit de demander 😉
Néanmoins, même si nous fournissons des services premium de hosting aux PME depuis 2009 déjà, nous savons aussi qu'en tant que jeune acteur du secteur avec « MassiveHoster » (un service ouvert en bêta depuis seulement 1 an), notre clientèle nous observe et attend de se faire un avis à long terme sur notre offre 👀
Et notre clientèle ne nous pardonnera pas de lui infliger les mêmes désagréments que ce que l'ancien fournisseur a fait subir.
Pour ces raisons,
Nous savons que le taux de disponibilité (uptime) est tellement important pour nos utilisateurs, qu'il nous arrive même de retarder certains travaux de maintenance utiles qui devraient être réalisés de nuit.
Retardés, car ils génèrent inévitablement une certaine période de downtime...
Nous pensons à des travaux tels que la mise à jour critique de MariaDB ou encore la mise à jour de Kernel (noyaux Linux) qui offrent souvent des correctifs améliorant les performances et la stabilité d'une infrastructure.
Si vous êtes arrivé jusqu'ici, vous devez certainement penser comme nous qu'il n'est pas raisonnable de retarder des mises à jour softwares utiles, uniquement pour éviter les plaintes de quelques utilisateurs... 🤔
Pourtant, lorsqu'on est une jeune offre, avec une architecture technique qui est toujours en cours d'apprentissage, chaque plainte ou avis négatif compte et peut impacter négativement la réputation, et donc, la croissance du projet ♾
C'est pourquoi nous marchons sur des oeufs.
Néanmoins, avant d'être « Entrepreneurs », nous sommes « Hébergeurs », et nous devons veiller à la stabilité de nos services et avancer...
Même si cela implique des tâches de maintenance qui peuvent frustrer certains utilisateurs qui ne connaissent pas l'envers (technique) du décor.
De toute façon, certaines interruptions arrivent toujours tôt ou tard, car une infrastructure, par définition, doit toujours réaliser des maintenances et est toujours victime d'incidents un jour ou l'autre, même si le but du jeu est que cela soit le moins fréquent possible et d'agir sans délai lorsque cela arrive.
C'est pourquoi demain, jeudi, de nuit, nous mettrons à jour l'ensemble des composants qui avaient été post-posés, avec interruption temporaire de MySQL et redémarrage physique complet.
****
Vous devrez donc vous attendre à un certain délai d'interruption pendant ces tâches, de nuit, désolé 😬
****
Nous allons également entreprendre ensuite de nouveaux travaux, comme nous le faisons depuis plusieurs mois, pour continuer d'optimiser tout ce qui peut l'être sur notre jeune infrastructure en apprentissage...
Spontanément, nous pensons à la marge de progression que nous avons pour continuer si possible de faire évoluer nos technologies "web server", ainsi qu'à revoir la manière dont sont exécutés nos routines de sauvegardes pour faire face à la quantité massive et grandissante de données dynamiques que nous sauvegardons pour vous quotidiennement.
Bien sûr, il s'agit de travaux que nous devons réaliser conformément à la structure unique de notre offre aux tarifs défiant toute concurrence.
En effet, le projet a été initié avec plusieurs priorités, dont celle de vous offrir le meilleur Rapport Qualité-Prix... et dans « Rapport Qualité-Prix », il y a aussi « PRIX ».
La même équipe mène d'autres projets « hosting » depuis plusieurs années, notamment via EasyHoster, avec des stats d'Uptime défiant toute concurrence et croyez-le, moins de défis techniques... car menés sur d'autres technologies :
Serveurs cPanel, Serveurs moins "partagés", etc.
Les défis auxquels nous faisons face progressivement sont directement liés aux tarifs concurrentiels que nous désirons maintenir afin de permettre à nos clients de réaliser des économies sur leur hébergement web.
Encore une fois, nous admettons volontiers être toujours en apprentissage sur le terrain du « low cost », avec des tarifs et un service qui se sont finalement avérés intenables par d'énormes concurrents directs, qui ont augmenté leur tarif et revu leur SAV à la baisse 👀
Nous invitons donc comme toujours, notre communauté de gentils clients, s'ils le souhaitent, à soutenir ce projet naissant et en cours d'évolution, en s'armant de patience concernant les imperfections en cours de résolution et les quelques minutes d'instabilités par ci par là, de nuit.
Nous ne pouvons pas tout faire en un jour 😅
Et pour toute demande plus spécifique, nous restons avec plaisir ouverts aux échanges en privé, par DM et via les Tickets sur notre site.
Merci pour votre intérêt et à bientôt pour la suite 😉
#15
Support Technique / Re : chemin cron et commande p...
Dernier message par MassiveHoster - Août 13, 2025, 11:23 AMMerci pour votre retour.
Si vous ne souhaitez pas recevoir de mail envoyé par la CRON vous pouvez ajouter >/dev/null 2>&1 à la fin de celle-ci ?
Si vous ne souhaitez pas recevoir de mail envoyé par la CRON vous pouvez ajouter >/dev/null 2>&1 à la fin de celle-ci ?
#16
Support Technique / Re : chemin cron et commande p...
Dernier message par chopodmoz - Août 13, 2025, 10:41 AMcomment effacer ces messages que je reçois par mail
Code Sélectionner
Cron <...@earth> php -q "/homes/principal/domains/domaine secondaire/public_html/wp-cron.php
Erreur base de données #17
Support Technique / Re : chemin cron et commande p...
Dernier message par MassiveHoster - Août 12, 2025, 12:14 PMBonjour chopodmoz,
Merci pour votre message.
Effectivement, vous avez raison l'indication donnée par le panel rend les choses peut claires. C'est une explication générée par le panel lui-même que nous devrions sans doute adapter ^_^
Les nouvelles CRONs avec 8,28 ont été générées par nos soins, aujourd'hui, pour améliorer les performances de notre infrastructures et ainsi remplacer les CRONs natives de WordPress par de véritables CRONs serveur beaucoup plus performantes.
Pour votre CRON personnelle, pour en vérifier le fonctionnement, vous pouvez utiliser le Terminal et l'exécuter en retirant notamment >/dev/null 2>&1
Cependant, nous vous recommanderions plutôt cette syntaxe :
$USER ; domaine-secondaire et dossier étant à adapter à votre situation (bien entendu ^^)
Avec >/dev/null 2>&1 à la fin si souhaité
Dites-nous si cela vous aide !
Merci pour votre message.
Effectivement, vous avez raison l'indication donnée par le panel rend les choses peut claires. C'est une explication générée par le panel lui-même que nous devrions sans doute adapter ^_^
Les nouvelles CRONs avec 8,28 ont été générées par nos soins, aujourd'hui, pour améliorer les performances de notre infrastructures et ainsi remplacer les CRONs natives de WordPress par de véritables CRONs serveur beaucoup plus performantes.
Pour votre CRON personnelle, pour en vérifier le fonctionnement, vous pouvez utiliser le Terminal et l'exécuter en retirant notamment >/dev/null 2>&1
Cependant, nous vous recommanderions plutôt cette syntaxe :
Code Sélectionner
php -q /homes/$USER/domains/domaine-secondaire/public_html/dossier/cron_update.php
$USER ; domaine-secondaire et dossier étant à adapter à votre situation (bien entendu ^^)
Avec >/dev/null 2>&1 à la fin si souhaité
Dites-nous si cela vous aide !
#18
Support Technique / Re : chemin cron et commande p...
Dernier message par chopodmoz - Août 12, 2025, 10:43 AMattention
si on previsualise on a une erreur de captcha et si on soumet direct, pas d'erreur et soumission
si on previsualise on a une erreur de captcha et si on soumet direct, pas d'erreur et soumission
#19
Support Technique / chemin cron et commande pas cl...
Dernier message par chopodmoz - Août 12, 2025, 10:42 AMBonjour
je me suis arraché les cheveux et là j'en ai plus
et je ne sais pas encore si mon cron marche
wget -O /dev/null https://www.domane secondaire /dossier/cron_update.php >/dev/null 2>&1 ( un cron que j'ai codé )
et ça marche une fois sur 2 ou pas completement !!!!!
et ce matin je reçois une alert de cron pourri
et cela me permet de découvrir des cron installés automatiquement
avec comme instructions des 8,28 ( 8 et 28 mn chaque heure..OK !) ou des 7,32 etc.. des trucs donc aléatoires
et puis
php -q "/homes/domaineprincipal/domains/domaine_ou_je veux faire cron/public_html/wp-cron.php"
et dans les instructions de votre page :
php /home/dmozfr/domains/domaine principal/public_html/script.php
curl --silent http://domaine principal/cron.php > /dev/null
wget -O /dev/null http://domaine principal/cron.php
alors finalement c'est quoi la bonne instruction
je me suis arraché les cheveux et là j'en ai plus
et je ne sais pas encore si mon cron marchewget -O /dev/null https://www.domane secondaire /dossier/cron_update.php >/dev/null 2>&1 ( un cron que j'ai codé )
et ça marche une fois sur 2 ou pas completement !!!!!
et ce matin je reçois une alert de cron pourri
et cela me permet de découvrir des cron installés automatiquement
avec comme instructions des 8,28 ( 8 et 28 mn chaque heure..OK !) ou des 7,32 etc.. des trucs donc aléatoires
et puis
php -q "/homes/domaineprincipal/domains/domaine_ou_je veux faire cron/public_html/wp-cron.php"
et dans les instructions de votre page :
php /home/dmozfr/domains/domaine principal/public_html/script.php
curl --silent http://domaine principal/cron.php > /dev/null
wget -O /dev/null http://domaine principal/cron.php
alors finalement c'est quoi la bonne instruction
#20
Support Technique / Re : Setup nodeJS app
Dernier message par MassiveHoster - Mai 13, 2025, 09:05 AMMerci pour votre retour.
Vous pouvez installer l'application où vous voulez, dans ou hors de public_html tant que cela se trouve dans le répertoire du domaine.
Si vous inscrivez simplement le mot "app" dans le champ "Application root" puis validez le formulaire, le conteneur d'application Node.js sera créé avec tous les sous-répertoires de base, ce qui vous permettra de comprendre comment définir le "path" de votre application dans un environnement CloudLinux Selector > Setup Node.js App.
Nous restons à votre disposition.
Vous pouvez installer l'application où vous voulez, dans ou hors de public_html tant que cela se trouve dans le répertoire du domaine.
Si vous inscrivez simplement le mot "app" dans le champ "Application root" puis validez le formulaire, le conteneur d'application Node.js sera créé avec tous les sous-répertoires de base, ce qui vous permettra de comprendre comment définir le "path" de votre application dans un environnement CloudLinux Selector > Setup Node.js App.
Nous restons à votre disposition.