{"id":83188,"date":"2020-05-29T07:43:02","date_gmt":"2020-05-29T05:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali"},"modified":"2020-05-29T07:43:02","modified_gmt":"2020-05-29T05:43:02","slug":"kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Kuidas me elasime \u00fcle koormuse x10 suurenemise kaugt\u00f6\u00f6 ajal ja millised j\u00e4reldused tegime","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, Habr! Viimase paariku jooksul oleme olnud v\u00e4ga huvitavas olukorras ja soovin jagada meie infrastruktuuri skaleerimise lugu. Selle aja jooksul kasvas SberMarket tellimustes neljakordselt ja k\u00e4ivitas teenuse 17 uues linnas. Toiduainete kohaletoimetamise n\u00f5udluse plahvatuslik kasv n\u00f5udis meie infrastruktuuri skaleerimist. K\u00f5igi k\u00f5ige huvitavamate ja kasulikumate j\u00e4relduste lugemiseks vaata edasi.<\/p>\n

\"Kuidas
\n<\/a><\/noindex>
\nMina olen Dima Bobylev, SberMarketi tehniline direktor. Kuna see on meie blogi esimene postitus, siis \u00fctlen paar s\u00f5na enda ja ettev\u00f5tte kohta. Eelmisel s\u00fcgisel osalesin noorte liidrite konkursil Runetis. Selle konkursi jaoks kirjutasin v\u00e4ikese loo<\/a><\/noindex> kuidas me SberMarketis n\u00e4eme sisemist kultuuri ja l\u00e4henemist teenuse arendamisele. Kuigi konkursil v\u00f5itmiseks ei \u00f5nnestunud, suutsin siiski v\u00e4lja m\u00f5elda peamised p\u00f5him\u00f5tted IT-\u00f6kos\u00fcsteemi arendamiseks. <\/p>\n

Meeskonna juhtimisel on oluline m\u00f5ista ja leida tasakaal selle vahel, mis on vajalik \u00e4ri jaoks, ja iga konkreetse arendaja vajaduste vahel. Praegu kasvab SberMarket 13 korda aastas ja see m\u00f5jutab toodet, n\u00f5udes pidevat mahu ja arendustempo suurendamist. Vaatamata sellele eraldame arendajatele piisavalt aega eelanal\u00fc\u00fcsiks ja kvaliteetse koodi kirjutamiseks. Moodustatud l\u00e4henemine aitab mitte ainult t\u00f6\u00f6tava toote loomisel, vaid ka selle edasises skaleerimises ja arendamises. Selle kasvu tulemusena on SberMarket juba saanud toidukullerite teenuste liidriks: me toimetame iga p\u00e4ev umbes 18 tuhat tellimust, kuigi veel veebruari alguses oli neid umbes 3500.<\/p>\n

\"Kuidas
\n\u00dcks kord palus klient SberMarketi kulleril toimetada tooted talle kontaktivabalt \u2014 otse r\u00f5dule.<\/i><\/p>\n

Aga liigume konkreetsemate asjade juurde. Viimased paar kuud oleme aktiivselt tegelenud meie ettev\u00f5tte infrastruktuuri suurendamisega. Selle vajadus sai seletatud nii v\u00e4listest kui ka sisemistest teguritest. Samal ajal, kui kliendibaas laienes, kasvas \u00fchendatud kaupluste arv algusaasta 90-st kuni rohkem kui 200-ni mai keskpaigaks. Loomulikult olime ette valmistunud, reserveerides p\u00f5h infrastruktuuri, pluss lootes vertikaalse ja horisontaalse skaleerimise v\u00f5imalusele k\u00f5igis Yandexi pilves asuvates virtuaalmasinates. Kuid praktika n\u00e4itas: \"K\u00f5ik, mis v\u00f5ib valesti minna, l\u00e4heb ka valesti\". Ja t\u00e4na tahan jagada k\u00f5ige huvitavamaid olukordi, mis on nendel n\u00e4dalatel aset leidnud. Loodan, et meie kogemus osutub teile kasulikuks.<\/p>\n

Slave on t\u00e4ielikus s\u00f5jalises valmiduses<\/h3>\n

