{"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\/da\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","title":{"rendered":"Nogle gange betyder mere mindre. N\u00e5r reduktion af belastningen f\u00f8rer til \u00f8get forsinkelse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Som i de fleste indl\u00e6g<\/a><\/noindex>, opstod der et problem med den distribuerede service, lad os kalde denne service Elvin. Denne gang var det ikke mig selv, der opdagede problemet, men drengene fra klientdelen, der informerede mig.<\/p>\n

En dag v\u00e5gnede jeg op til en utilfreds besked ang\u00e5ende store forsinkelser hos Elvin, som vi planlagde at lancere snart. Specifikt oplevede kunden en forsinkelse p\u00e5 99. percentilen p\u00e5 omkring 50 ms, langt over vores gr\u00e6nse for forsinkelse. Det var overraskende, da jeg havde testet tjenesten omhyggeligt, is\u00e6r hvad ang\u00e5r forsinkelser, da dette ofte er et klagepunkt.<\/p>\n

F\u00f8r jeg sendte Elvin til test, udf\u00f8rte jeg mange eksperimenter med 40.000 foresp\u00f8rgsler pr. sekund (QPS), og alle viste en forsinkelse p\u00e5 mindre end 10 ms. Jeg var klar til at p\u00e5st\u00e5, at jeg ikke var enig i deres resultater. Men da jeg s\u00e5 p\u00e5 brevet igen, lagde jeg m\u00e6rke til noget nyt: jeg havde helt sikkert ikke testet under de forhold, de n\u00e6vnte, deres QPS var meget lavere end min. Jeg testede ved 40k QPS, og de kun ved 1k. Jeg udf\u00f8rte endnu et eksperiment, denne gang med lavere QPS, bare for at tilfredsstille dem.
\n<\/a><\/noindex>
\nDa jeg skriver om dette p\u00e5 bloggen \u2014 har du nok allerede indset det: deres tal viste sig at v\u00e6re korrekte. Jeg kontrollerede min virtuelle klient igen og igen, alt med det samme resultat: lavt antal foresp\u00f8rgsler \u00f8ger ikke kun forsinkelsen, men \u00f8ger ogs\u00e5 antallet af foresp\u00f8rgsler med forsinkelse over 10 ms. Med andre ord, hvis der ved 40k QPS var omkring 50 foresp\u00f8rgsler pr. sekund, der oversteg 50 ms, s\u00e5 var der ved 1k QPS 100 foresp\u00f8rgsler hver sekund over 50 ms. Paradoxalt!<\/p>\n

\"Nogle
\n<\/p>\n

Indskr\u00e6nk s\u00f8gningen<\/h1>\n

\nN\u00e5r man st\u00e5r over for forsinkelsesproblemer i et distribueret system med mange komponenter, er det f\u00f8rste skridt at lave en kort liste over mist\u00e6nkte. Lad os dykke lidt dybere ned i Elvins arkitektur:<\/p>\n

\"Nogle
\n
\nEn god start ville v\u00e6re listen over udf\u00f8rte input-output overgange (netv\u00e6rk kald\/ diskopslag osv.). Lad os fors\u00f8ge at finde ud af, hvor forsinkelsen opst\u00e5r. Udover de \u00e5benlyse input-output med klienten foretager Elvin et ekstra skridt: han henvender sig til datalageret. Men dette lager fungerer i et cluster med Elvin, s\u00e5 forsinkelsen der b\u00f8r v\u00e6re mindre end med klienten. S\u00e5 her er listen over mist\u00e6nkte:<\/p>\n

    \n
  1. Netv\u00e6rksopkald fra klienten til Elvin.\n<\/li>\n
  2. Netv\u00e6rksopkald fra Elvin til datalageret.\n<\/li>\n
  3. S\u00f8gning p\u00e5 disket i datalageret.\n<\/li>\n
  4. Netv\u00e6rksanrop fra datalageret til Elvin.\n<\/li>\n
  5. Netv\u00e6rksanrop fra Elvin til klienten.<\/li>\n<\/ol>\n

    \nLad os pr\u00f8ve at udelukke nogle punkter.<\/p>\n

    Datalageret er ikke involveret<\/h3>\n

    \nF\u00f8rst og fremmest transformerede jeg Elvin til en ping-ping server, der ikke behandler anmodninger. N\u00e5r jeg modtager en anmodning, returnerer den et tomt svar. Hvis forsinkelsen falder, s\u00e5 er fejlen i implementeringen af Elvin eller datalageret - intet us\u00e6dvanligt. I det f\u00f8rste eksperiment f\u00e5r vi f\u00f8lgende graf:<\/p>\n

    \"Nogle
    \n
    \nSom vi kan se, er der ingen forbedringer ved brug af ping-ping serveren. Det betyder, at datalageret ikke \u00f8ger forsinkelsen, og listen over mist\u00e6nkte formindskes med halvdelen:<\/p>\n

      \n
    1. Netv\u00e6rksopkald fra klienten til Elvin.\n<\/li>\n
    2. Netv\u00e6rksanrop fra Elvin til klienten.<\/li>\n<\/ol>\n

      \nFantastisk! Listen formindskes hurtigt. Jeg troede, jeg n\u00e6sten havde fundet \u00e5rsagen.<\/p>\n

      gRPC<\/h3>\n

      \nNu er det tid til at introducere jer for en ny spiller: gRPC<\/a><\/noindex>. Det er et open source-bibliotek fra Google til inter-process kommunikation RPC<\/a><\/noindex>. Selvom gRPC<\/code> det er godt optimeret og bredt anvendt, er det f\u00f8rste gang, jeg bruger det i et system af denne st\u00f8rrelse, og jeg forventede, at min implementering ville v\u00e6re suboptimal - mildt sagt.<\/p>\n

      Tilstedev\u00e6relsen af gRPC<\/code> i stakken rejste et nyt sp\u00f8rgsm\u00e5l: kunne det v\u00e6re min implementering eller selve gRPC<\/code> for\u00e5rsager forsinkelsesproblemet? Vi tilf\u00f8jer en ny mist\u00e6nkt til listen:<\/p>\n

        \n
      1. Klienten kalder biblioteket gRPC<\/code>\n<\/li>\n
      2. Bibliotek gRPC<\/code> p\u00e5 klienten udf\u00f8rer et netv\u00e6rksopkald til biblioteket gRPC<\/code> p\u00e5 serveren\n<\/li>\n
      3. Bibliotek gRPC<\/code> henvender sig til Elvin (ingen operation i tilf\u00e6lde af ping-pong serveren)<\/li>\n<\/ol>\n

        \nFor at I skal forst\u00e5, hvordan koden ser ud, adskiller min implementering af klienten\/Elvin sig ikke meget fra klient-server eksempler p\u00e5 async<\/a><\/noindex>.<\/p>\n

        Bem\u00e6rk: den ovenfor n\u00e6vnte liste er lidt forenklet, da gRPC<\/code> den giver mulighed for brug af en egen (skabelon?) tr\u00e5dmodel, hvor udf\u00f8relsesstakken gRPC<\/code> og brugerimplementeringen flettes sammen. For enkelhedens skyld holder vi os til denne model.<\/i><\/p><\/blockquote>\n

        <\/p>\n

        Profilering vil l\u00f8se alt<\/h3>\n

        \nVed at udelukke datalagerne troede jeg, jeg n\u00e6sten var f\u00e6rdig: \"Nu bliver det nemt! Lad os anvende profilen og finde ud af, hvor forsinkelsen opst\u00e5r.\" Jeg er en stor tilh\u00e6nger af pr\u00e6cis profilering<\/a><\/noindex>, fordi CPU'en er meget hurtig og oftest ikke er flaskehalsen. De fleste forsinkelser opst\u00e5r, n\u00e5r processoren skal stoppe behandlingen for at g\u00f8re noget andet. Pr\u00e6cis CPU-profilering er lavet til netop dette: den registrerer pr\u00e6cist alle context switches<\/a><\/noindex> og giver indsigt i, hvor forsinkelserne opst\u00e5r.<\/p>\n

        Jeg tog fire profiler: \u00e9n til h\u00f8j QPS (lav forsinkelse) og med en ping-pong server p\u00e5 lav QPS (h\u00f8j forsinkelse), b\u00e5de p\u00e5 klientsiden og serversiden. Og for en sikkerheds skyld tog jeg ogs\u00e5 en pr\u00f8veprofil af CPU'en. N\u00e5r jeg sammenligner profiler, leder jeg typisk efter en abnorm funktionstak. For eksempel, p\u00e5 den d\u00e5rlige side med h\u00f8j forsinkelse er der betydeligt flere kontekstskift (10 gange eller mere). Men i mit tilf\u00e6lde var antallet af kontekstskift n\u00e6sten det samme. Til min skr\u00e6k var der ikke noget v\u00e6sentligt at finde.<\/p>\n

        Yderligere fejlfinding<\/h1>\n

        \nJeg var fortvivlet. Jeg vidste ikke, hvilke flere v\u00e6rkt\u00f8jer jeg kunne bruge, og min n\u00e6ste plan var i bund og grund at gentage eksperimenterne med forskellige variationer i stedet for at diagnosticere problemet klart.<\/p>\n

        Hvad nu hvis<\/h3>\n

        \nFra starten var jeg bekymret over den specifikke forsinkelse p\u00e5 50 ms. Det er en meget lang tid. Jeg besluttede, at jeg ville klippe stykker af koden, indtil jeg kunne finde ud af, hvilken del der for\u00e5rsagede denne fejl. Derefter fulgte et eksperiment, som lykkedes.<\/p>\n

        Som s\u00e6dvanligt, med bagklogskab virker alt indlysende. Jeg placerede klienten p\u00e5 \u00e9n maskine med Elvin - og sendte en anmodning til localhost<\/code>. Og forsinkelsen forsvandt!<\/p>\n

        \"Nogle
        \n
        \nNoget var galt med netv\u00e6rket.<\/p>\n

        L\u00e6rer f\u00e6rdighederne fra netv\u00e6rksingeni\u00f8ren<\/h3>\n

        \nJeg m\u00e5 indr\u00f8mme: mine netv\u00e6rksteknologiske f\u00e6rdigheder er forf\u00e6rdelige, is\u00e6r i betragtning af at jeg arbejder med dem dagligt. Men netv\u00e6rket var den prim\u00e6re mist\u00e6nkte, og jeg havde brug for at l\u00e6re at fejlfinde det.<\/p>\n

        Heldigvis elsker internettet dem, der \u00f8nsker at l\u00e6re. Kombinationen af ping og tracert virkede som et godt udgangspunkt for at fejlfinde netv\u00e6rkstransportproblemer.<\/p>\n

        For det f\u00f8rste k\u00f8rte jeg PsPing<\/a><\/noindex> p\u00e5 TCP-porten til Elvin. Jeg brugte standardindstillingerne - ikke noget s\u00e6rligt. Af mere end tusinde pings oversteg ingen 10 ms, undtagen den f\u00f8rste for opvarmning. Dette st\u00e5r i kontrast til den observerede forsinkelse p\u00e5 50 ms i 99. percentil: der burde vi have set omkring \u00e9n anmodning med 50 ms forsinkelse for hver 100 anmodninger.<\/p>\n

        Derefter pr\u00f8vede jeg tracert<\/a><\/noindex>: m\u00e5ske er problemet ved en af noderne p\u00e5 ruten mellem Elvin og klienten. Men traceren kom ogs\u00e5 tilbage uden resultater.<\/p>\n

        Derfor var \u00e5rsagen til forsinkelsen ikke min kode, ikke implementeringen af gRPC og ikke netv\u00e6rket. Jeg begyndte allerede at frygte, at jeg aldrig ville forst\u00e5 dette.<\/p>\n

        Nu, hvilket OS er vi p\u00e5<\/h3>\n

        \ngRPC<\/code> er bredt anvendt i Linux, men for Windows er det eksotisk. Jeg besluttede at udf\u00f8re et eksperiment, som lykkedes: jeg oprettede en virtuel Linux-maskine, kompilerede Alvin til Linux og deployerede den.<\/p>\n

        \"Nogle
        \n
        \nOg her er hvad der kom ud af det: i ping-pong serveren p\u00e5 Linux var der ikke de samme forsinkelser som p\u00e5 den tilsvarende Windows-node, selvom datakilden ikke var forskellig. Problemet viste sig at v\u00e6re implementeringen af gRPC for Windows.<\/p>\n

        Nagle-algoritmen<\/h3>\n

        \nI hele denne tid har jeg troet, at jeg manglede en flag gRPC<\/code>. Nu forst\u00e5r jeg, at det faktisk er en gRPC<\/code> flag for Windows, der mangler. Jeg fandt et internt RPC-bibliotek, som jeg var sikker p\u00e5 fungerede godt for alle installerede flag Winsock<\/a><\/noindex>. Jeg tilf\u00f8jede s\u00e5 alle disse flag til gRPC og deployerede Alvin p\u00e5 Windows, i den reviderede ping-pong server under Windows!<\/p>\n

        \"Nogle
        \n
        \nN\u00e6sten<\/i> klar: jeg begyndte at fjerne de tilf\u00f8jede flag \u00e9t ad gangen, indtil regressionen kom tilbage, s\u00e5 jeg kunne bestemme \u00e5rsagen pr\u00e6cist. Det var den berygtede         TCP_NODELAY<\/a><\/noindex>, Nagle-algoritmen switch.<\/p>\n

        Nagle-algoritmen<\/a><\/noindex> fors\u00f8ger at reducere antallet af pakker sendt over netv\u00e6rket ved at forsinke overf\u00f8rslen af meddelelser, indtil pakkest\u00f8rrelsen overstiger et bestemt antal bytes. Selvom dette kan v\u00e6re godt for den gennemsnitlige bruger, er det \u00f8del\u00e6ggende for realtidsservere, da OS vil forsinke nogle meddelelser, hvilket medf\u00f8rer forsinkelser ved lav QPS. Der gRPC<\/code> var dette flag sat i Linux-implementeringen for TCP-sockets, men ikke for Windows. Jeg fandt det rettet<\/a><\/noindex>.<\/p>\n

        Konklusion<\/h1>\n

        \nDen store forsinkelse ved lav QPS skyldtes OS' optimering. N\u00e5r jeg ser tilbage, kunne profileringen ikke opdage forsinkelsen, fordi den blev foretaget i kernel-tilstand, ikke i brugerstand<\/a><\/noindex>. Jeg ved ikke, om man kan observere Nagle-algoritmen gennem ETW-optagelser, men det ville v\u00e6re interessant.<\/p>\n

        Hvad ang\u00e5r localhost-eksperimentet, ber\u00f8rte det sandsynligvis ikke den faktiske netv\u00e6rkskode, og Nagle-algoritmen blev ikke aktiveret, s\u00e5 forsinkelsesproblemerne forsvandt, da klienten tilsluttede Alvin via localhost.<\/p>\n

        N\u00e6ste gang du ser en stigning i forsinkelse med faldende anmodninger per sekund, skal Nagle-algoritmen v\u00e6re p\u00e5 din mist\u00e6nkte liste!
        \n
        Kilde:         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\udd47Nogle gange er mere mindre. N\u00e5r reduktion af belastningen medf\u00f8rer \u00f8get forsinkelse | ProHoster","description":"Som med de fleste indl\u00e6g opstod der et problem med den distribuerede tjeneste, lad os kalde denne tjeneste Alvin.","canonical_url":"https:\/\/prohoster.info\/da\/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":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/33707","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=33707"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/33707\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/25389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=33707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=33707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=33707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}