{"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\/ro\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","title":{"rendered":"Uneori mai mult \u00eenseamn\u0103 mai pu\u021bin. C\u00e2nd reducerea sarcinii duce la cre\u0219terea \u00eent\u00e2rzierii","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ca \u0219i \u00een majoritatea post\u0103rilor<\/a><\/noindex>, a ap\u0103rut o problem\u0103 cu serviciul distribuit, s\u0103-i spunem Elvin. De aceast\u0103 dat\u0103 nu am descoperit eu problema, ci mi-au raportat-o colegii din partea clien\u021bilor.<\/p>\n

\u00centr-o diminea\u021b\u0103 m-am trezit cu un email nemul\u021bumit din cauza \u00eent\u00e2rzierilor mari \u00een Elvin, pe care inten\u021bionam s\u0103-l lans\u0103m \u00een cur\u00e2nd. \u00cen special, clientul s-a confruntat cu o \u00eent\u00e2rziere de 99% \u00een jur de 50 ms, mult peste bugetul nostru de \u00eent\u00e2rziere. A fost surprinz\u0103tor, deoarece testasem cu aten\u021bie serviciul, mai ales pentru \u00eent\u00e2rzieri, \u00eentruc\u00e2t acesta era subiectul pl\u00e2ngerilor frecvente.<\/p>\n

\u00cenainte de a-l da pe Elvin \u00een testare, am efectuat multe experimente cu 40.000 de cereri pe secund\u0103 (QPS), toate ar\u0103t\u00e2nd \u00eent\u00e2rzieri de mai pu\u021bin de 10 ms. Eram preg\u0103tit s\u0103 afirm c\u0103 nu sunt de acord cu rezultatele lor. Dar, arunc\u00e2nd o privire din nou la email, am observat ceva nou: nu testasem condi\u021biile pe care le men\u021bionaser\u0103, QPS-ul lor fiind mult mai mic dec\u00e2t al meu. Eu testasem la 40k QPS, iar ei doar la 1k. Am ini\u021biat un alt experiment, de aceast\u0103 dat\u0103 cu un QPS mai mic, doar pentru a-i r\u0103sf\u0103\u021ba.
\n<\/a><\/noindex>
\nDeoarece scriu despre acest lucru pe blog \u2014 probabil c\u0103 a\u021bi \u00een\u021beles deja: cifrele lor s-au dovedit a fi corecte. Am verificat clientul meu virtual din nou \u0219i din nou, av\u00e2nd acela\u0219i rezultat: un num\u0103r mic de cereri nu doar c\u0103 cre\u0219te \u00eent\u00e2rzierea, dar cre\u0219te \u0219i num\u0103rul cererilor cu \u00eent\u00e2rzieri de peste 10 ms. Cu alte cuvinte, dac\u0103 la 40k QPS aproximativ 50 de cereri pe secund\u0103 dep\u0103\u0219eau 50 ms, atunci la 1k QPS erau 100 de cereri pe secund\u0103 care dep\u0103\u0219eau 50 ms. Paradix!<\/p>\n

\"Uneori
\n<\/p>\n

Restr\u00e2ngem c\u0103utarea<\/h1>\n

\nAfar\u0103 fiind cu o problem\u0103 de \u00eent\u00e2rziere \u00eentr-un sistem distribuit cu multe componente, primul lucru de f\u0103cut este s\u0103 cre\u0103m o list\u0103 scurt\u0103 de suspec\u021bi. S\u0103 ne aprofund\u0103m pu\u021bin \u00een arhitectura lui Elvin:<\/p>\n

\"Uneori
\n
\nUn bun punct de plecare este lista tranzi\u021biilor de I\/O efectuate (apeluri de re\u021bea\/c\u0103ut\u0103ri pe disc etc.). S\u0103 \u00eencerc\u0103m s\u0103 afl\u0103m unde se afl\u0103 \u00eent\u00e2rzierile. \u00cen afar\u0103 de evidentul I\/O cu clientul, Elvin face un pas suplimentar: comunic\u0103 cu stocarea de date. Totu\u0219i, aceast\u0103 stocare func\u021bioneaz\u0103 \u00eentr-un singur cluster cu Elvin, astfel c\u0103 \u00eent\u00e2rzerea acolo ar trebui s\u0103 fie mai mic\u0103 dec\u00e2t cu clientul. A\u0219adar, lista suspec\u021bilor:<\/p>\n

    \n
  1. Apelul de re\u021bea de la client la Elvin.\n<\/li>\n
  2. Apelul de re\u021bea de la Elvin la stocarea de date.\n<\/li>\n
  3. C\u0103utarea pe disc \u00een stocarea de date.\n<\/li>\n
  4. Apel de re\u021bea din stocarea de date c\u0103tre Elvin.\n<\/li>\n
  5. Apel de re\u021bea de la Elvin c\u0103tre client.<\/li>\n<\/ol>\n

    \nHaide\u021bi s\u0103 \u00eencerc\u0103m s\u0103 elimin\u0103m unele puncte.<\/p>\n

    Stocarea de date nu are nicio vin\u0103.<\/h3>\n

    \nMai \u00eent\u00e2i, am transformat Elvin \u00eentr-un server ping-ping, care nu proceseaz\u0103 cererile. La primirea cererii, returneaz\u0103 un r\u0103spuns gol. Dac\u0103 \u00eent\u00e2rzierea scade, atunci problema este \u00een realizarea lui Elvin sau a stoc\u0103rii de date - nimic de neobi\u0219nuit. \u00cen primul experiment, ob\u021binem urm\u0103torul grafic:<\/p>\n

    \"Uneori
    \n
    \nDup\u0103 cum vedem, folosind serverul ping-ping nu observ\u0103m nicio \u00eembun\u0103t\u0103\u021bire. Aceasta \u00eenseamn\u0103 c\u0103 stocarea de date nu m\u0103re\u0219te \u00eent\u00e2rzierea, iar lista suspec\u021bilor se reduce la jum\u0103tate:<\/p>\n

      \n
    1. Apelul de re\u021bea de la client la Elvin.\n<\/li>\n
    2. Apel de re\u021bea de la Elvin c\u0103tre client.<\/li>\n<\/ol>\n

      \nGroaz\u0103! Lista se reduce repede. Credeam c\u0103 aproape am descoperit cauza.<\/p>\n

      gRPC<\/h3>\n

      \nAcum este momentul s\u0103 v\u0103 prezint un nou juc\u0103tor: gRPC<\/a><\/noindex>. Este o bibliotec\u0103 open-source de la Google pentru comunica\u021bii intra-proces. RPC<\/a><\/noindex>. De\u0219i gRPC<\/code> este bine optimizat\u0103 \u0219i folosit\u0103 pe scar\u0103 larg\u0103, eu am folosit-o pentru prima dat\u0103 \u00eentr-un sistem de aceast\u0103 magnitudine, \u0219i m\u0103 a\u0219teptam ca implementarea mea s\u0103 fie suboptimal\u0103 - ca s\u0103 m\u0103 exprim bl\u00e2nd.<\/p>\n

      Prezen\u021ba gRPC<\/code> \u00een stiv\u0103 a generat o nou\u0103 \u00eentrebare: poate c\u0103 implementarea mea sau gRPC<\/code> provoac\u0103 problema \u00eent\u00e2rzierii? Ad\u0103ug\u0103m un nou suspect pe list\u0103:<\/p>\n

        \n
      1. Clientul apeleaz\u0103 biblioteca. gRPC<\/code>\n<\/li>\n
      2. Biblioteca gRPC<\/code> pe client efectueaz\u0103 un apel de re\u021bea al bibliotecii. gRPC<\/code> pe serverul\n<\/li>\n
      3. Biblioteca gRPC<\/code> se adreseaz\u0103 lui Elvin (opera\u021bia nu exist\u0103 \u00een cazul serverului ping-pong).<\/li>\n<\/ol>\n

        \nPentru a \u00een\u021belege cum arat\u0103 codul, implementarea mea client\/Elvin nu se deosebe\u0219te mult de exemplele client-server async.<\/a><\/noindex>.<\/p>\n

        Nota: lista de mai sus este oarecum simplificat\u0103, deoarece gRPC<\/code> permite utilizarea propriului model de flux (\u0219ablon?), \u00een care se \u00eentre\u021bes stiva de execu\u021bie gRPC<\/code> \u0219i implementarea utilizatorului. De dragul simplit\u0103\u021bii, ne vom men\u021bine la acest model.<\/i><\/p><\/blockquote>\n

        <\/p>\n

        Profilarea va corecta totul.<\/h3>\n

        \nElimin\u00e2nd stoc\u0103rile de date, am crezut c\u0103 aproape am terminat: \u201eAcum e simplu! Aplic\u0103m profilul \u0219i afl\u0103m unde apare \u00eent\u00e2rzierea\u201d. Eu sunt un mare fan al profil\u0103rii precise.<\/a><\/noindex>, deoarece CPU-ul este foarte rapid \u0219i de cele mai multe ori nu reprezint\u0103 un punct critic. Cele mai multe \u00eent\u00e2rzieri apar atunci c\u00e2nd procesorul trebuie s\u0103 opreasc\u0103 procesarea pentru a face altceva. Profilarea precis\u0103 a CPU-ului este f\u0103cut\u0103 tocmai pentru asta: \u00eenregistreaz\u0103 cu exactitate toate comut\u0103rile de context<\/a><\/noindex> \u0219i ofer\u0103 o \u00een\u021belegere a locurilor unde apar \u00eent\u00e2rzierile.<\/p>\n

        Am luat patru profiluri: pentru un QPS ridicat (latenta mic\u0103) \u0219i cu un server ping-pong pe QPS sc\u0103zut (latenta mare), at\u00e2t pe partea clientului, c\u00e2t \u0219i pe partea serverului. \u0218i, doar pentru precau\u021bie, am luat \u0219i un exemplu de profil CPU. C\u00e2nd compar profilele, caut de obicei un stack de apeluri anormal. De exemplu, pe partea proast\u0103 cu latenta mare, se observ\u0103 mult mai multe comut\u0103ri de context (de 10 ori sau mai mult). Dar \u00een cazul meu, num\u0103rul comut\u0103rilor de context a fost practic acela\u0219i. Spre groaza mea, nu a fost nimic semnificativ.<\/p>\n

        Diagnosticare suplimentar\u0103<\/h1>\n

        \nAm fost \u00een disperare. Nu \u0219tiam ce alte instrumente s\u0103 folosesc, iar planul meu urm\u0103tor consta practic \u00een repetarea experimentelor cu varia\u021bii diferite, \u0219i nu \u00een diagnosticarea clar\u0103 a problemei.<\/p>\n

        Ce-ar fi dac\u0103<\/h3>\n

        \n\u00cenca de la \u00eenceput, m-a \u00eengrijorat timpul de laten\u021b\u0103 specific de 50 ms. Este un timp foarte mare. Am decis s\u0103 extrag buc\u0103\u021bi din cod p\u00e2n\u0103 c\u00e2nd voi putea determina exact care parte cauzeaz\u0103 aceast\u0103 eroare. A urmat un experiment care a func\u021bionat.<\/p>\n

        A\u0219a cum se \u00eent\u00e2mpl\u0103 de obicei, \u00een urm\u0103 pare c\u0103 totul a fost evident. Am pus clientul pe aceea\u0219i ma\u0219in\u0103 cu Elvin - \u0219i am trimis o cerere \u00een localhost<\/code>. \u0218i cre\u0219terea laten\u021bei a disp\u0103rut!<\/p>\n

        \"Uneori
        \n
        \nEra ceva \u00een neregul\u0103 cu re\u021beaua.<\/p>\n

        \u00cenv\u0103\u021barea abilit\u0103\u021bilor de inginer de re\u021bea<\/h3>\n

        \nTrebuie s\u0103 recunosc: cuno\u0219tin\u021bele mele \u00een tehnologia re\u021belurilor sunt groaznice, mai ales av\u00e2nd \u00een vedere c\u0103 lucrez cu ele zilnic. Dar re\u021beaua era principalul suspect \u0219i trebuia s\u0103 \u00eenv\u0103\u021b cum s\u0103 o diagnostic.<\/p>\n

        Din fericire, internetul iube\u0219te pe cei care vor s\u0103 \u00eenve\u021be. O combina\u021bie de ping \u0219i tracert p\u0103rea a fi un \u00eenceput destul de bun pentru diagnosticarea problemelor de transport al re\u021belei.<\/p>\n

        \u00cen primul r\u00e2nd, am rulat PsPing<\/a><\/noindex> pe portul TCP al lui Elvin. Am folosit parametrii implici\u021bi - nimic special. Din peste o mie de pings, niciunul nu a dep\u0103\u0219it 10 ms, cu excep\u021bia primului pentru \u00eenc\u0103lzire. Aceasta contrazice cre\u0219terea observat\u0103 a laten\u021bei de 50 ms \u00een percentilul 99: acolo, la fiecare 100 de cereri ar fi trebuit s\u0103 vedem aproximativ o cerere cu laten\u021b\u0103 de 50 ms.<\/p>\n

        Apoi am \u00eencercat tracert<\/a><\/noindex>: poate, problema este la unul dintre nodurile pe traseul dintre Elvin \u0219i client. Dar \u0219i tracert-ul a revenit cu m\u00e2inile goale.<\/p>\n

        Astfel, cauza laten\u021bei nu a fost codul meu, nu implementarea gRPC \u0219i nu re\u021beaua. \u00cencepusem deja s\u0103 m\u0103 \u00eengrijorez c\u0103 nu voi \u00een\u021belege niciodat\u0103 asta.<\/p>\n

        Acum, pe ce sistem de operare ne afl\u0103m<\/h3>\n

        \ngRPC<\/code> este folosit pe scar\u0103 larg\u0103 \u00een Linux, dar pentru Windows este o excep\u021bie. Am decis s\u0103 fac un experiment, care a func\u021bionat: am creat o ma\u0219in\u0103 virtual\u0103 Linux, am compilat Alvin pentru Linux \u0219i l-am desf\u0103\u0219urat.<\/p>\n

        \"Uneori
        \n
        \n\u0218i iat\u0103 ce a ie\u0219it: serverul ping-pong pe Linux nu avea \u00eent\u00e2rzierea aceea ca nodul similar pe Windows, de\u0219i sursa de date nu s-a schimbat. Se pare c\u0103 problema este \u00een implementarea gRPC pentru Windows.<\/p>\n

        Algoritmul Nagle<\/h3>\n

        \nToat\u0103 aceast\u0103 vreme am crezut c\u0103 \u00eemi lipse\u0219te un flag gRPC<\/code>. Acum am realizat c\u0103 de fapt lipse\u0219te gRPC<\/code> flagul Windows. Am g\u0103sit o bibliotec\u0103 intern\u0103 RPC, despre care eram sigur c\u0103 func\u021bioneaz\u0103 bine pentru toate flagurile instalate Winsock<\/a><\/noindex>. Apoi am ad\u0103ugat toate aceste flaguri \u00een gRPC \u0219i am desf\u0103\u0219urat Alvin pe Windows, \u00een serverul ping-pong corectat pentru Windows!<\/p>\n

        \"Uneori
        \n
        \nAproape<\/i> gata: am \u00eenceput s\u0103 elimin flagurile ad\u0103ugate unul c\u00e2te unul, p\u00e2n\u0103 c\u00e2nd regresia s-a \u00eentors, astfel \u00eenc\u00e2t am putut determina exact cauza ei. Era tristul         A fost publicat un ghid detaliat pentru optimizarea mediului Linux pentru a ob\u021bine performan\u021be maxime \u00een procesarea cererilor HTTP.<\/a><\/noindex>, comutator al algoritmului Nagle.<\/p>\n

        Algoritmul Nagle<\/a><\/noindex> \u00eencearc\u0103 s\u0103 reduc\u0103 num\u0103rul de pachete trimise prin re\u021bea, \u00eent\u00e2rziind transmiterea mesajelor p\u00e2n\u0103 c\u00e2nd dimensiunea pachetului dep\u0103\u0219e\u0219te un anumit num\u0103r de byte. De\u0219i acest lucru poate fi pl\u0103cut pentru utilizatorul mediu, este devastator pentru serverele \u00een timp real, deoarece OS va \u00eent\u00e2rziat unele mesaje, provoc\u00e2nd \u00eent\u00e2rzieri la un QPS sc\u0103zut. Flagul acesta gRPC<\/code> a fost setat \u00een implementarea Linux pentru socket-uri TCP, dar nu pentru Windows. Am realizat c\u0103 am corectat<\/a><\/noindex>.<\/p>\n

        Concluzie<\/h1>\n

        \n\u00cent\u00e2rzierea mare la un QPS sc\u0103zut a fost cauzat\u0103 de optimizarea OS-ului. Privind \u00eenapoi, profilarea nu a detectat \u00eent\u00e2rzierea deoarece a fost efectuat\u0103 \u00een modul kernel, nu \u00een modul utilizator<\/a><\/noindex>. Nu \u0219tiu dac\u0103 algoritmul Nagle poate fi observat prin capturi ETW, dar ar fi interesant.<\/p>\n

        \u00cen ceea ce prive\u0219te experimentul localhost, acesta probabil nu a fost legat de codul de re\u021bea real, iar algoritmul Nagle nu a fost activat, a\u0219a c\u0103 problemele cu \u00eent\u00e2rzierile au disp\u0103rut c\u00e2nd clientul a accesat Alvin prin localhost.<\/p>\n

        Data viitoare c\u00e2nd observa\u021bi o cre\u0219tere a \u00eent\u00e2rzierii cu o sc\u0103dere a num\u0103rului de cereri pe secund\u0103, algoritmul Nagle ar trebui s\u0103 fie \u00een lista dumneavoastr\u0103 de suspec\u021bi!
        \n
        Sursa:         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\udd47Uneori mai mult \u00eenseamn\u0103 mai pu\u021bin. C\u00e2nd reducerea sarcinii duce la cre\u0219terea \u00eent\u00e2rzierii | ProHoster","description":"Asemenea majorit\u0103\u021bii post\u0103rilor, a ap\u0103rut o problem\u0103 cu serviciul distribuit, s\u0103 numim acest serviciu Alvin.","canonical_url":"https:\/\/prohoster.info\/ro\/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":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/33707","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=33707"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33707\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/25389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=33707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=33707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=33707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}