17 mai 2024

Pourquoi AWS n'est pas la panacée à tous les maux : le temps d'arrêt de 4 heures de passionastronomia.it

La puissance n’est rien sans contrôle (et sans cache pleine page). Celui qui cause son propre mal devrait pleurer pour lui-même.

Dans le monde de l’hébergement web et de la gestion d’infrastructures, AWS (Amazon Web Services) est souvent considéré comme la référence en matière d’évolutivité et de fiabilité. Cependant, comme tout outil puissant, le succès d'AWS dépend de sa configuration et de sa gestion appropriées. Cet article analyse un cas concret de site d'astronomie, passionastronomia.it, qui a subi un temps d'arrêt de 4 heures malgré son hébergement sur AWS. Nous explorerons les causes du problème, l'utilisation de CloudFront et CloudFlare et l'importance du cache pleine page pour améliorer les performances et réduire la consommation de ressources.

Le cas : passionastronomia.it

Il y a quelques mois, l'un de nos précieux clients avec un trafic mensuel d'environ 50 millions de pages vues, nous a signalé un site d'astronomie émergent qui rencontrait périodiquement des problèmes de temps d'arrêt en raison d'un trafic trop important.

Lui, qui suivait la page Passione Astronomia, a été informé par les posts publiés sur Facebook par Passione Astronomia elle-même. Chaque fois qu'une publication provoquait une surcharge et que le site était hors ligne, ils le signalaient, se vantant que le serveur ne pouvait pas gérer le trafic élevé.. Or, pour le propriétaire d'un site habitué à gérer 50 millions de pages vues par mois, avec des pointes à plus de 3 millions par jour, il est assez « curieux » de voir comment un site qui en gère environ un dixième, soit environ 6 millions par mois (selon les estimations de SimilarWeb), peuvent se déconnecter très fréquemment sans que personne ne fasse quoi que ce soit pour résoudre le problème.

Visites-SimilaireWeb-Passion-Astronomie

C'est vraiment un problème, car normalement, lorsqu'un temps d'arrêt se produit et que le trafic dirigé vers le site est incapable de le contacter ou accumule de nombreuses erreurs 500, les navigateurs qui utilisent Chromium (le moteur derrière Chrome), y compris évidemment Chrome, signalent l'incident à Google. En conséquence, Google enverra moins de trafic vers ce site dans les heures suivantes, sachant que quelque chose ne fonctionne pas correctement. Cela peut avoir un impact important sur la visibilité et les performances du site, pénalisant encore davantage son trafic et sa fiabilité aux yeux des utilisateurs et des moteurs de recherche, en plus de nuire évidemment à son image.

De plus, même lorsque le site est en ligne, il ne semble pas garantir on ne sait quelles performances avec un Time To First Byte d'environ 500ms à 8h du matin avec un site pratiquement peu visité et sans posts lancés générant du trafic. Ci-dessous, vous pouvez par exemple consulter le test TTFB pour l'Europe avec le test TTFB SpeedVitals.com

SpeedVitals-Passion-Astronomie

Ci-dessous vous pouvez consulter notre TTFB de Managedserver.it, un site dont nous prenons soin de manière obsessionnelle pour obtenir les meilleures performances.

SpeedVitals ManagedServer.it

Nous parlons d'un TTFB (Time to First Byte) 10 fois inférieur et bien en dessous du maximum de 200 ms que Google considère acceptable avant de signaler que le temps de réponse du serveur est trop élevé, indiquant la nécessité « d'améliorer le temps de réponse du serveur ». .

Améliorer le temps de réponse du serveur --- Google-PSI

De plus, la lenteur d'un TTFB aussi élevé, au point de devenir fréquemment inatteignable à certains moments de la journée, y compris lors d'arrêts prolongés, affecte négativement le Vitaux Web de base ce que nous pouvons voir dans le rapport Google PageSpeed ​​​​Insight ci-dessous.

PageSpeed-Insight-Passioneastronomia.it