\nJuba enne pandeemia algust kohtasime t\u00f5usu meie backend serverite p\u00e4ringutes. Tooted koju tellimise trend hakkas kiiresti kasvama ning COVID-19 esimeste eneseisolatsiooni meetmete sisseviimisega kasvas koormus dramaatiliselt p\u00e4eva jooksul. Tekkis vajadus kiiresti vabastada master-serverid p\u00f5hiteabe andmebaasist ja suunata osa lugemisp\u00e4ringutest replikaserveritele (slave).<\/p>\n

Oli juba ette valmistatud sellele sammale, ja sellise man\u00f6\u00f6vri jaoks olid juba k\u00e4ivitatud 2 slave-serverit. Nendel t\u00f6\u00f6tasid peamiselt andmevahetuse infovood partneritega genereerimise batch-\u00fclesanded. Need protsessid genereerisid liigset koormust ja olid t\u00e4iesti \u00f5igustatult paar kuud varem \"k\u00f5rvadest v\u00e4lja viidud\".\u00a0<\/p>\n

Kuna Slave'is toimus replikatsioon, j\u00e4rgnesime p\u00f5him\u00f5ttele, et rakendused v\u00f5ivad nendega t\u00f6\u00f6tada ainult read only re\u017eiimis. H\u00e4daolukorra taastamise plaan eeldas, et t\u00f5sise probleemi korral saame lihtsalt monteerida Slave Masteri kohale ja suunata k\u00f5ik kirjutamis- ja lugemisp\u00e4ringud Slave'ile. Kuid soovisime kasutada replikaid ka anal\u00fc\u00fcsi osakonna vajadusteks, seet\u00f5ttu ei olnud serverid t\u00e4ielikult viidud read only staatusele ning igal hostil oli oma kasutajatute komplekt ja m\u00f5nedel olid kirjutamis\u00f5igused vahepealsete arvutuste tulemuste salvestamiseks.<\/p>\n

Teatud koormuse tasemeni piisavalt, et meistril oli piisavalt nii kirjutamiseks kui ka lugemiseks http-p\u00e4ringute t\u00f6\u00f6tlemisel. M\u00e4rtsi keskpaiku, just kui SberMarket otsustas t\u00e4ielikult \u00fcle minna kaugt\u00f6\u00f6le, algas meil RPS-i j\u00e4rsk kasv. \u00dcha rohkem meie kliente l\u00e4ks isolatsiooni v\u00f5i t\u00f6\u00f6tama kodust, mis kajastus koormuse n\u00e4itajates.<\/p>\n

Meistri tootlikkus l\u00f5petas piisavuse, seega hakkasime osa raskemaid lugemisep\u00e4ringuid viisama replikale. Kirjutamiseksp\u00e4ringute suunamiseks meistrisse ja lugemiseks orja, kasutasime ruby gem \"Octopus<\/a><\/noindex>\". Loomasime spetsiaalse kasutaja postfixiga _readonly, kellel ei olnud kirjutamis\u00f5igust. Kuid \u00fche hosti konfiguratsiooni vea t\u00f5ttu l\u00e4ks osa kirjutamisep\u00e4ringutest orjaserverile kasutaja nimel, kellel olid vastavad \u00f5igused.<\/p>\n

