{"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\/hr\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","title":{"rendered":"Ponekad je vi\u0161e manje. Kada smanjenje optere\u0107enja dovodi do pove\u0107anja ka\u0161njenja","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kao i u ve\u0107ini postova<\/a><\/noindex>, pojavila se problema s distribuiranom uslugom, nazovimo tu uslugu Elvin. Ovaj put nisam sam otkrio problem, obavijestili su me momci iz klijentskog dijela.<\/p>\n

Jednom sam se probudio zbog nezadovoljavaju\u0107e poruke o velikim ka\u0161njenjima kod Elvina, kojeg smo planirali pokrenuti uskoro. Naime, klijent se suo\u010dio s ka\u0161njenjem 99. percentila oko 50 ms, \u0161to je zna\u010dajno iznad na\u0161eg prora\u010duna ka\u0161njenja. To je bilo iznena\u0111uju\u0107e, jer sam pa\u017eljivo testirao uslugu, posebno na ka\u0161njenja, jer je to predmet \u010destih pritu\u017ebi.<\/p>\n

Prije nego \u0161to sam predao Elvina na testiranje, proveo sam mnogo eksperimenata s 40 tisu\u0107a zahtjeva u sekundi (QPS), svi su pokazali ka\u0161njenje manje od 10 ms. Bio sam spreman izjaviti da se ne sla\u017eem s njihovim rezultatima. No, ponovo gledaju\u0107i poruku, primijetio sam ne\u0161to novo: ja sigurno nisam testirao uvjete koje su spomenuli, njihov QPS je bio daleko ni\u017ei od mog. Ja sam testirao na 40k QPS, a oni samo na 1k. Pokrenuo sam jo\u0161 jedan eksperiment, ovaj put s ni\u017eim QPS, samo da ih umirim.
\n<\/a><\/noindex>
\nBudu\u0107i da o tome pi\u0161em u blogu \u2014 vjerojatno ste ve\u0107 shvatili: njihovi su brojevi bili to\u010dni. Provjeravao sam svog virtualnog klijenta iznova i iznova, sve s istim rezultatom: niska koli\u010dina zahtjeva ne samo da pove\u0107ava ka\u0161njenje, nego i pove\u0107ava broj zahtjeva s ka\u0161njenjem ve\u0107im od 10 ms. Drugim rije\u010dima, dok je na 40k QPS oko 50 zahtjeva u sekundi prema\u0161ilo 50 ms, na 1k QPS svake sekunde je bilo 100 zahtjeva iznad 50 ms. Paradoks!<\/p>\n

\"Ponekad
\n<\/p>\n

U\u017eavamo krug pretrage<\/h1>\n

\nSuo\u010deni s problemom ka\u0161njenja u distribuiranom sustavu s mnogo komponenti, prvo treba sastaviti kratak popis osumnji\u010denih. Kopajmo malo dublje u arhitekturi Elvina:<\/p>\n

\"Ponekad
\n
\nDobra polazna to\u010dka je popis izvr\u0161enih ulaza\/izlaza (mre\u017eni pozivi\/tra\u017eenje na disku itd.). Poku\u0161ajmo otkriti gdje je ka\u0161njenje. Osim o\u010ditih ulaza\/izlaza s klijentom, Elvin \u010dini dodatni korak: obra\u0107a se skladi\u0161tu podataka. Me\u0111utim, to skladi\u0161te radi u istom klasteru s Elvinom, stoga bi ka\u0161njenje tamo trebalo biti manje nego s klijentom. Dakle, popis osumnji\u010denih:<\/p>\n

    \n
  1. Mre\u017eni poziv od klijenta do Elvina.\n<\/li>\n
  2. Mre\u017eni poziv od Elvina prema spremi\u0161tu podataka.\n<\/li>\n
  3. Pretraga na disku u spremi\u0161tu podataka.\n<\/li>\n
  4. Mre\u017eni poziv iz spremi\u0161ta podataka prema Elvinu.\n<\/li>\n
  5. Mre\u017eni poziv od Elvina prema klijentu.<\/li>\n<\/ol>\n

    \nPoku\u0161ajmo izostaviti neke stavke.<\/p>\n

    Spremi\u0161te podataka nije u vezi s tim.<\/h3>\n

    \nPrvo sam Elvina pretvorio u ping-ping server koji ne obra\u0111uje zahtjeve. Kada primi zahtjev, vra\u0107a prazni odgovor. Ako se latencija smanjuje, onda je gre\u0161ka u implementaciji Elvina ili spremi\u0161ta podataka - ni\u0161ta izvanredno. U prvom eksperimentu dobivamo takav grafikon:<\/p>\n

    \"Ponekad
    \n
    \nKao \u0161to vidimo, kori\u0161tenje ping-ping servera ne pokazuje nikakva pobolj\u0161anja. To zna\u010di da spremi\u0161te podataka ne pove\u0107ava latenciju, a popis osumnji\u010denika se prepolovio:<\/p>\n

      \n
    1. Mre\u017eni poziv od klijenta do Elvina.\n<\/li>\n
    2. Mre\u017eni poziv od Elvina prema klijentu.<\/li>\n<\/ol>\n

      \nSuper! Popis se brzo smanjuje. Mislim da sam gotovo otkrio uzrok.<\/p>\n

      gRPC<\/h3>\n

      \nSada je vrijeme da vam predstavim novog igra\u010da: gRPC<\/a><\/noindex>. Ovo je knji\u017enica s otvorenim kodom od Googlea za me\u0111uprocesnu komunikaciju RPC<\/a><\/noindex>. Iako gRPC<\/code> dobro je optimizirana i \u0161iroko kori\u0161tena, prvi put sam je koristio u sustavu takvih razmjera, i o\u010dekivao sam da \u0107e moja implementacija biti neoptimalna - blago re\u010deno.<\/p>\n

      Prisutnost gRPC<\/code> u stogu je postavilo novo pitanje: mo\u017eda moja implementacija ili sam gRPC<\/code> uzrokuje problem latencije? Dodajemo novog osumnji\u010denika na popis:<\/p>\n

        \n
      1. Klijent poziva knji\u017enicu gRPC<\/code>\n<\/li>\n
      2. Biblioteka gRPC<\/code> na klijentu izvodi mre\u017eni poziv knji\u017enice gRPC<\/code> na serveru\n<\/li>\n
      3. Biblioteka gRPC<\/code> obra\u0107a se Elvinu (operacija nije prisutna u slu\u010daju ping-pong servera)<\/li>\n<\/ol>\n

        \nDa biste imali predod\u017ebu o kodu, moja implementacija klijenta\/Elvina ne razlikuje se mnogo od klijentsko-poslu\u017eiteljskih primjera async<\/a><\/noindex>.<\/p>\n

        Napomena: gornji popis je malo pojednostavljen, jer gRPC<\/code> omogu\u0107uje kori\u0161tenje vlastitog (predlo\u017eenog?) modela niti, u kojem se isprepli\u0107u stog izvr\u0161enja gRPC<\/code> i korisni\u010dka implementacija. Radi jednostavnosti, pridr\u017eavat \u0107emo se ovog modela.<\/i><\/p><\/blockquote>\n

        <\/p>\n

        Profiliranje \u0107e sve popraviti.<\/h3>\n

        \nIzostavljaju\u0107i spremi\u0161ta podataka, pomislio sam da sam gotovo zavr\u0161io: \"Sada je lako! Primijenimo profil i saznajmo gdje se javlja latencija\". Ja sam veliki obo\u017eavatelj to\u010dnog profiliranja<\/a><\/noindex>, jer su CPU vrlo brzi i naj\u010de\u0161\u0107e nisu usko grlo. Ve\u0107ina latencija se doga\u0111a kada procesor mora zaustaviti obradu da bi u\u010dinio ne\u0161to drugo. To\u010dno profiliranje CPU-a upravo je napravljeno za to: ono precizno bilje\u017ei sve. kontextualni prekida\u010di<\/a><\/noindex> i ukazuje gdje se javljaju zastoji.<\/p>\n

        Uzeo sam \u010detiri profila: jedan za visoki QPS (mala latencija) i onaj s ping-pong serverom na niskom QPS (velika latencija), kako na strani klijenta, tako i na strani servera. I kao dodatak, tako\u0111er sam uzeo uzorak CPU profila. Kada uspore\u0111ujem profile, obi\u010dno tra\u017eim abnormalan stog poziva. Na primjer, na lo\u0161oj strani s visokom latencijom dolazi do mnogo vi\u0161e prekida\u010da konteksta (10 ili vi\u0161e puta). No, u mom slu\u010daju, broj prekida\u010da konteksta prakti\u010dki je bio identi\u010dan. Na moje u\u017eas, nije bilo ni\u010dega zna\u010dajnog.<\/p>\n

        Dodatno debagiranje<\/h1>\n

        \nBio sam o\u010dajan. Nisam znao koje druge alate mogu koristiti, a moj sljede\u0107i plan bio je u biti ponoviti eksperiment s razli\u010ditim varijacijama, umjesto da jasno dijagnosticiram problem.<\/p>\n

        \u0160to ako<\/h3>\n

        \nOd samog po\u010detka mu\u010dila me specifi\u010dna latencija od 50 ms. To je vrlo dugo vrijeme. Odlu\u010dio sam da \u0107u izrezati dijelove koda dok ne otkrijem to\u010dno koji dio uzrokuje ovu gre\u0161ku. Zatim je uslijedio eksperiment koji je uspio.<\/p>\n

        Kao obi\u010dno, unazad se \u010dini da je sve bilo o\u010dito. Smjestio sam klijenta na jedan stroj s Elvinom - i poslao zahtjev u localhost<\/code>. I pove\u0107anje latencije je nestalo!<\/p>\n

        \"Ponekad
        \n
        \nNe\u0161to nije bilo u redu s mre\u017eom.<\/p>\n

        Usvajaju\u0107i vje\u0161tine mre\u017enog in\u017eenjera<\/h3>\n

        \nMoram priznati: moje znanje o mre\u017enim tehnologijama je stra\u0161no, posebno s obzirom na to da s njima radim svakodnevno. No, mre\u017ea je bila glavni sumnjivac, i trebao sam nau\u010diti kako je debagirati.<\/p>\n

        Na sre\u0107u, internet voli one koji \u017eele u\u010diti. Kombinacija pinga i tracerta \u010dinila se kao dobar po\u010detak za debagiranje problema s mre\u017enim prijenosom.<\/p>\n

        Prvo sam pokrenuo PsPing<\/a><\/noindex> na TCP portu Elvine. Koristio sam zadane postavke - ni\u0161ta posebno. Od vi\u0161e od tisu\u0107u pingova, nijedan nije prema\u0161io 10 ms, osim prvog za zagrijavanje. To se protivi zabilje\u017eenom pove\u0107anju latencije od 50 ms u 99. percentilu: tamo smo za svakih 100 zahtjeva trebali vidjeti otprilike jedan zahtjev s latencijom od 50 ms.<\/p>\n

        Zatim sam isprobao tracert<\/a><\/noindex>: mo\u017eda problem le\u017ei na jednom od \u010dvorova na putu izme\u0111u Elvine i klijenta. No, tracert se tako\u0111er vratio s praznim rukama.<\/p>\n

        Tako je uzrok ka\u0161njenja bio ne moj kod, ne implementacija gRPC i ne mre\u017ea. Ve\u0107 sam po\u010deo brinuti se da to nikada ne\u0107u shvatiti.<\/p>\n

        Na kojoj operativnoj sistemu se nalazimo<\/h3>\n

        \ngRPC<\/code> \u0161iroko se koristi u Linuxu, ali za Windows je to egzotika. Odlu\u010dio sam provesti eksperiment, koji je uspio: stvorio sam virtualnu ma\u0161inu Linux, iskompajlirao Elvina za Linux i postavio ga.<\/p>\n

        \"Ponekad
        \n
        \nI evo \u0161to se dogodilo: u ping-pong serveru Linux nije bilo takvih ka\u0161njenja, kao kod sli\u010dnog \u010dvora na Windowsu, iako izvor podataka nije bio druga\u010diji. Ispostavilo se da je problem u implementaciji gRPC za Windows.<\/p>\n

        Nagleov algoritam<\/h3>\n

        \nCijelo to vrijeme mislio sam da mi nedostaje zastavica gRPC<\/code>. Sada sam shvatio da zapravo nedostaje gRPC<\/code> Windows zastavica. Na\u0161ao sam internu RPC biblioteku, za koju sam bio siguran da dobro funkcionira za sve postavljene zastavice Winsock<\/a><\/noindex>. Zatim sam dodao sve te zastavice u gRPC i postavio Elvina na Windows, u ispravljenom ping-pong serveru pod Windowsom!<\/p>\n

        \"Ponekad
        \n
        \nSkoro<\/i> spremno: po\u010deo sam uklanjati dodane zastavice jednu po jednu, dok se regresija nije vratila, tako da sam mogao to\u010dno odrediti njen uzrok. To je bila zloglasna         TCP_NODELAY<\/a><\/noindex>, prekida\u010d Nagleovog algoritma.<\/p>\n

        Nagleov algoritam<\/a><\/noindex> poku\u0161ava smanjiti broj paketa poslanih preko mre\u017ee odga\u0111anjem slanja poruka dok veli\u010dina paketa ne prema\u0161i odre\u0111eni broj bajtova. Iako to mo\u017ee biti korisno za prosje\u010dnog korisnika, uni\u0161tava servere u stvarnom vremenu, jer OS odga\u0111a neke poruke, uzrokuju\u0107i ka\u0161njenja pri niskom QPS-u. Ovaj gRPC<\/code> bio je postavljen u implementaciji Linuxa za TCP sokete, ali ne i za Windows. To sam ispravio<\/a><\/noindex>.<\/p>\n

        Zaklju\u010dak<\/h1>\n

        \nVeliko ka\u0161njenje pri niskom QPS-u uzrokovala je optimizacija OS-a. Gledaju\u0107i unatrag, profiliranje nije otkrilo ka\u0161njenje jer je ra\u0111eno u kernel modu, a ne u korisni\u010dkom modu<\/a><\/noindex>. Ne znam mo\u017ee li se Nagleov algoritam promatrati kroz ETW snimke, ali to bi bilo zanimljivo.<\/p>\n

        \u0160to se ti\u010de eksperimenta localhost, vjerojatno se nije ticao stvarnog mre\u017enog koda, a Nagleov algoritam nije pokrenut, pa su problemi s ka\u0161njenjem nestali kada je klijent pristupio Elvinu putem localhosta.<\/p>\n

        Sljede\u0107i put kada primijetite pove\u0107anje ka\u0161njenja prilikom smanjenja broja zahtjeva u sekundi, Nagleov algoritam trebao bi biti na va\u0161em popisu osumnji\u010denih!
        \n
        Izvor:         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\udd47Ponekad je vi\u0161e \u2014 manje. Kada smanjenje optere\u0107enja dovodi do pove\u0107anja ka\u0161njenja | ProHoster","description":"Kao i kod ve\u0107ine postova, pojavila se problem s distribuiranom slu\u017ebom, nazovimo tu slu\u017ebu Elvin.","canonical_url":"https:\/\/prohoster.info\/hr\/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":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/33707","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=33707"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/33707\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/25389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=33707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=33707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=33707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}