Un délai élevé jusqu'au premier octet (TTFB), comme le montre l'image avec une valeur de 2,3 secondes, peut affecter négativement d'autres paramètres du Vitaux Web de base. Un TTFB élevé signifie qu'il y a un délai important avant que le navigateur ne commence à recevoir des données du serveur. Ce délai contribue à un First Contentful Paint (FCP) élevé (3,4 secondes) et à un Largest Contentful Paint (LCP) élevé (4,7 secondes), car le rendu initial de la page est retardé. De plus, un TTFB élevé peut avoir un impact négatif sur l'interaction avec Next Paint (INP) et le décalage cumulatif de mise en page (CLS), car un chargement lent des pages peut conduire à une expérience utilisateur moins fluide et à des changements de mise en page plus fréquents.

Habitué à gérer des pics de trafic importants, voire supérieurs à 2 millions de visites par heure et 200 mille par minute, et spécialisé dans l'optimisation de Vitaux Web de base, nous avons proposé nos services et notre expertise aux propriétaires de passionastronomia.it en les contactant pour leur proposer une gestion gérée de leur infrastructure ou migrer vers notre hébergement performant, cependant, notre offre a probablement été mal comprise et sous-estimée, voire rejetée sans trop de compliments et de mots hachés.

Pourtant, notre site bénéficie d'un TTFB optimal de seulement 22 ms en Italie et d'un PageSpeed ​​​​qui passe brillamment le test de Vitaux Web de base comme vous pouvez le voir ci-dessous.

PageSpeed-Insight-Managedserver.it

Avec un portefeuille de clients éditeurs important et les chiffres évoqués ci-dessus, qui ont pu être évalués de manière impartiale grâce aux outils mis à disposition par Google, il semblait incroyable que, dans un moment de difficulté caractérisé par des temps d'arrêt continus, ils n'aient pas profité de l'occasion pour résoudre tous les problèmes en un éclair. Cela aurait pu se produire à un coût probablement deux fois moins élevé que celui de leur fournisseur actuel, qui les voyait souvent hors ligne ou avec des performances médiocres, comme l'indiquent les tests ci-dessus.

Passioneastronomia.it et WordPress

Passioneastronomia.it est un site éditorial développé sous WordPress, basé sur PHP et MySQL. Bien que ces technologies soient désormais considérées comme obsolètes par rapport aux langages et technologies plus modernes et asynchrones comme Node.js, Go ou les bases de données NoSQL comme Cassandra, MongoDB ou REDIS, elles continuent d'être largement utilisées. PHP, par exemple, a été développé dans les années 90 et a subi de nombreuses mises à jour au fil du temps, mais reste moins performant dans les situations de charge élevée que les langages asynchrones modernes. De même, MySQL, bien qu'il s'agisse d'un système de gestion de bases de données relationnelles robuste, peut rencontrer des difficultés en termes d'évolutivité et de performances lors du traitement de gros volumes de données et de requêtes simultanées.

Malgré ces limites, WordPress reste le système de publication de contenu le plus polyvalent et le plus facile à mettre en œuvre disponible aujourd'hui. Sa vaste communauté de développeurs, sa myriade de plugins disponibles et son interface intuitive en font un choix populaire aussi bien pour les petits blogs que pour les grandes entreprises. Même les grands journaux comme Le Quotidien Made ils utilisent WordPress comme CMS pour publication éditoriale, démontrant qu'avec la bonne configuration et optimisation, il est possible d'obtenir d'excellentes performances même avec des technologies considérées comme moins modernes.

en outre même la NASA, la plus haute expression de l’imaginaire collectif de diffusion scientifique, utilise WordPress comme CMS.

Bannière de la NASA

 