Probleem ei ilmunud kohe v\u00e4lja, kuna suurenenud koormus t\u00f5i endaga kaasa orjade viibimise. Andmete j\u00e4rjepidevuse probleem ilmnes hommikul, kui \u00f6iste importide j\u00e4rel ei olnud orjad meistrile j\u00e4rele j\u00f5udnud. Kandsime selle k\u00f5rge koormuse ja teenuse enda \u00fchitamise arvele, mis oli seotud uute kaupluste avamisega. Kuid andmete edastamine mitme tunni viivitusega ei olnud aktsepteeritav ning suunatud protsessid teisele anal\u00fc\u00fctilise orjale, kuna sellel olid bilotka<\/strong>suuremad ressursid ja see ei olnud lugemisep\u00e4ringutega koormatud (mida me ka ise seletamiseks kasutasime, et replikatsiooni lag'i puudumine).<\/p>\n

Kui olime v\u00e4lja uurinud peamise orja \"lagunemise\" p\u00f5hjused, oli anal\u00fc\u00fctiline juba sama p\u00f5hjuse t\u00f5ttu t\u00f6\u00f6lt v\u00e4ljas. Vaatamata kahe t\u00e4iendava serveri olemasolule, kuhu plaanisime koormuse viia meistri rikke korral, selgus, et kriitilisel hetkel ei olnud \u00fchtegi.<\/p>\n

Kuid kuna me tegime mitte ainult andmebaasi dump'i (taastamine tooks tollal umbes 5 tundi), vaid ka meistri serveri snapshot'i, \u00f5nnestus replika k\u00e4ivitada kahe tunni jooksul. T\u00f5si, p\u00e4rast seda ootas meid replikatsiooni logi pealekandmine pika aja jooksul (sest protsess toimub \u00fche l\u00f5ime re\u017eiimis, kuid see on juba hoopis teine lugu).<\/p>\n

Kokkuv\u00f5te:<\/strong> P\u00e4rast sellist intsidenti sai selgeks, et tuleb loobuda kasutajate kirjutamise piirangute rakendamisest ja kuulutada server t\u00e4ielikult ainult lugemiseks. Sellise l\u00e4henemisega v\u00f5ib olla kindel, et koopiad on kriitilisel hetkel kergesti k\u00e4ttesaadavad.<\/p><\/blockquote>\n

<\/p>\n

Isegi \u00fche raske p\u00e4ringu optimeerimine v\u00f5ib andmebaasi \"elule tagasi tuua\".<\/h3>\n

\nKuigi me uuendame kodulehe katalooge pidevalt, olid p\u00e4ringud, mida viisime \u00fcle Slave-serveritele, veidi j\u00e4rel Master-serverist. Aeg, mille jooksul avastasime ja k\u00f5rvaldasime \"\u00e4kitselt eemaldunud\" slave-serverite probleemi, oli pikem kui \"ps\u00fchholoogiline barj\u00e4\u00e4r\" (sel ajal v\u00f5isid hinnad muutuda ning kliendid n\u00e4eksid aegunud andmeid), ja me olime sunnitud suunama k\u00f5ik p\u00e4ringud peamise andmebaasi serveri peale. Tulemuseks t\u00f6\u00f6tas veebisait aeglaselt\u2026 kuid v\u00e4hemalt t\u00f6\u00f6tas. Ja seni, kuni Slave taastust\u00f6id tegime, polnud meil muud teha, kui optimeerida.\u00a0<\/p>\n

Kuni Slave-serverid taastusid, venisid minutid aeglaselt, Master oli \u00fclekoormatud ja suunasin oma j\u00f5ud aktiivsete \u00fclesannete optimeerimisele \"Pareto reegli\" kohaselt: valisime k\u00f5rgeima koormuse andvad TOP-p\u00e4ringud ja alustasime h\u00e4\u00e4lestamist. See toimus otse \"lennul\".<\/p>\n

Huvi pakkus see, et \u00fclevoolav MySQL reageerib isegi v\u00e4ikesele protsesside paranemisele. Paar p\u00e4ringu optimeerimist, mis andis vaid 5% kogukoormusest, n\u00e4itas juba selget CPU koormuse v\u00e4henemist. Tulemuseks suutsime tagada piisava ressursivarustuse Masteri andmebaasi t\u00f6\u00f6ks ja saada vajalik aeg koopiate taastamiseks.\u00a0<\/p>\n

Kokkuv\u00f5te:<\/strong> Isegi v\u00e4ike optimeerimine v\u00f5imaldab \"elluj\u00e4\u00e4mist\" \u00fclekoormuse korral mitme tunni v\u00e4ltel. Meil oli selleks just piisavalt aega serverite taastamiseks, kus olid koopiad. Muide, arutame p\u00e4ringute optimeerimise tehnilist k\u00fclge \u00fches j\u00e4rgmises postituses. Niisiis, tellige meie blogi, kui see v\u00f5ib teile kasulik olla.<\/p><\/blockquote>\n

<\/p>\n

Korraldage partnerite teenuste t\u00f6\u00f6monitoring.<\/h3>\n

\nK\u00e4sitleme klientide tellimusi ning meie teenused suhtlevad pidevalt kolmandate osapoolte API-dega \u2014 need on SMS-i saatmise v\u00e4ravad, makseplatvormid, marsruutimise s\u00fcsteemid, geokodeerija, FNS-i teenus ja paljusid teisi s\u00fcsteeme. Ja kui koormus hakkas kiiresti suurenema, hakkasime me j\u00f5udma meie partnerite teenuste API-de piiranguteni, millest me varem isegi mitte ei m\u00f5elnud.<\/p>\n

Ootamatu partnerite teenuste kvotide \u00fcletamine v\u00f5ib viia teie enda teenuse t\u00f6\u00f6katkestuseni. Paljud API-d blokeerivad kliente, kes \u00fcletavad limiite, ja m\u00f5nel juhul v\u00f5ib liigne p\u00e4ringute arv partneri tootmist \u00fcle koormata.\u00a0<\/p>\n

N\u00e4iteks, kui kohaletehtud pakke hakkas kiiresti suurenema, ei suutnud saatmise teenused \u00fclesandeid jaotada ning marsruute kindlaks m\u00e4\u00e4rata. Tulemuseks oli see, et tellimused olid esitatud, kuid marsruudi genereerimise teenus ei t\u00f6\u00f6tanud. Tuleb m\u00e4rkida, et meie logistika meeskond tegi sellistes oludes praktiliselt v\u00f5imatut ning meeskonna selge koost\u00f6\u00f6 aitas kompenseerida ajutisi teenuse katkemisi. Kuid sellist tellimuste hulka ei ole pidevalt v\u00f5imalik k\u00e4sitsi hallata ja m\u00f5ne aja p\u00e4rast oleksime silmitsi vastuv\u00f5etamatute viivitustega tellimuste ja nende t\u00e4itmise vahel.\u00a0<\/p>\n

V\u00f5eti vastu mitmeid organisatsioonilisi meetmeid ja \u00fchtne meeskonna t\u00f6\u00f6 aitas kokku hoida aega, kuni me lepime uute tingimuste \u00fcle ja ootame m\u00f5nede partnerite teenuste moderniseerimist. On ka teisi API-sid, mis pakuvad suurep\u00e4raseid vastupidavuse tasemeid ja palju soodsaid tariife suurte liiklustasemetega. N\u00e4iteks alguses kasutasime \u00fcht tuntud kaardistamise API-d, et m\u00e4\u00e4rata kohaletoimetamise aadress. Kuid kuu l\u00f5puks saime peaaegu 2 miljoni rubla suuruse arve. P\u00e4rast seda otsustasime selle kiiresti asendada. Ei hakka reklaamima, aga \u00fctleksin, et meie kulud v\u00e4henesid m\u00e4rkimisv\u00e4\u00e4rselt.
\n\"Kuidas<\/p>\n

Kokkuv\u00f5te: <\/strong>Oluline on j\u00e4lgida v\u00f5imaluste t\u00f6\u00f6tingimusi k\u00f5igi partnerite teenuste osas ja arvesse v\u00f5tta neid. Isegi kui t\u00e4na tundub, et need on teile 'suure varuga', ei t\u00e4henda see, et need ei takistaks teid kasvu hommikul. Ja loomulikult on parem eelnevalt kokku leppida teenusele suurenenud p\u00e4ringute finants tingimustes.\u00a0<\/p><\/blockquote>\n

<\/p>\n

M\u00f5nikord selgub, et \u201eon rohkem kulda<\/a><\/noindex>\u201d (c) ei aita<\/h3>\n

\nMe oleme harjunud \u201eummikutega\u201c peamises andmebaasis v\u00f5i rakenduste serverites, kuid skaleerimise korral v\u00f5ivad probleemid ilmneda seal, kus neid ei oodata. T\u00e4isteksti otsimiseks veebilehel kasutame Apache Solr mootorit. Koormuse kasvu t\u00f5ttu oleme m\u00e4rganud reageerimise aja v\u00e4henemist ning serveri protsessori koormus j\u00f5udis juba 100%ni. Mis v\u00f5iks olla lihtsam - anname Solr konteinerile rohkem ressursse.<\/p>\n

Oodatud j\u00f5udluse kasvu asemel t\u00f5mmati server lihtsalt \u201ekinnij\u00e4\u00e4misele\u201c. See laadis kohe 100% ja vastas veel aeglasemalt. Alguses oli meil 2 s\u00fcdamikku ja 2 GB RAM-i. Otsustasime teha seda, mis tavaliselt aitab - andsime serverile 8 s\u00fcdamikku ja 32 GB. K\u00f5ik muutus palju halvemaks (kuidas t\u00e4pselt ja miks - sellest r\u00e4\u00e4gime eraldi postituses).\u00a0<\/p>\n

M\u00f5ne p\u00e4eva jooksul saime selle k\u00fcsimuse n\u00fcanssidest aru ning saavutasime optimaalse j\u00f5udluse 8 s\u00fcdamiku ja 32 GB juures. See konfiguratsioon v\u00f5imaldab meil ka t\u00e4na koormust suurendada, mis on v\u00e4ga oluline, kuna kasv ei toimu mitte ainult klientide arvu, vaid ka \u00fchendatud poodide arvu osas - kahe kuu jooksul on nende arv kahekordistunud.\u00a0<\/p>\n

Kokkuv\u00f5te: <\/strong>Tavalised meetodid nagu \u201elihtsalt lisa rohkem rauda\u201c ei t\u00f6\u00f6ta alati. Niisiis tuleb igasuguste teenuste skaleerimise juures h\u00e4sti m\u00f5ista, kuidas need ressursse kasutavad ja eelnevalt testida nende t\u00f6\u00f6d uutes tingimustes.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless - v\u00f5ti lihtsaks horisontaalseks skaleerimiseks.<\/h3>\n

\n\u00dcldiselt j\u00e4rgib meie meeskond tuntud l\u00e4henemist: teenustel ei peaks olema sisemist seisundit (stateless) ja nad peaksid olema s\u00f5ltumatud t\u00f6\u00f6tamisest. See v\u00f5imaldas meil taluda koormuse kasvu lihtsa horisontaalse skaleerimise abil. Kuid meil oli \u00fcks teenus-erand - pikaajaliste taustategevuste t\u00f6\u00f6tleja. See tegeles e-kirjade ja SMS-ide saatmise, s\u00fcndmuste t\u00f6\u00f6tlemise, feedide genereerimise, hindade ja varude importimise ning piltide t\u00f6\u00f6tlemisega. Nii kujunes, et see s\u00f5ltus kohalikust failide salvestamisest ja oli ainus eksemplar.\u00a0<\/p>\n

Kui j\u00e4rjekorras olevate \u00fclesannete arv kasvas (ja see juhtus loomulikult koos tellimuste arvu kasvuga), muutus host, millel t\u00f6\u00f6tasid t\u00f6\u00f6tleja ja failide salvestamine, piiravaks teguriks. Tulemusena peatus tootevaliku ja hindade v\u00e4rskendamine, kasutajatele teavituste saatmine ja palju muid kriitilisi funktsioone, mis j\u00e4id j\u00e4rjekorda kinni. Ops meeskond migreeris kiiresti failide salvestamise S3-taolisse v\u00f5rgu salvestusse, mis v\u00f5imaldas meil t\u00f5sta mitu v\u00f5imsat masinat, et skaleerida taustat\u00f6\u00f6tlajat.<\/p>\n

Kokkuv\u00f5te: <\/strong>Reeglit Stateless tuleb j\u00e4rgida k\u00f5igi komponentide puhul, isegi kui tundub, et \"siin me kindlasti ei komista\". Paremini on kulutada natuke aega k\u00f5igi s\u00fcsteemide t\u00f6\u00f6 korraldamiseks, kui hiljem kiirustades koodi \u00fcmber kirjutada ja teenust, mis kogeb \u00fclem\u00e4\u00e4rast koormust, parandada.<\/p><\/blockquote>\n

<\/p>\n

7 p\u00f5him\u00f5tet intensiivseks kasvuks<\/h2>\n

\nHoolimata t\u00e4iendavate v\u00f5imsuste k\u00e4ttesaadavusest, puutusime kasvamise k\u00e4igus mitmete probleemide otsa. Selle aja jooksul on tellimuste arv kasvanud rohkem kui 4 korda. Praegu toimetame juba \u00fcle 17 000 tellimuse p\u00e4evas 62 linnas ja kavatseme geograafiat veelgi laiendada \u2013 2020. aasta esimeses pooles on oodata teenuse k\u00e4ivitamist kogu Venemaa ulatuses. Kuidas toime tulla kasvava koormusega, arvestades juba saadud \u00f5petusi, oleme v\u00e4lja t\u00f6\u00f6tanud 7 p\u00f5hise p\u00f5him\u00f5tte, kuidas pideva kasvu tingimustes t\u00f6\u00f6tada:<\/p>\n

    \n
  1. Incidendi juhtimine<\/strong>. Oleme loonud Jira-s tahvli, kus iga juhtum kajastub piletina. See aitab tegelikult prioriseerida ja t\u00e4ita juhtumiga seotud \u00fclesandeid. L\u00f5ppude l\u00f5puks ei ole viga teha viga - hirmutav on teha sama viga kaks korda. Juhtudel, kui juhtumid korduvad enne, kui suudame p\u00f5hjuse k\u00f5rvaldada, peab olema valmis tegevusjuhend, sest suure koormuse ajal on oluline reageerida kiiresti.<\/li>\n
  2. J\u00e4lgimine <\/strong>see all elements of infrastructure without exception. It is precisely thanks to this that we were able to predict the increase in load and correctly identify \"bottlenecks\" for prioritization of resolution. Most likely, under high load, everything you didn't think would fail or start to lag behind. Therefore, it is best to create new alerts immediately after the first incidents occur to monitor and anticipate them.<\/li>\n
  3. Correct alerts<\/strong> are simply essential with a sharp increase in load. Firstly, they must accurately report what exactly has broken. Secondly, there shouldn't be too many alerts, as an abundance of non-critical alerts leads to all notifications being ignored.<\/li>\n
  4. Applications must be stateless. <\/strong>We have confirmed that there should be no exceptions to this rule. Complete independence from the runtime environment is necessary. For this, you can store shared data in a database or, for example, directly in S3. Even better, follow the rules https:\/\/12factor.net<\/a><\/noindex>. During a sharp increase in time, optimizing code is simply not an option, and handling the load will have to be done by directly increasing computational resources and horizontal scaling.<\/li>\n
  5. Quotas and performance of external services. <\/strong>With rapid growth, problems can arise not only in your infrastructure but also in external services. The most frustrating thing is when this happens not due to a failure but because of reaching quotas or limits. Therefore, external services must scale as well as you do.\u00a0<\/li>\n
  6. Separate processes and queues. <\/strong>This greatly helps when there is a bottleneck on one of the gateways. We wouldn't have encountered delays in data transmission if the filled SMS sending queues hadn\u2019t interfered with the exchange of notifications between information systems. Moreover, increasing the number of workers would have been easier if they operated separately.<\/li>\n
  7. Financial realities.<\/strong> When there is an explosive growth in data streams, there\u2019s no time to think about tariffs and subscriptions. However, one must remember them, especially if you are a small company. A hefty bill can be issued by any API owner as well as your hosting provider. So, it is important to read agreements carefully.<\/li>\n<\/ol>\n

    <\/p>\n

    Kokkuv\u00f5te<\/h2>\n

    \nKaotiliste kaotustega, kuid me oleme selle etapi \u00fcle saanud ja t\u00e4na p\u00fc\u00fcame j\u00e4rgida k\u00f5iki leidunud p\u00f5him\u00f5tteid, samas kui iga masin omab v\u00f5imalust kergelt t\u00f5sta j\u00f5udlust kuni 4 korda, et toime tulla ootamatustega.\u00a0<\/p>\n

    J\u00e4rgmistes postitustes jagame oma kogemusi Apache Solr'i j\u00f5udluse v\u00e4henemise uurimisel ning r\u00e4\u00e4gime p\u00e4ringute optimeerimisest ja sellest, kuidas suhtlemine FNS-iga aitab ettev\u00f5ttel raha s\u00e4\u00e4sta. Tellige meie blogi, et mitte midagi vahele j\u00e4tta, ning r\u00e4\u00e4kige kommentaarides, kas olete sarnaseid ebameeldivusi kogenud liikluse kasvu ajal.<\/p>\n

    \"Kuidas<\/p>\n

    Ainult registreeritud kasutajad saavad k\u00fcsitluses osaleda. Logige sisse<\/a><\/noindex>, palun.<\/p>\n

    Kas olete kogenud teenuse aeglustumist\/vajadust suure koormuse korral, kuna:<\/h2>\n