{"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\/pt\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","title":{"rendered":"\u00c0s vezes, menos \u00e9 mais. Quando a redu\u00e7\u00e3o da carga leva ao aumento da lat\u00eancia","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Assim como no na maioria das postagens<\/a><\/noindex>, surgiu um problema com o servi\u00e7o distribu\u00eddo, que chamaremos de Elvin. Desta vez, eu n\u00e3o descobri o problema por conta pr\u00f3pria, fui informado pela equipe de suporte ao cliente.<\/p>\n

Certa vez, acordei com um e-mail insatisfeito devido a grandes atrasos no Elvin, que planej\u00e1vamos lan\u00e7ar em breve. Em particular, o cliente enfrentou um atraso no percentil 99 em torno de 50 ms, muito acima do nosso or\u00e7amento de lat\u00eancia. Isso foi surpreendente, pois testei rigorosamente o servi\u00e7o, especialmente em rela\u00e7\u00e3o \u00e0 lat\u00eancia, que \u00e9 um assunto de frequentes queixas.<\/p>\n

Antes de entregar o Elvin para testes, realizei muitos experimentos com 40 mil solicita\u00e7\u00f5es por segundo (QPS), todos mostraram lat\u00eancia inferior a 10 ms. Eu estava pronto para afirmar que n\u00e3o concordava com os resultados deles. Mas ao olhar novamente para o e-mail, notei algo novo: eu definitivamente n\u00e3o testei as condi\u00e7\u00f5es que eles mencionaram, o QPS deles era muito menor que o meu. Eu testei em 40 mil QPS, enquanto eles apenas com 1 mil. Realizei outro experimento, desta vez com um QPS mais baixo, apenas para agrad\u00e1-los.
\n<\/a><\/noindex>
\nComo estou escrevendo sobre isso no blog \u2013 provavelmente voc\u00ea j\u00e1 percebeu: os n\u00fameros deles estavam corretos. Verifiquei meu cliente virtual repetidamente, tudo com o mesmo resultado: um baixo n\u00famero de solicita\u00e7\u00f5es n\u00e3o apenas aumenta a lat\u00eancia, mas tamb\u00e9m aumenta o n\u00famero de solicita\u00e7\u00f5es com lat\u00eancia superior a 10 ms. Em outras palavras, se em 40 mil QPS cerca de 50 solicita\u00e7\u00f5es por segundo excediam 50 ms, em 1 mil QPS havia 100 solicita\u00e7\u00f5es acima de 50 ms a cada segundo. Paradoxo!<\/p>\n

\"\u00c0s
\n<\/p>\n

Afunilando a busca<\/h1>\n

\nEnfrentando um problema de lat\u00eancia em um sistema distribu\u00eddo com muitos componentes, a primeira coisa a fazer \u00e9 elaborar uma lista curta de suspeitos. Vamos nos aprofundar um pouco mais na arquitetura do Elvin:<\/p>\n

\"\u00c0s
\n
\nUm bom ponto de partida \u00e9 a lista de transi\u00e7\u00f5es de entrada e sa\u00edda realizadas (chamadas de rede \/ busca no disco etc.). Vamos tentar descobrir onde est\u00e1 a lat\u00eancia. Al\u00e9m da \u00f3bvia entrada e sa\u00edda com o cliente, o Elvin faz um passo adicional: ele consulta o armazenamento de dados. No entanto, esse armazenamento funciona em um cluster com o Elvin, ent\u00e3o a lat\u00eancia l\u00e1 deve ser menor do que com o cliente. Assim, a lista de suspeitos:<\/p>\n

    \n
  1. Chamada de rede do cliente para o Elvin.\n<\/li>\n
  2. Chamada de rede do Elvin para o armazenamento de dados.\n<\/li>\n
  3. Busca no disco no armazenamento de dados.\n<\/li>\n
  4. Chamado de rede do armazenamento de dados para Elvin.\n<\/li>\n
  5. Chamado de rede de Elvin para o cliente.<\/li>\n<\/ol>\n

    \nVamos tentar eliminar alguns pontos.<\/p>\n

    O armazenamento de dados nada tem a ver com isso<\/h3>\n

    \nPrimeiro, transformei Elvin em um servidor ping-ping, que n\u00e3o processa solicita\u00e7\u00f5es. Ao receber uma solicita\u00e7\u00e3o, ele retorna uma resposta vazia. Se a lat\u00eancia diminui, \u00e9 um erro na implementa\u00e7\u00e3o de Elvin ou do armazenamento de dados - nada de incomum. No primeiro experimento, obtemos este gr\u00e1fico:<\/p>\n

    \"\u00c0s
    \n
    \nComo podemos ver, ao usar o servidor ping-ping, n\u00e3o h\u00e1 melhora alguma. Isso significa que o armazenamento de dados n\u00e3o aumenta a lat\u00eancia, e a lista de suspeitos \u00e9 reduzida pela metade:<\/p>\n

      \n
    1. Chamada de rede do cliente para o Elvin.\n<\/li>\n
    2. Chamado de rede de Elvin para o cliente.<\/li>\n<\/ol>\n

      \n\u00d3timo! A lista est\u00e1 diminuindo rapidamente. Eu pensei que quase descobri a causa.<\/p>\n

      gRPC<\/h3>\n

      \nAgora \u00e9 a hora de apresentar um novo jogador: gRPC<\/a><\/noindex>. Esta \u00e9 uma biblioteca de c\u00f3digo aberto do Google para comunica\u00e7\u00e3o intra-processo RPC<\/a><\/noindex>. Embora gRPC<\/code> seja bem otimizada e amplamente utilizada, \u00e9 a primeira vez que a uso em um sistema dessa escala, e eu esperava que minha implementa\u00e7\u00e3o fosse sub\u00f3tima - para dizer o m\u00ednimo.<\/p>\n

      A presen\u00e7a de gRPC<\/code> no stack gerou uma nova pergunta: pode ser que minha implementa\u00e7\u00e3o ou a pr\u00f3pria gRPC<\/code> causa o problema da lat\u00eancia? Adicionamos um novo suspeito \u00e0 lista:<\/p>\n

        \n
      1. O cliente chama a biblioteca gRPC<\/code>\n<\/li>\n
      2. A biblioteca gRPC<\/code> no cliente, executa a chamada de rede da biblioteca gRPC<\/code> no servidor\n<\/li>\n
      3. A biblioteca gRPC<\/code> se conecta a Elvin (sem opera\u00e7\u00e3o no caso do servidor ping-pong)<\/li>\n<\/ol>\n

        \nPara que voc\u00eas entendam como \u00e9 o c\u00f3digo, minha implementa\u00e7\u00e3o do cliente\/Elvin n\u00e3o difere muito dos exemplos de cliente-servidor ass\u00edncronos<\/a><\/noindex>.<\/p>\n

        Nota: a lista acima \u00e9 um pouco simplificada, pois gRPC<\/code> permite o uso de um modelo de thread pr\u00f3prio (template?), onde o stack de execu\u00e7\u00e3o se entrela\u00e7a gRPC<\/code> com a implementa\u00e7\u00e3o do usu\u00e1rio. Para simplificar, seguiremos este modelo.<\/i><\/p><\/blockquote>\n

        <\/p>\n

        O perfilamento resolver\u00e1 tudo<\/h3>\n

        \nEliminando os armazenamentos de dados, pensei que estava quase l\u00e1: \"Agora \u00e9 f\u00e1cil! Vamos aplicar o perfil e descobrir onde a lat\u00eancia aparece\". Eu sou um grande f\u00e3 do perfilamento preciso<\/a><\/noindex>, porque a CPU \u00e9 muito r\u00e1pida e costuma n\u00e3o ser o gargalo. A maioria das lat\u00eancias ocorre quando a CPU deve parar de processar para fazer algo mais. O perfilamento preciso da CPU \u00e9 feito exatamente para isso: ele registra com precis\u00e3o todas as trocadilhos de contexto<\/a><\/noindex> e mostra onde ocorrem as lat\u00eancias.<\/p>\n

        Eu peguei quatro perfis: para um alto QPS (baixa lat\u00eancia) e com um servidor ping-pong em baixo QPS (alta lat\u00eancia), tanto do lado do cliente quanto do lado do servidor. E s\u00f3 para garantir, tamb\u00e9m peguei uma amostra do perfil do processador. Ao comparar os perfis, normalmente procuro por pilhas de chamadas an\u00f4malas. Por exemplo, no lado ruim com alta lat\u00eancia, h\u00e1 muito mais mudan\u00e7as de contexto (10 vezes ou mais). Mas, neste meu caso, o n\u00famero de mudan\u00e7as de contexto quase coincidiu. Para meu horror, n\u00e3o havia nada significativo l\u00e1.<\/p>\n

        Depura\u00e7\u00e3o adicional<\/h1>\n

        \nEu estava desesperado. N\u00e3o sabia que outras ferramentas poderiam ser usadas, e meu pr\u00f3ximo plano consistia basicamente em repetir experimentos com diferentes varia\u00e7\u00f5es, em vez de diagnosticar claramente o problema.<\/p>\n

        E se<\/h3>\n

        \nDesde o in\u00edcio, estava preocupado com um tempo de lat\u00eancia espec\u00edfico de 50 ms. Isso \u00e9 um tempo muito alto. Decidi que cortaria peda\u00e7os do c\u00f3digo at\u00e9 conseguir descobrir exatamente qual parte estava causando esse erro. Ent\u00e3o, veio um experimento que funcionou.<\/p>\n

        Como sempre, com a mente retrospectiva, parece que tudo era \u00f3bvio. Coloquei o cliente em uma m\u00e1quina com Elvin\u2014 e enviei a solicita\u00e7\u00e3o para localhost<\/code>. E o aumento da lat\u00eancia desapareceu!<\/p>\n

        \"\u00c0s
        \n
        \nAlgo estava errado com a rede.<\/p>\n

        Acumulando habilidades de engenheiro de rede<\/h3>\n

        \nDevo confessar: meu conhecimento em tecnologias de rede \u00e9 horr\u00edvel, especialmente considerando que trabalho com elas diariamente. Mas a rede era o principal suspeito, e eu precisava aprender como depur\u00e1-la.<\/p>\n

        Felizmente, a internet gosta dos que querem aprender. A combina\u00e7\u00e3o de ping e tracert parecia um bom come\u00e7o para depurar problemas de transporte de rede.<\/p>\n

        Primeiro, executei PsPing<\/a><\/noindex> na porta TCP de Elvin. Usei as configura\u00e7\u00f5es padr\u00e3o \u2014 nada de especial. De mais de mil pings, nenhum ultrapassou 10 ms, exceto o primeiro para aquecimento. Isso contradiz o aumento observado de lat\u00eancia de 50 ms no 99\u00ba percentil: para cada 100 solicita\u00e7\u00f5es, dever\u00edamos ter visto cerca de uma solicita\u00e7\u00e3o com lat\u00eancia de 50 ms.<\/p>\n

        Ent\u00e3o eu tentei tracert<\/a><\/noindex>: talvez o problema esteja em um dos n\u00f3s do caminho entre Elvin e o cliente. Mas o tracer tamb\u00e9m voltou de m\u00e3os vazias.<\/p>\n

        Assim, a causa da lat\u00eancia n\u00e3o era meu c\u00f3digo, nem a implementa\u00e7\u00e3o do gRPC, nem a rede. Comecei a me preocupar que nunca entenderia isso.<\/p>\n

        Agora, em qual sistema operacional estamos?<\/h3>\n

        \ngRPC<\/code> \u00e9 amplamente utilizado no Linux, mas para Windows \u00e9 ex\u00f3tico. Decidi realizar um experimento que funcionou: criei uma m\u00e1quina virtual Linux, compilei o Elvin para Linux e o implantei.<\/p>\n

        \"\u00c0s
        \n
        \nE eis o que aconteceu: no servidor ping-pong Linux n\u00e3o houve os mesmos atrasos que na inst\u00e2ncia correspondente do Windows, embora a fonte de dados n\u00e3o tenha mudado. A quest\u00e3o parece estar na implementa\u00e7\u00e3o do gRPC para Windows.<\/p>\n

        O Algoritmo Nagle<\/h3>\n

        \nDurante todo esse tempo eu pensei que me faltava uma bandeira. gRPC<\/code>Agora eu entendi que, na verdade, faltava a gRPC<\/code> bandeira do Windows. Encontrei uma biblioteca interna RPC na qual tinha certeza de que funcionava bem para todas as bandeiras instaladas Winsock<\/a><\/noindex>. Depois adicionei todas essas bandeiras ao gRPC e implantei o Elvin no Windows, no servidor ping-pong corrigido para Windows!<\/p>\n

        \"\u00c0s
        \n
        \nQuase<\/i> pronto: comecei a remover as bandeiras adicionadas uma a uma, at\u00e9 que a regress\u00e3o voltou, assim pude identificar sua causa com precis\u00e3o. Era o infame         TCP_NODELAY<\/a><\/noindex>, o interruptor do algoritmo Nagle.<\/p>\n

        O Algoritmo Nagle<\/a><\/noindex> tenta reduzir o n\u00famero de pacotes enviados pela rede, retardando a transmiss\u00e3o das mensagens at\u00e9 que o tamanho do pacote exceda um certo n\u00famero de bytes. Embora isso possa ser agrad\u00e1vel para o usu\u00e1rio m\u00e9dio, \u00e9 prejudicial para servidores em tempo real, pois o sistema operacional retardar\u00e1 algumas mensagens, causando atrasos em um baixo QPS. O gRPC<\/code> tinha essa bandeira configurada na implementa\u00e7\u00e3o do Linux para sockets TCP, mas n\u00e3o para Windows. Eu corrigi<\/a><\/noindex>.<\/p>\n

        Conclus\u00e3o<\/h1>\n

        \nUm grande atraso em um baixo QPS foi causado pela otimiza\u00e7\u00e3o do sistema operacional. Ao olhar para tr\u00e1s, a profilagem n\u00e3o detectou o atraso, porque foi realizada no modo n\u00facleo, e n\u00e3o no modo de usu\u00e1rio<\/a><\/noindex>. N\u00e3o sei se \u00e9 poss\u00edvel observar o algoritmo Nagle atrav\u00e9s das capturas ETW, mas seria interessante.<\/p>\n

        Quanto ao experimento localhost, provavelmente n\u00e3o envolveu o c\u00f3digo de rede real, e o algoritmo Nagle n\u00e3o foi acionado, ent\u00e3o os problemas de atraso desapareceram quando o cliente acessou o Elvin atrav\u00e9s do localhost.<\/p>\n

        Da pr\u00f3xima vez que voc\u00ea notar um aumento no atraso ao diminuir o n\u00famero de solicita\u00e7\u00f5es por segundo, o algoritmo Nagle deve estar em sua lista de suspeitos!
        \n
        Fonte:         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\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\udd47\u00c0s vezes, mais \u00e9 menos. Quando a redu\u00e7\u00e3o da carga resulta em maior lat\u00eancia | ProHoster","description":"Como na maioria das postagens, surgiu um problema com o servi\u00e7o distribu\u00eddo, vamos chamar esse servi\u00e7o de Elvin.","canonical_url":"https:\/\/prohoster.info\/pt\/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":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/33707","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=33707"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33707\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/25389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=33707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=33707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=33707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}