{"id":33707,"date":"2019-10-31T21:54:17","date_gmt":"2019-10-31T18:54:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki\/"},"modified":"2019-10-31T21:54:17","modified_gmt":"2019-10-31T18:54:17","slug":"inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","title":{"rendered":"Parfois, plus c'est moins. Lorsque la r\u00e9duction de la charge entra\u00eene une augmentation du d\u00e9lai.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Comme dans la plupart des messages<\/a><\/noindex>, un probl\u00e8me est survenu avec le service distribu\u00e9, appelons ce service Elvin. Cette fois, je n'ai pas d\u00e9couvert le probl\u00e8me moi-m\u00eame, c'est l'\u00e9quipe c\u00f4t\u00e9 client qui m'en a inform\u00e9.<\/p>\n

Un jour, je me suis r\u00e9veill\u00e9 \u00e0 cause d'un e-mail m\u00e9content \u00e0 propos de gros d\u00e9lais avec Elvin, que nous pr\u00e9voyions de lancer tr\u00e8s bient\u00f4t. En particulier, le client avait rencontr\u00e9 un d\u00e9lai au 99\u00e8me percentile d'environ 50 ms, bien au-dessus de notre budget de latence. C'\u00e9tait surprenant, car j'avais soigneusement test\u00e9 le service, notamment pour la latence, qui est un sujet de plaintes fr\u00e9quentes.<\/p>\n

Avant de confier Elvin aux tests, j'avais r\u00e9alis\u00e9 de nombreuses exp\u00e9riences avec 40 000 requ\u00eates par seconde (QPS), toutes ont montr\u00e9 une latence inf\u00e9rieure \u00e0 10 ms. J'\u00e9tais pr\u00eat \u00e0 affirmer que je n'\u00e9tais pas d'accord avec leurs r\u00e9sultats. Mais en regardant de nouveau l'e-mail, j'ai remarqu\u00e9 quelque chose de nouveau : je n'avais pas du tout test\u00e9 les conditions qu'ils avaient mentionn\u00e9es, leur QPS \u00e9tait bien inf\u00e9rieur au mien. J'avais test\u00e9 \u00e0 40k QPS, tandis qu'ils n'\u00e9taient qu'\u00e0 1k. J'ai lanc\u00e9 une autre exp\u00e9rience, cette fois avec un QPS plus bas, juste pour les apaiser.
\n<\/a><\/noindex>
\nPuisque j'\u00e9cris \u00e0 ce sujet sur le blog \u2014 vous avez probablement d\u00e9j\u00e0 compris : leurs chiffres se sont av\u00e9r\u00e9s corrects. J'ai v\u00e9rifi\u00e9 mon client virtuel encore et encore, avec le m\u00eame r\u00e9sultat : un faible nombre de requ\u00eates non seulement augmente la latence, mais augmente \u00e9galement le nombre de requ\u00eates avec une latence sup\u00e9rieure \u00e0 10 ms. En d'autres termes, alors qu'avec 40k QPS environ 50 requ\u00eates par seconde d\u00e9passaient 50 ms, avec 1k QPS, il y avait 100 requ\u00eates par seconde sup\u00e9rieures \u00e0 50 ms. Paradoxe !<\/p>\n

\"Parfois,
\n<\/p>\n

R\u00e9duisons le champ de recherche<\/h1>\n

\nConfront\u00e9 \u00e0 un probl\u00e8me de latence dans un syst\u00e8me distribu\u00e9 avec de nombreux composants, la premi\u00e8re \u00e9tape consiste \u00e0 \u00e9tablir une liste restreinte de suspects. Creusons un peu plus dans l'architecture d'Elvin :<\/p>\n

\"Parfois,
\n
\nUn bon point de d\u00e9part est la liste des transitions d'entr\u00e9es-sorties effectu\u00e9es (appels r\u00e9seau \/ recherche sur disque, etc.). Essayons de comprendre o\u00f9 se situe la latence. En plus de l'\u00e9vident E\/S avec le client, Elvin fait une \u00e9tape suppl\u00e9mentaire : il se connecte au stockage des donn\u00e9es. Cependant, ce stockage fonctionne dans le m\u00eame cluster qu'Elvin, donc la latence l\u00e0 devrait \u00eatre inf\u00e9rieure \u00e0 celle avec le client. Ainsi, la liste des suspects :<\/p>\n

    \n
  1. Appel r\u00e9seau du client \u00e0 Elvin.\n<\/li>\n
  2. Appel r\u00e9seau d'Elvin au stockage des donn\u00e9es.\n<\/li>\n
  3. Recherche sur disque dans le stockage des donn\u00e9es.\n<\/li>\n
  4. Appel r\u00e9seau du stockage de donn\u00e9es vers Elvin.\n<\/li>\n
  5. Appel r\u00e9seau d'Elvin au client.<\/li>\n<\/ol>\n

    \nEssayons de rayer certains \u00e9l\u00e9ments.<\/p>\n

    Le stockage de donn\u00e9es n'est pas en cause.<\/h3>\n

    \nTout d'abord, j'ai transform\u00e9 Elvin en serveur ping-ping qui ne traite pas les requ\u00eates. D\u00e8s qu'il re\u00e7oit une requ\u00eate, il renvoie une r\u00e9ponse vide. Si le d\u00e9lai diminue, alors l'erreur se trouve dans l'impl\u00e9mentation d'Elvin ou du stockage de donn\u00e9es - rien d'extraordinaire. Dans la premi\u00e8re exp\u00e9rience, nous obtenons ce graphique :<\/p>\n

    \"Parfois,
    \n
    \nComme nous le voyons, en utilisant le serveur ping-ping, aucune am\u00e9lioration n'est not\u00e9e. Cela signifie que le stockage de donn\u00e9es n'augmente pas le d\u00e9lai, et la liste des suspects est r\u00e9duite de moiti\u00e9 :<\/p>\n

      \n
    1. Appel r\u00e9seau du client \u00e0 Elvin.\n<\/li>\n
    2. Appel r\u00e9seau d'Elvin au client.<\/li>\n<\/ol>\n

      \nSuper ! La liste se r\u00e9duit rapidement. Je pensais avoir presque trouv\u00e9 la cause.<\/p>\n

      gRPC<\/h3>\n

      \nIl est maintenant temps de vous pr\u00e9senter un nouveau joueur : gRPC<\/a><\/noindex>. C'est une biblioth\u00e8que open-source de Google pour la communication inter-processus. RPC<\/a><\/noindex>. Bien que gRPC<\/code> bien optimis\u00e9e et largement utilis\u00e9e, c'est la premi\u00e8re fois que je l'utilise dans un syst\u00e8me d'une telle ampleur, et je m'attendais \u00e0 ce que mon impl\u00e9mentation soit sous-optimale - pour le dire poliment.<\/p>\n

      Pr\u00e9sence gRPC<\/code> dans la pile a soulev\u00e9 une nouvelle question : est-ce que c'est mon impl\u00e9mentation ou la biblioth\u00e8que elle-m\u00eame gRPC<\/code> causerait le probl\u00e8me de d\u00e9lai ? Ajoutons \u00e0 la liste un nouveau suspect :<\/p>\n

        \n
      1. Le client appelle la biblioth\u00e8que. gRPC<\/code>\n<\/li>\n
      2. Biblioth\u00e8que gRPC<\/code> sur le client effectue l'appel r\u00e9seau de la biblioth\u00e8que. gRPC<\/code> sur le serveur\n<\/li>\n
      3. Biblioth\u00e8que gRPC<\/code> se connecte \u00e0 Elvin (pas d'op\u00e9ration dans le cas du serveur ping-pong).<\/li>\n<\/ol>\n

        \nPour que vous compreniez \u00e0 quoi ressemble le code, mon impl\u00e9mentation client\/Elvin ne diff\u00e8re pas beaucoup des exemples client-serveur. de type async.<\/a><\/noindex>.<\/p>\n

        Remarque : la liste ci-dessus est l\u00e9g\u00e8rement simplifi\u00e9e, car gRPC<\/code> permet d'utiliser son propre mod\u00e8le de flux (template ?) dans lequel s'entrelacent la pile d'ex\u00e9cution gRPC<\/code> et l'impl\u00e9mentation utilisateur. Par simplicit\u00e9, restons sur ce mod\u00e8le.<\/i><\/p><\/blockquote>\n

        <\/p>\n

        Le profilage r\u00e9soudra tout.<\/h3>\n

        \nAvoir exclu les stockages de donn\u00e9es, je pensais que j'avais presque fini : \u00ab Maintenant, c'est facile ! Appliquons le profil et d\u00e9couvrons o\u00f9 se situe le d\u00e9lai \u00bb. Je suis un grand fan du profilage pr\u00e9cis,<\/a><\/noindex>parce que le CPU est tr\u00e8s rapide et est souvent pas le goulot d'\u00e9tranglement. La plupart des d\u00e9lais se produisent lorsque le processeur doit arr\u00eater le traitement pour faire autre chose. Le profilage pr\u00e9cis du CPU est fait exactement pour \u00e7a : il enregistre avec pr\u00e9cision tous les changement de contexte<\/a><\/noindex> et permet de comprendre o\u00f9 se produisent les d\u00e9lais.<\/p>\n

        J'ai pris quatre profils : un pour un QPS \u00e9lev\u00e9 (faible latence) et un avec un serveur ping-pong \u00e0 faible QPS (grande latence), \u00e0 la fois c\u00f4t\u00e9 client et c\u00f4t\u00e9 serveur. Et juste au cas o\u00f9, j'ai \u00e9galement pris un \u00e9chantillon de profil de processeur. Lors de la comparaison des profils, je recherche g\u00e9n\u00e9ralement une pile d'appels anormale. Par exemple, du c\u00f4t\u00e9 mauvais avec une latence \u00e9lev\u00e9e, il y a beaucoup plus de changements de contexte (10 fois ou plus). Mais dans mon cas, le nombre de changements de contexte co\u00efncidait pratiquement. \u00c0 ma grande horreur, il n'y avait rien de substantiel.<\/p>\n

        D\u00e9bogage suppl\u00e9mentaire<\/h1>\n

        \nJ'\u00e9tais d\u00e9sesp\u00e9r\u00e9. Je ne savais pas quels autres outils utiliser, et mon prochain plan consistait essentiellement \u00e0 r\u00e9p\u00e9ter des exp\u00e9riences avec diff\u00e9rentes variations, plut\u00f4t qu'\u00e0 diagnostiquer clairement le probl\u00e8me.<\/p>\n

        Et si<\/h3>\n

        \nDepuis le d\u00e9but, une latence sp\u00e9cifique de 50 ms me pr\u00e9occupait. C'est un temps tr\u00e8s \u00e9lev\u00e9. J'ai d\u00e9cid\u00e9 de couper des morceaux de code jusqu'\u00e0 ce que je puisse d\u00e9terminer exactement quelle partie provoquait cette erreur. Ensuite, une exp\u00e9rience a suivi, qui a fonctionn\u00e9.<\/p>\n

        Comme d'habitude, avec le recul, tout semblait \u00e9vident. J'ai mis le client sur une machine avec Elvin - et j'ai envoy\u00e9 une requ\u00eate \u00e0 localhost<\/code>. Et l'augmentation de latence a disparu !<\/p>\n

        \"Parfois,
        \n
        \nIl y avait quelque chose qui clochait avec le r\u00e9seau.<\/p>\n

        D\u00e9velopper des comp\u00e9tences d'ing\u00e9nieur r\u00e9seau<\/h3>\n

        \nJe dois admettre : mes connaissances en technologies r\u00e9seau sont terribles, surtout consid\u00e9rant que je travaille avec elles tous les jours. Mais le r\u00e9seau \u00e9tait le principal suspect, et je devais apprendre \u00e0 le d\u00e9boguer.<\/p>\n

        Heureusement, Internet aime ceux qui veulent apprendre. La combinaison de ping et de tracert semblait \u00eatre un bon d\u00e9but pour d\u00e9boguer les probl\u00e8mes de transport r\u00e9seau.<\/p>\n

        Tout d'abord, j'ai lanc\u00e9 PsPing<\/a><\/noindex> sur le port TCP d'Elvin. J'ai utilis\u00e9 les param\u00e8tres par d\u00e9faut - rien de sp\u00e9cial. Sur plus de mille pings, aucun n'a d\u00e9pass\u00e9 10 ms, sauf le premier pour le pr\u00e9chauffage. Cela contredit l'augmentation observ\u00e9e de la latence de 50 ms au 99e percentile : l\u00e0, pour chaque 100 requ\u00eates, nous devrions voir environ une requ\u00eate avec une latence de 50 ms.<\/p>\n

        Puis j'ai essay\u00e9 tracert<\/a><\/noindex>: peut-\u00eatre que le probl\u00e8me se situe sur l'un des n\u0153uds du chemin entre Elvin et le client. Mais le traceur est \u00e9galement revenu les mains vides.<\/p>\n

        Ainsi, la cause de la latence n'\u00e9tait ni mon code, ni l'impl\u00e9mentation gRPC, ni le r\u00e9seau. J'ai d\u00e9j\u00e0 commenc\u00e9 \u00e0 m'inqui\u00e9ter de ne jamais comprendre cela.<\/p>\n

        Alors, sur quel OS sommes-nous ?<\/h3>\n

        \ngRPC<\/code> Il est largement utilis\u00e9 sur Linux, mais c'est exotique pour Windows. J'ai d\u00e9cid\u00e9 de mener une exp\u00e9rience qui a fonctionn\u00e9 : j'ai cr\u00e9\u00e9 une machine virtuelle Linux, compil\u00e9 Alvin pour Linux et l'ai d\u00e9ploy\u00e9.<\/p>\n

        \"Parfois,
        \n
        \nEt voici ce qui s'est pass\u00e9 : dans le serveur ping-pong de Linux, il n'y avait pas de latences comme sur l'\u00e9quivalent Windows, bien que la source des donn\u00e9es soit rest\u00e9e identique. Le probl\u00e8me semble venir de l'impl\u00e9mentation de gRPC pour Windows.<\/p>\n

        L'algorithme de Nagle<\/h3>\n

        \nTout ce temps, je pensais qu'il me manquait un drapeau gRPC<\/code>. Maintenant, je comprends qu'en fait, c'est dans gRPC<\/code> le drapeau Windows qui manque. J'ai trouv\u00e9 une biblioth\u00e8que RPC interne, en \u00e9tant s\u00fbr qu'elle fonctionne bien pour tous les drapeaux install\u00e9s. Winsock<\/a><\/noindex>. J'ai ensuite ajout\u00e9 tous ces drapeaux \u00e0 gRPC et d\u00e9ploy\u00e9 Alvin sur Windows, dans le serveur ping-pong corrig\u00e9 sous Windows !<\/p>\n

        \"Parfois,
        \n
        \nPresque<\/i> termin\u00e9 : j'ai commenc\u00e9 \u00e0 supprimer les drapeaux ajout\u00e9s un par un, jusqu'\u00e0 ce que la r\u00e9gression revienne, ce qui m'a permis de d\u00e9terminer pr\u00e9cis\u00e9ment sa cause. C'\u00e9tait le tristement c\u00e9l\u00e8bre         TCP_NODELAY<\/a><\/noindex>, le commutateur de l'algorithme de Nagle.<\/p>\n

        L'algorithme de Nagle<\/a><\/noindex> essaye de r\u00e9duire le nombre de paquets envoy\u00e9s sur le r\u00e9seau en retardant la transmission des messages jusqu'\u00e0 ce que la taille du paquet d\u00e9passe un certain nombre d'octets. Bien que cela puisse \u00eatre agr\u00e9able pour l'utilisateur moyen, cela est destructeur pour les serveurs en temps r\u00e9el, car l'OS retarde certains messages, provoquant des retards \u00e0 faible QPS. Un gRPC<\/code> avait ce drapeau activ\u00e9 dans l'impl\u00e9mentation Linux pour les sockets TCP, mais pas pour Windows. Je l'ai corrig\u00e9<\/a><\/noindex>.<\/p>\n

        Conclusion<\/h1>\n

        \nLa grande latence \u00e0 faible QPS \u00e9tait caus\u00e9e par une optimisation de l'OS. En y repensant, le profilage n'a pas d\u00e9tect\u00e9 de latence, car il a \u00e9t\u00e9 effectu\u00e9 en mode noyau, et non en mode utilisateur<\/a><\/noindex>. Je ne sais pas si l'on peut observer l'algorithme de Nagle \u00e0 travers des captures ETW, mais ce serait int\u00e9ressant.<\/p>\n

        Concernant l'exp\u00e9rience localhost, elle ne concernait probablement pas le code r\u00e9seau r\u00e9el, et l'algorithme de Nagle ne s'est pas activ\u00e9, donc les probl\u00e8mes de latence ont disparu lorsque le client a acc\u00e9d\u00e9 \u00e0 Alvin via localhost.<\/p>\n

        La prochaine fois que vous verrez une augmentation de la latence avec une diminution du nombre de requ\u00eates par seconde, l'algorithme de Nagle doit \u00eatre sur votre liste des suspects !
        \n
        Source :         habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

        \u041a\u0430\u043a \u0438 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u0435 \u043f\u043e\u0441\u0442\u043e\u0432, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0441 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u043e\u0439 \u0441\u043b\u0443\u0436\u0431\u043e\u0439, \u043d\u0430\u0437\u043e\u0432\u0451\u043c \u044d\u0442\u0443 \u0441\u043b\u0443\u0436\u0431\u0443 \u042d\u043b\u0432\u0438\u043d. \u041d\u0430 \u044d\u0442\u043e\u0442 \u0440\u0430\u0437 \u044f \u043d\u0435 \u0441\u0430\u043c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u043b \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443, \u043c\u043d\u0435 \u0441\u043e\u043e\u0431\u0449\u0438\u043b\u0438 \u0440\u0435\u0431\u044f\u0442\u0430 \u0441 \u043a\u043b\u0438\u0435\u043d\u0442\u0441\u043a\u043e\u0439 \u0447\u0430\u0441\u0442\u0438. \u041e\u0434\u043d\u0430\u0436\u0434\u044b \u044f \u043f\u0440\u043e\u0441\u043d\u0443\u043b\u0441\u044f \u043e\u0442 \u043d\u0435\u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e\u0433\u043e \u043f\u0438\u0441\u044c\u043c\u0430 \u0438\u0437-\u0437\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0437\u0430\u0434\u0435\u0440\u0436\u0435\u043a \u0443 \u042d\u043b\u0432\u0438\u043d\u0430, \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0432 \u0431\u043b\u0438\u0436\u0430\u0439\u0448\u0435\u0435 \u0432\u0440\u0435\u043c\u044f. \u0412 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u043a\u043b\u0438\u0435\u043d\u0442 \u0441\u0442\u043e\u043b\u043a\u043d\u0443\u043b\u0441\u044f \u0441 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u043e\u0439 99-\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u043d\u0442\u0438\u043b\u044f \u0432 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33707","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Parfois, moins c'est plus. Lorsque la r\u00e9duction de la charge entra\u00eene une augmentation de la latence | ProHoster","description":"Comme dans la plupart des posts, un probl\u00e8me est apparu avec le service distribu\u00e9, appelons ce service Alvin.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u043d\u043e\u0433\u0434\u0430 \u0431\u043e\u043b\u044c\u0448\u0435 \u2014 \u044d\u0442\u043e \u043c\u0435\u043d\u044c\u0448\u0435. \u041a\u043e\u0433\u0434\u0430 \u0443\u043c\u0435\u043d\u044c\u0448\u0435\u043d\u0438\u0435 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043f\u0440\u0438\u0432\u043e\u0434\u0438\u0442 \u043a \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u044e \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438 | ProHoster","og:description":"\u041a\u0430\u043a \u0438 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u0435 \u043f\u043e\u0441\u0442\u043e\u0432, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0441 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u043e\u0439 \u0441\u043b\u0443\u0436\u0431\u043e\u0439, \u043d\u0430\u0437\u043e\u0432\u0451\u043c \u044d\u0442\u0443 \u0441\u043b\u0443\u0436\u0431\u0443 \u042d\u043b\u0432\u0438\u043d.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:54:17+00:00","article:modified_time":"2019-10-31T18:54:17+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33707","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 16:23:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:35:31","updated":"2026-01-21 16:23:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/33707","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=33707"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/33707\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/25389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=33707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=33707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=33707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}