{"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\/it\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","title":{"rendered":"A volte, di pi\u00f9 significa di meno. Quando la riduzione del carico porta a un aumento della latenza.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Come in gran parte dei post<\/a><\/noindex>, \u00e8 emerso un problema con il servizio distribuito, chiameremo questo servizio Elvin. Questa volta non ho scoperto il problema da solo, ma me lo hanno segnalato i ragazzi della parte cliente.<\/p>\n

Un giorno mi sono svegliato a causa di un'email di lamentele per l'elevata latenza di Elvin, che avevamo in programma di lanciare a breve. In particolare, il cliente ha riscontrato una latenza del 99\u00b0 percentile intorno ai 50 ms, ben oltre il nostro limite di latenza. \u00c8 stato sorprendente, perch\u00e9 avevo testato a fondo il servizio, in particolare per la latenza, che \u00e8 oggetto di frequenti lamentele.<\/p>\n

Prima di consegnare Elvin per il collaudo, ho condotto molti esperimenti con 40.000 richieste al secondo (QPS), tutti hanno mostrato una latenza inferiore ai 10 ms. Ero pronto a dichiarare che non ero d'accordo con i loro risultati. Ma guardando di nuovo l'email, ho notato qualcosa di nuovo: non avevo testato le condizioni che avevano menzionato, il loro QPS era molto pi\u00f9 basso del mio. Ho testato a 40k QPS, mentre loro solo a 1k. Ho avviato un altro esperimento, questa volta con un QPS pi\u00f9 basso, solo per accontentarli.
\n<\/a><\/noindex>
\nPoich\u00e9 ne parlo nel blog, \u00e8 probabile che tu l'abbia gi\u00e0 capito: i loro numeri si sono rivelati corretti. Ho controllato il mio cliente virtuale pi\u00f9 e pi\u00f9 volte, ottenendo sempre lo stesso risultato: un basso numero di richieste non solo aumenta la latenza, ma anche il numero di richieste con latenza superiore a 10 ms. In altre parole, se a 40k QPS circa 50 richieste al secondo superavano i 50 ms, a 1k QPS c'erano 100 richieste superiori a 50 ms ogni secondo. Paradossale!<\/p>\n

\"A
\n<\/p>\n

Raffiniamo la ricerca<\/h1>\n

\nDi fronte a un problema di latenza in un sistema distribuito con molti componenti, il primo passo \u00e8 stilare un breve elenco di sospetti. Approfondiamo un po' l'architettura di Alvin:<\/p>\n

\"A
\n
\nUn buon punto di partenza \u00e8 l'elenco delle transazioni di input\/output eseguite (chiamate di rete \/ ricerca su disco, ecc.). Cerchiamo di capire dove sia la latenza. Oltre all'evidente input\/output con il cliente, Alvin compie un passo aggiuntivo: si rivolge allo storage dei dati. Tuttavia, questo storage opera in un cluster con Alvin, quindi la latenza l\u00ec dovrebbe essere inferiore rispetto a quella con il cliente. Quindi, l'elenco dei sospetti:<\/p>\n

    \n
  1. Chiamata di rete dal cliente ad Alvin.\n<\/li>\n
  2. Chiamata di rete da Alvin al data center.\n<\/li>\n
  3. Ricerca sul disco nel data center.\n<\/li>\n
  4. Chiamata di rete dal data center ad Alvin.\n<\/li>\n
  5. Chiamata di rete da Alvin al cliente.<\/li>\n<\/ol>\n

    \nProviamo a escludere alcuni punti.<\/p>\n

    Il data center non centra niente.<\/h3>\n

    \nPer prima cosa ho trasformato Alvin in un server ping-ping che non gestisce le richieste. Una volta ricevuta una richiesta, restituisce una risposta vuota. Se il ritardo diminuisce, allora c'\u00e8 un errore nella nostra implementazione di Alvin o nel data center \u2014 nulla di anomalo. Nel primo esperimento otteniamo questo grafico:<\/p>\n

    \"A
    \n
    \nCome si pu\u00f2 vedere, non ci sono miglioramenti nell'uso del server ping-ping. Ci\u00f2 significa che il data center non aumenta il ritardo, e la lista dei sospetti si riduce della met\u00e0:<\/p>\n

      \n
    1. Chiamata di rete dal cliente ad Alvin.\n<\/li>\n
    2. Chiamata di rete da Alvin al cliente.<\/li>\n<\/ol>\n

      \nOttimo! La lista si sta riducendo rapidamente. Pensavo di aver quasi capito la causa.<\/p>\n

      gRPC<\/h3>\n

      \n\u00c8 il momento di presentarvi un nuovo attore: gRPC<\/a><\/noindex>. Si tratta di una libreria open source di Google per la comunicazione interprocesso. richiesta RPC<\/a><\/noindex>. Anche se gRPC<\/code> ben ottimizzato e ampiamente utilizzato, \u00e8 la prima volta che lo utilizzo in un sistema di tale scala, e mi aspettavo che la mia implementazione non fosse ottimale \u2014 per dirla in modo gentile.<\/p>\n

      Disponibilit\u00e0 gRPC<\/code> nel stack ha sollevato una nuova domanda: forse \u00e8 la mia implementazione o \u00e8 essa stessa gRPC<\/code> che causa il problema di latenza? Aggiungiamo alla lista un nuovo sospettato:<\/p>\n

        \n
      1. Il client chiama la libreria gRPC<\/code>\n<\/li>\n
      2. Libreria gRPC<\/code> sul client effettua una chiamata di rete alla libreria gRPC<\/code> sul server\n<\/li>\n
      3. Libreria gRPC<\/code> si rivolge a Elvin (non ci sono operazioni nel caso del server ping-pong)<\/li>\n<\/ol>\n

        \nPer farvi capire come appare il codice, la mia implementazione client\/Elvin non \u00e8 molto diversa da esempi client-server di async<\/a><\/noindex>.<\/p>\n

        Nota: l'elenco sopra riportato \u00e8 leggermente semplificato, poich\u00e9 gRPC<\/code> consente l'uso di un proprio (templato?) modello di flusso, in cui si intrecciano lo stack di esecuzione gRPC<\/code> e l'implementazione dell'utente. Per semplicit\u00e0, ci atteniamo a questo modello.<\/i><\/p><\/blockquote>\n

        <\/p>\n

        Il profiling sistemer\u00e0 tutto<\/h3>\n

        \nEscludendo i repository di dati, pensavo di essere quasi alla fine: \"Ora \u00e8 facile! Applichiamo il profilo e scopriamo dove si verifica la latenza\". Sono un grande sostenitore del profiling preciso<\/a><\/noindex>, perch\u00e9 la CPU \u00e8 molto veloce e di solito non \u00e8 un collo di bottiglia. La maggior parte dei ritardi si verifica quando il processore deve interrompere l'elaborazione per fare qualcos'altro. Il profilo CPU accurato \u00e8 stato creato proprio per questo: registra esattamente tutto i cambi di contesto<\/a><\/noindex> e permette di capire dove si verificano i ritardi.<\/p>\n

        Ho preso quattro profili: sotto un alto QPS (bassa latenza) e con un server ping-pong a basso QPS (alta latenza), sia dal lato client che dal lato server. E giusto per sicurezza, ho anche preso un campione del profilo della CPU. Quando confronto i profili, di solito cerco uno stack di chiamate anomalo. Ad esempio, sul lato negativo con alta latenza ci sono molti pi\u00f9 cambi di contesto (10 volte o pi\u00f9). Ma nel mio caso, il numero di cambi di contesto era praticamente identico. Con mia grande sorpresa, non c'era nulla di significativo.<\/p>\n

        Ulteriore debug<\/h1>\n

        \nEro disperato. Non sapevo quali altri strumenti poter utilizzare, e il mio prossimo piano era essenzialmente ripetere esperimenti con diverse varianti, piuttosto che diagnosticare chiaramente il problema.<\/p>\n

        Cosa succede se<\/h3>\n

        \nFin dall'inizio, mi preoccupava il tempo di latenza specifico di 50 ms. \u00c8 un tempo molto elevato. Ho deciso di rimuovere parti del codice fino a quando non sono riuscito a capire esattamente quale parte stesse causando l'errore. Poi \u00e8 seguito un esperimento che ha funzionato.<\/p>\n

        Come al solito, col senno di poi sembra che fosse tutto ovvio. Ho messo il cliente su una macchina con Alvin e ho inviato una richiesta a localhost<\/code>. E l'aumento della latenza \u00e8 scomparso!<\/p>\n

        \"A
        \n
        \nC'era qualcosa che non andava nella rete.<\/p>\n

        Acquisendo le competenze di un ingegnere di rete<\/h3>\n

        \nDevo ammettere: le mie conoscenze delle tecnologie di rete sono orribili, soprattutto considerando che ci lavoro ogni giorno. Ma la rete era il principale sospettato e dovevo imparare come debuggarla.<\/p>\n

        Fortunatamente, Internet premia coloro che vogliono imparare. La combinazione di ping e tracert sembrava un buon inizio per risolvere i problemi di trasporto di rete.<\/p>\n

        Per prima cosa, ho avviato PsPing<\/a><\/noindex> sulla porta TCP di Alvin. Ho utilizzato le impostazioni predefinite \u2014 nulla di particolare. Su oltre mille ping, nessuno ha superato i 10 ms, tranne il primo per il riscaldamento. Questo contrasta con l'aumento osservato della latenza di 50 ms nel 99\u00b0 percentile: l\u00ec, su ogni 100 richieste, avremmo dovuto vedere circa una richiesta con latenza di 50 ms.<\/p>\n

        Poi ho provato tracert<\/a><\/noindex>: forse il problema si trova su uno dei nodi lungo il percorso tra Alvin e il client. Ma anche il tracer \u00e8 tornato a mani vuote.<\/p>\n

        Quindi, la causa della latenza non era il mio codice, n\u00e9 l'implementazione di gRPC n\u00e9 la rete. Avevo gi\u00e0 cominciato a preoccuparmi di non capirlo mai.<\/p>\n

        Ora, su quale sistema operativo ci troviamo<\/h3>\n

        \ngRPC<\/code> \u00e8 ampiamente utilizzato in Linux, ma per Windows \u00e8 un'eccezione. Ho deciso di condurre un esperimento che ha funzionato: ho creato una macchina virtuale Linux, ho compilato Alvin per Linux e l'ho distribuito.<\/p>\n

        \"A
        \n
        \nEcco cosa ho scoperto: nel server ping-pong Linux non c'erano ritardi come nel nodo Windows equivalente, anche se la sorgente dei dati non era diversa. Si rivela che il problema \u00e8 nell'implementazione di gRPC per Windows.<\/p>\n

        L'algoritmo di Nagle<\/h3>\n

        \nTutto questo tempo ho pensato che mi mancasse il flag gRPC<\/code>. Ora ho capito che in realt\u00e0 \u00e8 nella gRPC<\/code> manca un flag di Windows. Ho trovato una libreria interna RPC di cui ero sicuro che funzionasse bene per tutti i flag installati Winsock<\/a><\/noindex>. Poi ho aggiunto tutti questi flag in gRPC e ho distribuito Alvin su Windows, con il server ping-pong corretto sotto Windows!<\/p>\n

        \"A
        \n
        \nQuasi<\/i> completo: ho iniziato a rimuovere i flag aggiunti uno alla volta, finch\u00e9 non \u00e8 riemersa la regressione, cos\u00ec ho potuto identificare con precisione la sua causa. Era il         TCP_NODELAY<\/a><\/noindex>, commutatore dell'algoritmo di Nagle.<\/p>\n

        L'algoritmo di Nagle<\/a><\/noindex> cerca di ridurre il numero di pacchetti inviati sulla rete ritardando la trasmissione dei messaggi fino a quando la dimensione del pacchetto non supera un certo numero di byte. Sebbene questo possa essere piacevole per l'utente medio, \u00e8 devastante per i server in tempo reale, poich\u00e9 il sistema operativo ritarder\u00e0 alcuni messaggi, causando ritardi a bassa QPS. Ho gRPC<\/code> impostato questo flag nell'implementazione Linux per i socket TCP, ma non per Windows. L'ho corretto<\/a><\/noindex>.<\/p>\n

        Conclusione<\/h1>\n

        \nUn grande ritardo a bassa QPS era causato dall'ottimizzazione del sistema operativo. Guardando indietro, il profiling non ha rilevato il ritardo, perch\u00e9 era fatto in modalit\u00e0 kernel, e non in modalit\u00e0 utente<\/a><\/noindex>. Non so se sia possibile osservare l'algoritmo di Nagle attraverso le catture ETW, ma sarebbe interessante.<\/p>\n

        Per quanto riguarda l'esperimento localhost, probabilmente non ha interessato il codice di rete effettivo, e l'algoritmo di Nagle non \u00e8 stato attivato, quindi i problemi di latenza sono svaniti quando il client ha contattato Alvin tramite localhost.<\/p>\n

        La prossima volta che noterai un aumento della latenza con la diminuzione delle richieste al secondo, l'algoritmo di Nagle dovrebbe essere nella tua lista dei sospetti!
        \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\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\udd47A volte di pi\u00f9 significa meno. Quando la diminuzione del carico porta a un aumento della latenza | ProHoster","description":"Come in molti post, \u00e8 emerso un problema con un servizio distribuito, chiamiamo questo servizio Alvin. Questa volta non ho scoperto personalmente il problema, ma me lo hanno segnalato i ragazzi della parte client. Una mattina mi sono svegliato a causa di una mail di reclamo per grandi ritardi con Alvin, che avevamo programmato di avviare a breve. In particolare, il cliente ha riscontrato un ritardo al 99\u00b0 percentile in","canonical_url":"https:\/\/prohoster.info\/it\/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":"it_IT","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. \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","og:url":"https:\/\/prohoster.info\/it\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33707","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=33707"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33707\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/25389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=33707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=33707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=33707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}