{"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 kaugemate t\u00f6\u00f6de j\u00e4rsu koormuse kasvu x10 ja milliseid j\u00e4reldusi tegime.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, Habr! Viimased paar kuud oleme elanud v\u00e4ga huvitavas olukorras ja tahaksin jagada meie infrastruktuuri skaleerimise lugu. Selle aja jooksul on SberMarket tellimustes kasvanud neljakordseks ja k\u00e4ivitanud teenuse 17 uues linnas. Toidu kohaletoimetamise n\u00f5udluse plahvatuslik kasv n\u00f5udis meilt infrastruktuuri skaleerimist. K\u00f5ige huvitavamatest ja kasulikest j\u00e4reldustest loe allpool.<\/p>\n

\"Kuidas
\n<\/a><\/noindex>
\nMinu nimi on Dima Bobylev, olen SberMarketi tehniline direktor. Kuna see on meie blogi esimene postitus, \u00fctlen paar s\u00f5na enda ja ettev\u00f5tte kohta. Eelmisel s\u00fcgisel osalesin noorte liidrite konkursil Runetis. Konkursi raames kirjutasin v\u00e4ikese loo<\/a><\/noindex> sellest, kuidas me SberMarketis n\u00e4eme sisekultuuri ja l\u00e4henemist teenuse arendamisele. Ja kuigi konkursil v\u00f5ita ei \u00f5nnestunud, s\u00f5nastasin endale p\u00f5hialused IT-\u00f6kos\u00fcsteemi arendamiseks. <\/p>\n

Meeskonna juhtimisel on oluline m\u00f5ista ja leida tasakaal selle vahel, mida \u00e4ri vajab, ja iga konkreetse arendaja vajadustega. Praegu kasvab SberMarket aastaga 13 korda, mis m\u00f5jutab toodet, n\u00f5udes pidevat arendustempot ja mahtude suurendamist. Sellegipoolest anname arendajatele piisavalt aega eelanal\u00fc\u00fcsiks ja kvaliteetse koodi kirjutamiseks. Meie loodud l\u00e4henemine aitab mitte ainult t\u00f6\u00f6tava toote loomisel, vaid ka selle edasisel skaleerimisel ja arendamisel. Sellise kasvu tulemusena on SberMarket juba muutunud toidukullerite teenuste liidriks: toimetame igap\u00e4evaselt umbes 18 000 tellimust, samas kui veel aasta alguses oli neid umbes 3500.<\/p>\n

\"Kuidas
\nKord palus klient SberMarketi kulleril toidud toimetada kontaktivabalt \u2014 otse r\u00f5dule.<\/i><\/p>\n

Kuid liigume konkreetsete asjade juurde. Viimased paar kuud oleme aktiivselt tegelenud meie ettev\u00f5tte infrastruktuuri ulatuse suurendamisega. See vajadus tulenes nii v\u00e4listest kui ka sisemistest teguritest. Samal ajal kui kliendibaas laienes, kasvas \u00fchendatud kaupade arv 90-lt aasta alguses rohkem kui 200-ni mai keskel. Me olime muidugi ette valmistunud, broneerides p\u00f5histruktuuri ja arvutades v\u00e4lja v\u00f5imaluse virtuaalmasinate vertikaalseks ja horisontaalseks ulatuseks, mis asuvad Yandexi pilves. Kuid praktika on n\u00e4idanud: \"K\u00f5ik, mis v\u00f5ib valesti minna, l\u00e4hebki valesti\". Ja t\u00e4na tahan ma jagada k\u00f5ige huvitavamaid olukordi, mis nende n\u00e4dalate jooksul juhtusid. Loodan, et meie kogemus on teile kasulik.<\/p>\n

Slave on t\u00e4ielikult valmis tegevuseks<\/h3>\n

\nEelnevalt, enne pandeemia algust, seisisime silmitsi kasvava n\u00f5udlusega meie backend-serverite j\u00e4rele. Kodukullerteenuste tellimise trend hakkas kasvama, ja COVID-19 esimeste isoleerimismeetmete kehtestamisega kasvas koormus dramaatiliselt p\u00e4evast p\u00e4eva. Tekkinud vajadus oli kiiresti v\u00e4hendada p\u00f5hiraamatupidamise master-serverite koormust ja suunata osa lugemisest tehtud p\u00e4ringutest replica-serveritele.<\/p>\n

Oliime sellele sammule eelnevalt ette valmistunud ning selleks oli juba k\u00e4ivitatud 2 replica-serverit. Need serverid t\u00f6\u00f6tlesid peamiselt andmevahetuseks partneritega m\u00f5eldud infotoodete genereerimise batch-\u00fclesandeid. Need protsessid genereerisid liigset koormust ja olid t\u00e4iesti \u00f5igustatud, et v\u00f5eti paar kuud varem \u201ev\u00e4lja\u201d.\u00a0<\/p>\n

Kuna Slave'is toimus replikatsioon, j\u00e4rgime p\u00f5him\u00f5tet, et rakendused saavad nendega t\u00f6\u00f6tada ainult lugemisre\u017eiimis. H\u00e4daolukorra taastamisplaan n\u00e4gi ette, et katastroofi korral saame lihtsalt mountida Slave Master'i kohale ja suunata k\u00f5ik kirjutamis- ja lugemisettepanekud Slave'ile. Kuid soovisime ka replikate kasutamist anal\u00fc\u00fctika osakonna vajadusteks, seet\u00f5ttu ei olnud serverid t\u00e4ielikult muutunud lugemisre\u017eiimi, vaid igas hostis oli oma kasutajate kogum, kellest m\u00f5ned omasid kirjutamis\u00f5igusi vahepealsete arvutuste tulemuste salvestamiseks.<\/p>\n

Teatud koormustasandini piisab meistrist nii kirjutamiseks kui lugemiseks http-p\u00e4ringute t\u00f6\u00f6tlemisel. M\u00e4rtsi keskel, kui Sbermarketi otsus kaug- t\u00f6\u00f6le t\u00e4ielikult \u00fcle minna kehtestati, algas meie RPS-i kiire kasv. \u00dcha rohkem meie kliente l\u00e4ks isoleerimisele v\u00f5i t\u00f6\u00f6tas kodus, mis kajastus koormusn\u00e4itajates.<\/p>\n

\u00abMeister\u00bb j\u00f5udlus ei olnud enam piisav, seet\u00f5ttu hakkasime osa k\u00f5ige raskematest lugemisest p\u00e4ringutest replika peale suunama. Kirjutamis p\u00e4ringute suunamiseks meistrisse ja lugemiseks slave'ile kasutasime ruby gem'i \u00abOctopus<\/a><\/noindex>\u00bb. Loodud eraldi kasutaja koos _readonly postfixiga, kellel ei olnud kirjutamis\u00f5igusi. Kuid \u00fche hosti konfiguratsiooni vea t\u00f5ttu l\u00e4ks osa kirjutamis p\u00e4ringutest slave-serverisse kasutajana, kellel olid vastavad \u00f5igused.<\/p>\n

Probleem ei ilmnenud kohe, kuna suurenenud koormus t\u00f5i kaasa slave'ide mahaj\u00e4\u00e4must. Andmete ebak\u00f5la avastati hommikul, kui p\u00e4rast \u00f6iseid impordeid ei olnud slave'id meisteriga \u00abj\u00e4rgmised\u00bb. Kirjutasime selle k\u00f5rgele koormusele teenusele endale ja impordile, mis oli seotud uute poodide avamisega. Kuid andmete edastamine mitme tunni viivitususega ei olnud vastuv\u00f5etav ning suunasime protsessid teisele anal\u00fc\u00fctilisele slave'ile, kuna tal olid bo<\/strong>suuremad ressursid ja ta ei olnud lugemis p\u00e4ringutest koormatud (mida me endale replikatsiooni mahaj\u00e4\u00e4must seletades kinnitasime).<\/p>\n

Kui saime selgeks p\u00f5hjus, miks p\u00f5hja slave oli kokku kukkunud, oli anal\u00fc\u00fcs juba sama p\u00f5hjusel t\u00f6\u00f6 l\u00f5petanud. Kuigi meil oli kaks t\u00e4iendavat serverit, kuhu plaanisime koormuse \u00fcle viia, kui meester server peaks eba\u00f5nnestuma, selgus h\u00e4iriva vea t\u00f5ttu, et kriitilise hetke jooksul ei olnud \u00fchtegi serverit saadaval.<\/p>\n

Kuna tegime mitte ainult andmebaasi dump'i (tagasiveo aeg oli sel hetkel umbes 5 tundi), vaid ka master-serveri snapshot'i, \u00f5nnestus replikat k\u00e4ivitada kahe tunni jooksul. P\u00e4rast seda ootas meid siiski replikatsiooni logi pealekandmine pikka aega (sest protsess toimub \u00fchesuunaliselt, kuid see on juba hoopis teine lugu).<\/p>\n

V\u00e4ljund:<\/strong> P\u00e4rast sellist intsidenti oli selge, et peame loobuma kasutajate kirjutamise piiramisest ja kuulutama kogu serveri lugemiseks. Sellise l\u00e4henemisega ei ole kahtlust, et repliikide k\u00e4ttesaadavus kriitiliselt olulistel hetkedel on tagatud.<\/p><\/blockquote>\n

<\/p>\n

Isegi \u00fche raske p\u00e4ringu optimeerimine v\u00f5ib andmebaasi \"ellu \u00e4ratada\".<\/h3>\n

\nKuigi uuendame veebilehe katalooge pidevalt, esitati Slave-serveritele tehtud p\u00e4ringud Master-serverist v\u00e4ikese viivitusega. Aeg, mille jooksul avastasime ja lahendasime probleemi, et \"\u00fcksused kaotasid \u00e4kitselt \u00fchenduse\", \u00fcletas \"ps\u00fchholoogilise piiri\" (selle aja jooksul v\u00f5isid hinnad muutuda ja kliendid oleksid n\u00e4inud aegunud andmeid), mist\u00f5ttu pidime suunama k\u00f5ik p\u00e4ringud peamiselt andmebaasiserverile. Tulemuseks oli, et veebileht t\u00f6\u00f6tas aeglaselt\u2026 aga v\u00e4hemalt t\u00f6\u00f6tas. Ja seni, kuni Slave taastus, ei j\u00e4\u00e4nud meil muud kui optimeerida.\u00a0<\/p>\n

Kuni Slave-serverid taastusid, venisid minutid aeglaselt, Master oli \u00fclekoormatud ja panime k\u00f5ik j\u00f5ud aktiivsete \u00fclesannete optimeerimisele vastavalt \u201ePareto printsiibile\u201d: valisime TOP-p\u00e4ringud, mis andsid suure osa koormusest, ja alustasime h\u00e4\u00e4lestamist. Seda tehti otse \u201eliikvel olles\u201d.<\/p>\n

Huvitav n\u00e4htus oli see, et \u00fclekoormatud MySQL reageerib isegi tavaliste protsesside v\u00e4ikeste parenduste peale. Paar p\u00e4ringu optimeerimist, mis andsid vaid 5% kogu koormusest, n\u00e4itas juba olulist CPU laadimise v\u00e4hendamist. Selle tulemusena suutsime tagada Masteri t\u00f6\u00f6ks andmebaasis piisava ressursi varu ja saada vajalik taastumisaeg replika jaoks.\u00a0<\/p>\n

V\u00e4ljund:<\/strong> Isegi v\u00e4ike optimeerimine v\u00f5imaldab \u201eellu j\u00e4\u00e4da\u201d koormuse all mitu tundi. Just seda meil oli piisavalt serverite replika taastumise ajaks. Muide, p\u00e4ringute optimeerimise tehnilist k\u00fclge arutame \u00fches j\u00e4rgmistest postitustest. Nii et j\u00e4lgige meie blogi, kui see teile kasulikuks osutub.<\/p><\/blockquote>\n

<\/p>\n

Korrastage partnerite teenuste t\u00f6\u00f6v\u00f5ime j\u00e4lgimine<\/h3>\n

\nKliendi tellimuste t\u00f6\u00f6tlemisega tegelemise t\u00f5ttu suhtlevad meie teenused pidevalt kolmandate osapoolte API-dega \u2014 need on SMS-i saatmise v\u00e4ravad, makseplatvormid, marsruutimiss\u00fcsteemid, geokooder, FNS teenus ja paljud teised s\u00fcsteemid. Ja kui koormus hakkas kiiresti kasvama, sattusime partnerite teenuste API-de piirangutesse, mille \u00fcle me varem isegi ei m\u00f5elnud.<\/p>\n

Partnerite teenuste kvootide ootamatu \u00fcletamine v\u00f5ib p\u00f5hjustada teie enda s\u00fcsteemi seisakuid. Paljud API-d blokeerivad kliente, kes \u00fcletavad limiite, ja m\u00f5nel juhul v\u00f5ib liigne p\u00e4ringute arv partneri tootmisprotsessi \u00fcle koormata.\u00a0<\/p>\n

N\u00e4iteks, kui kohaletoimetamiste arv kasvas, ei suutnud saateteenused neid \u00fclesandeid, nagu jaotamine ja marsruutide m\u00e4\u00e4ramine, t\u00e4ita. Tulemusena oli nii, et tellimused olid tehtud, kuid marsruudi loomise teenus ei t\u00f6\u00f6tanud. Tuleb \u00f6elda, et meie logistika spetsialistid tegid sellistes tingimustes peaaegu impossibli; meeskonna t\u00e4pne koost\u00f6\u00f6 aitas ajutisi teenuste katkestusi tasakaalustada. Kuid sellist tellimuste mahtu ei ole konstantsete k\u00e4sitsi t\u00f6\u00f6tlemisega v\u00f5imalik pidevalt hallata, ja varsti oleksime silmitsi vastuv\u00f5etamatu l\u00f5hega tellimuste ja nende t\u00e4itmise vahel.\u00a0<\/p>\n

Tegime mitmeid organisatsioonilisi samme ja meeskonna sujuv koost\u00f6\u00f6 aitas meil aega v\u00f5ita, kuni leppisime kokku uutel tingimustel ja ootasime m\u00f5nedelt partneritelt teenuste uuendamist. On ka teisi API-sid, mis paistavad silma k\u00f5rge vastupidavuse ja talumatute hindadega k\u00f5rge liikluse korral. N\u00e4iteks kasutasime alguses \u00fchte tuntud kaardistamis-API-d, et m\u00e4\u00e4rata kohaletoimetamise punkti aadress. Kuid kuu l\u00f5puks saime \u00fcsna soliidse arve peaaegu 2 miljoni rubla ulatuses. P\u00e4rast seda otsustasime selle kiiresti v\u00e4lja vahetada. Ma ei hakka reklaamima, aga v\u00f5in \u00f6elda, et meie kulud on m\u00e4rgatavalt v\u00e4henenud.
\n\"Kuidas<\/p>\n

V\u00e4ljund: <\/strong>On v\u00e4ga oluline j\u00e4lgida k\u00f5igi partnerite teenuste t\u00f6\u00f6tingimusi ja neid meeles pidada. Isegi kui t\u00e4na tundub, et need on teile \u201esuure varuga\u201d, ei t\u00e4henda see, et nad ei saa homme kasvu takistuseks. Ja muidugi on parem eelnevalt kokku leppida teenuse suurenenud n\u00f5udmiste rahalistes tingimustes.\u00a0<\/p><\/blockquote>\n

<\/p>\n

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

\nOleme harjunud \u201eummikute\u201c esinemisega peamises andmebaasis v\u00f5i rakendusserverites, kuid skaleerimise ajal v\u00f5ivad probleemid ilmuda seal, kus neid ei oodata. T\u00e4isteksti otsingu jaoks kasutame Apache Solr mootorit. Koormuse suurenedes oleme m\u00e4rganud vastuseaja v\u00e4henemist, samas kui serveri protsessori koormus j\u00f5udis 100%-ni. Mis v\u00f5iks olla lihtsam \u2014 anname Solr konteinerile rohkem ressursse.<\/p>\n

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

M\u00f5ne p\u00e4eva jooksul saime aru selle k\u00fcsimuse keerukusest ning saavutasime optimaalse tootlikkuse 8 tuuma ja 32 GB korral. See konfiguratsioon v\u00f5imaldab ka t\u00e4na koormust j\u00e4tkuvalt suurendada, mis on v\u00e4ga oluline, sest kasv toimub mitte ainult klientide, vaid ka \u00fchendatud poodide arvu osas \u2014 kahe kuuga suurenenud arv on kaks korda.\u00a0<\/p>\n

V\u00e4ljund: <\/strong>Tavalised meetodid nagu \"veel riistvara lisamine\" ei t\u00f6\u00f6ta alati. Seega, teenuse skaleerimisel on oluline aru saada, kui h\u00e4sti see ressursse kasutab ja testida seda ettevalmistavas faasis uutes tingimustes.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 lihtsa horisontaalse skaleerimise v\u00f5ti<\/h3>\n

\n\u00dcldiselt j\u00e4rgib meie meeskond tuntud l\u00e4henemist: teenused ei peaks omama sisemist olekut (stateless) ja peaksid olema s\u00f5ltumatud k\u00e4ituskeskkonnast. See on v\u00f5imaldanud meil taluda koormuse kasvu lihtsa horisontaalse skaleerimise abil. Kuid meil oli \u00fcks erand \u2014 pikaajaliste taustateenuste t\u00f6\u00f6tleja. See tegeles e-kirjade ja SMS-ide saatmise, s\u00fcndmuste t\u00f6\u00f6tlemise, voogude genereerimise, hindade ja varude importimise, piltide t\u00f6\u00f6tlemisega. Tekkis olukord, kus see s\u00f5ltus kohalikust failide salvestamisest ja oli ainus eksemplar.\u00a0<\/p>\n

Kuna \u00fclesannete arv j\u00e4rjekorras t\u00f6\u00f6tlejat (mis loomulikult juhtus koos tellimuste arvu kasvuga) kasvas, muutus host, millel t\u00f6\u00f6tleja ja failide salvestamine asusid, piiravaks teguriks. Selle tulemusena peatus valikute ja hindade uuendamine, kasutajatele teavituste saatmine ja palju muid kriitilisi funktsioone, mis j\u00e4id j\u00e4rjekorda kinni. Ops meeskond viis kiiresti failide salvestamise S3-sarnasesse v\u00f5rgu salvestusse ja see v\u00f5imaldas meil t\u00f5sta mitmeid v\u00f5imsaid masinaid, et laiendada taustat\u00f6\u00f6tluse s\u00fcsteemi.<\/p>\n

V\u00e4ljund: <\/strong>Stateless reeglit tuleb j\u00e4rgida k\u00f5igi komponentide puhul ilma eranditeta, isegi kui tundub, et siin me kindlasti ei j\u00e4\u00e4 kinni. Olulisem on kulutada veidi aega s\u00fcsteemide t\u00f6\u00f6 \u00f5igele korraldamisele, kui hiljem kiiruselt koodi \u00fcmber kirjutada ja parandada teenust, mis kogeb \u00fclekoormust.<\/p><\/blockquote>\n

<\/p>\n

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

\nHoolimata t\u00e4iendavate ressursside olemasolust oleme kasvu k\u00e4igus kokkup\u00f5rganud mitmete probleemidega. Selle aja jooksul on tellimuste arv kasvanud rohkem kui neli korda. Praegu toimetame juba rohkem kui 17 000 tellimust p\u00e4evas 62 linnas ning plaanime oma tegevust veelgi laiendada \u2014 2020. aasta esimeses pooles on plaanis teenuse k\u00e4ivitamine kogu Venemaal. Selleks, et hakkama saada kasvava koormusega, arvestades juba saadud kogemusi, oleme v\u00e4lja t\u00f6\u00f6tanud 7 p\u00f5hieesm\u00e4rki pideva kasvu tingimustes:<\/p>\n

    \n
  1. Juhtimine<\/strong>. Oleme loonud Jira-sse tahvli, kus iga juhtum peegeldub pileti n\u00e4ol. See aitab t\u00f5eliselt prioriseerida ja tegeleda juhtu puudutavate \u00fclesannetega. Sest sisuliselt ei ole hirmus eksida \u2014 hirmus on eksida kaks korda sama asja p\u00e4rast. Nende juhtumite puhul, kus probleemid korduvad kiiremini, kui suudame p\u00f5hjusest vabaneda, peaks olema valmis tegevusjuhend, sest suurte koormuste ajal on oluline reageerida viivitamatult.<\/li>\n
  2. J\u00e4lgimine <\/strong>see all sides of the infrastructure. Thanks to this, we were able to forecast the growth of load and correctly identify the bottlenecks to prioritize their resolution. Most likely, under heavy load, everything you didn't expect will break or start lagging. Therefore, it's best to create new alerts right after the first incidents occur, to monitor and anticipate them.<\/li>\n
  3. Correct alerts<\/strong> are essential during a sudden increase in load. Firstly, they must report exactly what has broken. Secondly, there shouldn't be too many alerts, as an abundance of non-critical alerts leads to the ignoring of all notifications altogether.<\/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 is to follow the rules. https:\/\/12factor.net<\/a><\/noindex>. \u00c4kilise kasvu korral pole aega koodi optimeerida ja koormuse eest tuleb hoolitseda lihtsalt arvutusressursside otsese suurendamise ja horisontaalse skaleerimise abil.<\/li>\n
  5. V\u00e4liste teenuste kvotid ja j\u00f5udlus. <\/strong>Kiire kasvu korral v\u00f5ib probleem tekkida mitte ainult teie infrastruktuuris, vaid ka v\u00e4lises teenuses. K\u00f5ige masendavam on see, kui see juhtub mitte rikke t\u00f5ttu, vaid kvotide v\u00f5i piiride saavutamise t\u00f5ttu. Seega peavad ka v\u00e4lised teenused skaleeruma sama h\u00e4sti nagu teie ise.\u00a0<\/li>\n
  6. Jagage protsesse ja j\u00e4rjekordi. <\/strong>See aitab v\u00e4ga palju, kui \u00fches v\u00e4ravas tekib ummik. Me ei oleks andmeedastuses viivitustega silmitsi, kui SMS-ide saatmise t\u00e4isj\u00e4rjekorrad ei segaks teavituste vahetust infos\u00fcsteemide vahel. Jah, ja t\u00f6\u00f6tajate arvu oleks lihtsam suurendada, kui nad t\u00f6\u00f6taksid eraldi.<\/li>\n
  7. Finantsreaalsused.<\/strong> Kui andmete voogude plahvatuslik kasv toimub, pole aega hinnaplaanide ja tellimuste \u00fcle j\u00e4rele m\u00f5elda. Kuid neid tuleb meeles pidada, eriti kui olete v\u00e4ike ettev\u00f5te. Suure arve v\u00f5ib esitada iga API omanik, samuti teie hostimise teenusepakkuja. Seega tuleb lepingud hoolikalt l\u00e4bi lugeda.<\/li>\n<\/ol>\n

    <\/p>\n

    Kokkuv\u00f5te<\/h2>\n

    \nKuigi kaotusi oli, oleme sellest etapis \u00fcle saanud ja t\u00e4na p\u00fc\u00fcame j\u00e4rgiselt k\u00f5iki leitud p\u00f5him\u00f5tteid, kusjuures iga masin on suuteline lihtsaks j\u00f5udluse neljakordseks suurendamiseks, et toime tulla ootamatustega.\u00a0<\/p>\n

    J\u00e4rgnevates postitustes jagame oma kogemusi Apache Solri j\u00f5udluse languse uurimisel, r\u00e4\u00e4gime p\u00e4ringute optimeerimisest ning sellest, kuidas suhe FNS-iga aitab ettev\u00f5ttel raha s\u00e4\u00e4sta. Liituge meie blogiga, et mitte midagi vahele j\u00e4tta, ja kirjutage kommentaaridesse, kas teil on olnud sarnaseid probleeme liikluse kasvamisel.<\/p>\n

    \"Kuidas<\/p>\n

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

    Kas teil on olnud teenuse aeglustumist v\u00f5i langemist j\u00e4rsu koormuse suurenemise t\u00f5ttu:<\/h2>\n