Passioneastronomia.it initialement (du moins depuis qu'ils nous en ont parlé il y a environ un an) était hébergé sur SiteGround, un service d'hébergement qui n'est pas toujours en mesure de gérer un trafic de ce niveau. Puis en avril, le site a migré vers AWS, le choix du marché et de nombreux grands noms comme Netflix, Airbnb, Spotify, Twitch, LinkedIn, Adobe, Slack et la BBC.

  1. Netflix: Utilise AWS pour le streaming vidéo, le stockage de données et l'analyse.
  2. Airbnb: exploite AWS pour gérer sa plateforme hôtelière mondiale et son marché en ligne.
  3. Spotify: utilisez AWS pour la diffusion de musique en streaming, l'analyse de données et l'apprentissage automatique.
  4. Twitch: La plateforme de streaming vidéo appartenant à Amazon s'appuie sur AWS pour la transmission vidéo en direct et la gestion des données.
  5. LinkedIn: Bien qu'une partie de son infrastructure soit interne, LinkedIn utilise AWS pour certains de ses services de stockage et d'analyse de données.
  6. Adobe: Propose ses services Creative Cloud et d'autres applications SaaS via AWS.
  7. Slack: Utilise AWS pour sa plateforme de messagerie et de collaboration.
  8. BBC: La BBC utilise AWS pour la diffusion de contenu vidéo à la demande et la gestion des données.

Malgré la puissance et l'évolutivité d'AWS, passionastronomia.it a continué à connaître des temps d'arrêt, aboutissant à une panne de 4 heures le 16 mai, de 19h à 00h23, surveillée par notre outil Uptime Kuma.

Temps d'arrêt-passioneastronomia.it
La capture d'écran met en évidence une période d'indisponibilité importante survenue le 16 mai 2024. La section rouge du graphique montre que l'indisponibilité a commencé à 19h00 et s'est poursuivie jusqu'à 23h13, pour un total de plus de 4 heures d'inactivité.

Les causes des temps d'arrêt

Le principal problème ne réside pas dans AWS en tant qu'infrastructure, mais dans la configuration et la gestion du service. AWS propose une large gamme de services, notamment EC2, des bases de données, des équilibreurs de charge, des systèmes de fichiers distribués et des CDN comme CloudFront.. Cependant, s'il est utilisé de manière inappropriée, AWS peut entraîner de graves problèmes de performances.

Le site passionastronomia.it ne disposait pas d'un système Full Page Cache adéquat tel que CloudFront ou la version Pro ou Business de CloudFlare avec support HTML Cache, ni même d'un « simple » Varnish. Les en-têtes de réponse du site montrent clairement que la mise en cache HTML n'était pas activée :

HTTP/2 200
date: Thu, 16 May 2024 22:02:18 GMT
content-type: text/html; charset=UTF-8
set-cookie: AWSALBTG=gkrvkTmzuBE7uhKteG6ihiCGQH60BIdF48ki+7cvKP9ia2ltc4cAgn5dVM5l+/WaO8fbb8dzylYF1OYP7PZnmhHdLsauuVLuLntiKviIt8EAxKNbM3yBSyKqrMaGu1SXAQaPGkLnjoHwqz3OkmDHAVqvBB0V3v4d0WOcshbhqixspvTJTic=; Expires=Thu, 23 May 2024 22:02:17 GMT; Path=/
set-cookie: AWSALBTGCORS=gkrvkTmzuBE7uhKteG6ihiCGQH60BIdF48ki+7cvKP9ia2ltc4cAgn5dVM5l+/WaO8fbb8dzylYF1OYP7PZnmhHdLsauuVLuLntiKviIt8EAxKNbM3yBSyKqrMaGu1SXAQaPGkLnjoHwqz3OkmDHAVqvBB0V3v4d0WOcshbhqixspvTJTic=; Expires=Thu, 23 May 2024 22:02:17 GMT; Path=/; SameSite=None; Secure
cf-edge-cache: cache,platform=wordpress
link: <https://www.passioneastronomia.it/wp-json/>; rel="https://api.w.org/"
link: <https://www.passioneastronomia.it/wp-json/wp/v2/pages/49>; rel="alternate"; type="application/json"
link: <https://www.passioneastronomia.it/>; rel=shortlink
vary: Accept-Encoding
cf-cache-status: DYNAMIC
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=dvOaq3CI0sDGSeXsjICpJUT0nF1zmp%2BFj1TKPfqJKvyRd%2FuybtNnkc9FKE6SLu7CldFY7brUo1HZwF1kvPoDyisecYzzZC3aI%2FlrjkKCKcs%2BD4LVRylVZMmSQViSYJRA6fO9JU1sg2ejKUk%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 884ea6b518c20e4d-MXP
alt-svc: h3=":443"; ma=86400

La version gratuite de CloudFlare ne prend pas en charge le cache HTML en mode DYNAMIQUE, provoquant une charge excessive sur les serveurs AWS avec des requêtes HTML continues passant directement par les processus PHP et les connexions aux bases de données.

Dans le premier cas, lorsque la charge augmente de manière significative, le serveur Web d'origine atteint la saturation, étant incapable même de répondre et provoquant l'expiration du proxy inverse du CDN CloudFlare comme dans l'image suivante :

CloudFlare-Gateway-Timeout

Dans le deuxième cas, même si le serveur Web parvient à répondre pendant quelques instants, le chargement des requêtes SQL sur la base de données MySQL renverra certainement une erreur de connexion à la base de données comme dans la capture d'écran ci-dessous.

Erreur-Base de données-WordPress

Plus succinctement, il est correct de dire, sans trop entrer dans le monde des SGBD, de la gestion des tables, des requêtes et des index, que ce manque de mise en cache adéquate a plusieurs implications négatives, en particulier pour les sites à fort trafic tels que passionastronomia.it.

Implications du manque de cache HTML

  1. Charge accrue sur les serveurs Origin:Sans mise en cache HTML, chaque requête de page HTML doit être traitée directement par les serveurs d'origine. Cela signifie que chaque visite sur le site active les processus PHP pour générer le contenu dynamique de la page, augmentant considérablement la charge sur les serveurs. En conséquence, le serveur doit gérer un grand nombre de requêtes simultanées, entraînant un épuisement rapide des ressources disponibles.
  2. Surcharge de base de données:Chaque requête HTML peut impliquer une série de requêtes de base de données pour récupérer les données nécessaires à la génération de la page. À mesure que le trafic augmente, le nombre de connexions à la base de données peut dépasser la limite gérable, provoquant un ralentissement, voire une panne de la base de données. Cette surcharge de base de données est souvent à l’origine d’un temps d’arrêt prolongé.
  3. Temps de réponse élevés:Sans mise en cache, le temps nécessaire pour générer une page HTML peut être considérablement plus long. Chaque requête nécessite le chargement et l'exécution de scripts PHP, l'interaction avec la base de données et la génération dynamique de contenu. Ce processus est beaucoup plus lent que la diffusion d'une page en cache, ce qui entraîne des temps de réponse élevés et une expérience utilisateur sous-optimale.
  4. Risque de temps d'arrêt:Lorsque les serveurs d'origine sont constamment sous pression en raison du nombre élevé de requêtes, le risque de temps d'arrêt augmente. Les serveurs peuvent ne plus répondre ou même planter si la charge dépasse leur capacité à gérer. C'est exactement ce qui est arrivé à passionaastronomia.it, où le site a connu des temps d'arrêt importants en raison de l'incapacité de gérer un trafic élevé sans un système de mise en cache approprié.

Utilisation inappropriée d'AWS EC2

Bien qu'AWS EC2 soit une solution puissante, l'utilisation d'une instance EC2, même une grande Etra, sans configuration appropriée, peut s'avérer inefficace. Une instance EC2 n’est rien d’autre qu’une instance virtualisée dotée d’une certaine quantité de cœurs et de RAM, qui offre des ressources de calcul importantes. Cependant, sans une gestion du trafic et une mise en cache appropriées, ces ressources peuvent rapidement devenir surchargées. Une mauvaise configuration peut transformer une instance puissante en un goulot d'étranglement, incapable de gérer des pics de trafic élevés.

Par exemple, en l'absence de mécanismes d'équilibrage de charge, un serveur unique peut être submergé par un trop grand nombre de requêtes simultanées, épuisant rapidement le processeur et la mémoire disponibles. De plus, sans stratégie de mise en cache efficace, chaque requête utilisateur doit être entièrement traitée par le serveur d'origine, impliquant des processus PHP et des requêtes de base de données pour générer les pages dynamiques. Cela augmente non seulement les temps de réponse, mais cela met également à rude épreuve la base de données, ce qui peut devenir un point de défaillance critique bien que, comme nous pouvons le voir, la base de données soit hébergée sur un service de base de données gérée tel que RDS.

Base de données d'erreurs WordPress

MySQL RDS (service de base de données relationnelle) par Amazon AWS est un service de base de données géré qui facilite la configuration, l'exploitation et la mise à l'échelle d'une base de données MySQL dans le cloud. Avec MySQL RDS, Amazon s'occupe des tâches administratives telles que le matériel, le système d'exploitation, les correctifs de base de données et les sauvegardes. Cela permet aux utilisateurs de se concentrer davantage sur le développement d'applications et moins sur la gestion de l'infrastructure.

Même les meilleures instances EC2 peuvent donc échouer si elles ne sont pas prises en charge par une architecture backend solide. Pour maximiser l'efficacité d'une instance EC2, il est essentiel de mettre en œuvre des systèmes de mise en cache au niveau des applications et d'utiliser des CDN comme CloudFront ou CloudFlare pour répartir la charge. De plus, la configuration d'Auto Scaling pour s'adapter automatiquement aux changements de trafic peut éviter les surcharges soudaines. Ce n'est qu'avec une gestion minutieuse et une configuration optimale qu'une instance EC2 peut exploiter pleinement son potentiel, garantissant des performances et une fiabilité élevées.

Que sont CloudFront et CloudFlare ?

CloudFront

CloudFront est un CDN (Content Delivery Network) proposé par AWS qui diffuse du contenu dans le monde entier, réduisant ainsi la latence et améliorant la vitesse de chargement des pages. Ce service est particulièrement utile pour les sites à fort trafic tels que passionastronomia.it, car il est capable de mettre en cache des pages HTML entières, réduisant ainsi la charge sur les serveurs d'origine et améliorant considérablement l'expérience utilisateur. La fourniture de contenu via un réseau mondial de nœuds périphériques rapproche les données des utilisateurs finaux, ce qui se traduit par des temps de réponse plus rapides et une plus grande fiabilité. De plus, CloudFront offre des fonctionnalités avancées telles que la protection DDoS et l'intégration avec AWS Shield et AWS WAF, qui contribuent à améliorer la sécurité du site. L'utilisation de CloudFront vous permet également de mieux gérer les pics de trafic, en garantissant que les ressources du serveur d'origine ne sont pas surchargées pendant les périodes de forte demande. Sa flexibilité et son évolutivité en font une solution idéale pour améliorer les performances du site et offrir une expérience de navigation plus fluide et plus rapide aux utilisateurs.

CloudFlare

CloudFlare est un autre service CDN qui offre une large gamme de fonctionnalités pour améliorer les performances et la sécurité des sites Web. Contrairement à CloudFront, CloudFlare propose plusieurs options de mise en cache, notamment HTML Cache pour les versions Pro et Business.

Les avantages de CloudFront et CloudFlare peuvent être très similaires, voire se chevaucher. L'avantage le plus connu de CloudFlare par rapport à CloudFront est que CloudFlare propose un plan tarifaire forfaitaire avec un plan de base de 25 $ par mois. ce qui aurait été largement suffisant pour rendre le site passionastronomia.it parfaitement conforme aux pics de trafic qu'il reçoit quotidiennement.

CloudFront, en revanche, propose un plan de paiement à l'utilisation, de sorte que le coût est directement proportionnel aux données déplacées.

En fait, CloudFlare et CloudFront proposent tous deux un service Full Page Cache en mode PaaS (Platform as a Service), se distinguant des solutions auto-hébergées telles que Varnish Cache. Cette différence est significative, car un service PaaS comme celui fourni par CloudFlare et CloudFront vous évite d'avoir à gérer et à maintenir l'infrastructure de mise en cache. Avec les solutions PaaS, le déploiement et la gestion du cache sont automatisés et intégrés au service, réduisant ainsi les frais administratifs et permettant aux équipes de se concentrer sur d'autres tâches critiques.

Par exemple, CloudFlare et CloudFront proposent des interfaces conviviales pour configurer les règles de mise en cache., gérez les invalidations et surveillez les performances du site, le tout sans nécessiter de compétences techniques approfondies en gestion de serveur. En revanche, les solutions auto-hébergées telles que Varnish Cache nécessitent une configuration manuelle et une gestion continue de l'infrastructure de mise en cache. Cela implique la nécessité de disposer d'un personnel technique qualifié capable d'installer, de configurer, de surveiller et de mettre à jour le logiciel de mise en cache, ainsi que de gérer les serveurs physiques ou virtuels sur lesquels il opère.

Les solutions PaaS de CloudFlare et CloudFront offrent également un avantage significatif en termes d'évolutivité et de fiabilité.. En tant que services cloud, ils peuvent tirer parti du réseau mondial de nœuds distribués pour offrir des performances élevées et une faible latence aux utilisateurs finaux, quelle que soit leur situation géographique. La fourniture de contenu sur un réseau mondial de serveurs périphériques réduit la latence et améliore les temps de chargement des pages, offrant ainsi une expérience utilisateur optimale.

De plus, CloudFlare et CloudFront intègrent des fonctionnalités de sécurité avancées, telles que la protection DDoS et l'intégration avec les certificats SSL, qui peuvent être gérées et configurées directement depuis la plateforme sans nécessiter d'intervention manuelle. Ce niveau d'automatisation et d'intégration facilite la sécurisation des applications Web et offre une plus grande tranquillité d'esprit aux propriétaires de sites.

Bien que les solutions auto-hébergées telles que Varnish Cache puissent offrir un contrôle plus granulaire et personnalisé sur la configuration du cache, elles nécessitent un engagement important en termes de ressources et d'expertise technique. D'autre part, les solutions CloudFlare et CloudFront PaaS fournissent un service complet, automatisé et hautement évolutif qui simplifie la gestion du cache, réduit la charge administrative et offre un niveau plus élevé de performances et de sécurité.

Cache pleine page, qu'est-ce que c'est ?

Full Page Cache (FPC) est une technique de mise en cache qui stocke l'intégralité de la page HTML générée par un site Web. Cette technique est essentielle pour les sites à fort trafic car elle réduit considérablement le nombre de requêtes adressées au serveur d'origine, réduisant ainsi la charge de travail des processus PHP et des connexions aux bases de données.

Comment Acheter

Lorsqu'un utilisateur visite une page Web, le serveur génère la page HTML et la met en cache. Les visites ultérieures sur la même page sont servies directement à partir du cache, évitant ainsi la régénération de la page et réduisant les temps de réponse.

conclusion

L'absence de cache HTML est un exemple classique de la façon dont l'absence d'une stratégie de mise en cache adéquate peut mettre à rude épreuve même les infrastructures les plus robustes comme AWS. Pour les sites à fort trafic, la mise en œuvre d'un système de mise en cache efficace est cruciale pour réduire la charge sur les serveurs d'origine, améliorer les temps de réponse et éviter des temps d'arrêt importants. Dans ce cas précis, il aurait suffi d'utiliser la version mensuelle de CloudFlare à 25 $, configurée par un bon ingénieur système, pour résoudre les problèmes de temps d'arrêt. Mieux encore, implémenter un système Varnish Cache avec CloudFlare placé devant aurait permis une double couche de cache. Cette configuration aurait offert des performances maximales à un coût certainement inférieur à celui actuel. Grâce à de telles solutions, il est possible d'obtenir des améliorations significatives des performances et de la stabilité du site, garantissant une expérience utilisateur optimale même pendant les pics de trafic.

Cela montre qu'au-delà du fournisseur des services que vous décidez d'utiliser, ce qui compte vraiment, c'est la compétence technique et l'expertise des techniciens chargés de mettre en œuvre la meilleure stratégie de mise en cache afin d'améliorer les performances et la diffusion du contenu.

Vous trouverez ci-dessous le trafic du site de notre client que l'équipe éditoriale de Passionastronomia.it nous a signalé pour des problèmes que nous aurions pu résoudre en 1 heure de travail et de conseil, économisant probablement environ 75% du budget qu'ils dépensent sur AWS pour se déconnecter. . Mais comme on dit dans ces cas-là, celui qui est la cause de son propre mal devrait pleurer pour lui-même.

Statistiques JetPack Compteur de visiteurs

Ce sera drôle quand les "factures" arriveront d'AWS et notamment d'Amazon RDS pour MySQL qui est un service Pay Per Use et qui va probablement augmenter considérablement les coûts. L'ingénierie des systèmes n'est pas un jeu d'enfant et comme vous pouvez le constater, des consultants techniques inexpérimentés peuvent non seulement causer des dégâts, mais aussi épuiser votre budget, sans savoir à quel point il pourrait être plus pratique de dépenser en investissant dans le CDN et le Full Page Cache, plutôt que dans le Managed. Services de base de données comme AWS RDS.

Nous lui avons dit…

 

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de The FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Hetzner Online GmbH détient les droits sur Hetzner® ; OVHcloud est une marque déposée d'OVH Groupe SAS ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Facebook, Inc. détient les droits sur Facebook®. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente en aucune manière aucune de ces entités. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

Retour en haut de page