Përshëndetje, Habr! Gjatë disa muajve të fundit, kemi përjetuar një situatë shumë interesante, dhe do të doja të ndaja historinë tonë të zgjerimit të infrastrukturës. Gjatë kësaj kohe, SberMarket është rritur katërfish në porosi dhe ka lansuar shërbimin në 17 qytete të reja. Rritja eksplozive e kërkesës për dorëzim të produkteve kërkoi nga ne zgjerimin e infrastrukturës. Rreth konkluzioneve më interesante dhe të dobishme lexoni poshtë.
Më quajnë Dima Bobylëv, unë jam drejtor teknik i SberMarket. Duke qenë se ky është posti i parë në blogun tonë, do të them disa fjalë për veten dhe për kompaninë. Në vjeshtën e kaluar, kam marrë pjesë në konkursin e liderëve të rinj të Runet. Për këtë contest unë rreth mënyrës se si ne në SberMarket e shohim kulturën e brendshme dhe qasjen ndaj zhvillimit të shërbimit. Edhe pse nuk arrita të fitoj në konkurs, përkundrazi, kam formuluar për vete parimet themelore të zhvillimit të ekosistemit IT.
Kur menaxhon një ekip, është e rëndësishme të kuptosh dhe të gjesh një balancë mes nevojave të biznesit dhe kërkesave të çdo zhvilluesi të veçantë. Aktualisht, SberMarket po rritet 13 herë nga viti në vit, dhe kjo ndikon në produkt, duke kërkuar rritjen e vazhdueshme të volumit dhe ritmit të zhvillimit. Megjithatë, ne i japim zhvilluesve mjaft kohë për analizën paraprake dhe për një kod të cilësisë së lartë. Qasja e formuar ndihmon jo vetëm në krijimin e një produkti funksional, por gjithashtu në zgjerimin dhe zhvillimin e tij të mëtejshëm. Si rezultat i kësaj rritjeje, SberMarket tashmë është bërë lider ndër shërbimet e dorëzimit të produkteve: ne dorëzojmë rreth 18 mijë porosi çdo ditë, ndonëse në fillim të shkurtit ishin rreth 3500.
NjĂ« herĂ«, njĂ« klient kĂ«rkoi qĂ« kurieri i SberMarket tĂ« dorĂ«zonte produktet atij nĂ« mĂ«nyrĂ« pa kontakt â direkt nĂ« ballkon.
Por tĂ« kaluar te detajet. GjatĂ« disa muajve tĂ« fundit, ne kemi punuar aktivisht nĂ« zgjerimin e infrastrukturĂ«s sĂ« kompanisĂ« sonĂ«. Ky nevojĂ« u justifikua nga faktorĂ« tĂ« jashtĂ«m dhe tĂ« brendshĂ«m. NĂ« tĂ« njĂ«jtĂ«n kohĂ« me rritjen e bazĂ«s sĂ« klientĂ«ve, numri i dyqaneve tĂ« lidhura u rrit nga 90 nĂ« fillim tĂ« vitit nĂ« mĂ« shumĂ« se 200 deri nĂ« mes tĂ« majit. Sigurisht, ne u pĂ«rgatitĂ«m, rezervuam infrastrukturĂ«n kryesore dhe planifikuam mundĂ«sinĂ« e zgjerimit vertikal dhe horizontal tĂ« tĂ« gjitha makinave virtuale tĂ« vendosura nĂ« ĐŸĐ±Đ»Đ°kun e Yandex. MegjithatĂ«, praktika tregoi: "Gjithçka qĂ« mund tĂ« shkojĂ« keq, do tĂ« shkojĂ« keq". Dhe sot dua tĂ« ndaj situatat mĂ« interesante qĂ« ndodhen pĂ«r kĂ«to javĂ«. Shpresoj qĂ« pĂ«rvoja jonĂ« tĂ« jetĂ« e dobishme pĂ«r ju.
Slave është në gatishmëri të plotë
Edhe përpara fillimit të pandemisë, u përballëm me një rritje të numrit të kërkesave në serverat tanë backend. Tendenca për të porositur produkte me dorëzim në shtëpi filloi të merrte hov, dhe me futjen e masave të para të vetizolimit për shkak të COVID-19, ngarkesa po rritej dramatikisht para syve tanë gjatë gjithë ditës. U shfaq nevoja për të shkarkuar me urgjencë serverat master të bazës kryesore të të dhënave dhe për të transferuar disa kërkesa për lexim në serverat-replikë (slave).
Ne u pĂ«rgatitĂ«m paraprakisht pĂ«r kĂ«tĂ« hap, dhe pĂ«r kĂ«tĂ« manovĂ«r tashmĂ« ishin aktivizuar 2 servera slave. Ata kryesisht punonin me detyra batch pĂ«r gjenerimin e feed-eve informative pĂ«r shkĂ«mbimin e tĂ« dhĂ«nave me partnerĂ«t. KĂ«to procese krijonin njĂ« ngarkesĂ« tĂ« tepĂ«rt dhe ishin krejtĂ«sisht tĂ« arsyeshme tĂ« hiqeshin "jashtĂ« skanave" disa muaj mĂ« parĂ«.Â
Duke qenë se replikimi ndodhte në Slave, ne ndoqëm konceptin që aplikacionet mund të punojnë me to vetëm në mënyrë read only. Plani i Rimëkëmbjes nga Fatkeqësitë parashikonte që në rast katastrofe, ne mund të montonim thjesht Slave në vend të Master dhe të kalonim të gjitha kërkesat për shkrim dhe lexim në Slave. Megjithatë, ne gjithashtu dëshironim të përdornim replikat për nevojat e departamentit të analizave, kështu që serverat nuk u transferuan plotësisht në statusin read only, dhe në çdo host kishte grupin e tij të përdoruesve, dhe disa kishin të drejta shkrimi për të ruajtur rezultatet ndërmjetëse të llogaritjeve.
Der nivel të caktuar ngarkese na mjaftonte një master për të shkruar dhe lexuar gjatë përpunimit të kërkesave http. Në mesin e marsit, pikërisht kur Sbermarket vendosi të kalojë në punë të largët, filluam një rritje të ndjeshme të RPS. Po aq shumë klientë tanë kaluan në vetëizolim ose punë nga shtëpia, gjë që ndikoi në treguesit e ngarkesës.
Performanca e «master» nuk ishte më e mjaftueshme, prandaj filluam të transferonim disa nga kërkesat më të rënda për lexim në replikë. Për të drejtuar transparencën e kërkesave për shkruar në master dhe për lexim në slave, përdorëm gemin ruby «». Krijuam një përdorues të veçantë me postfixin _readonly pa të drejta për shkruar. Por për shkak të një gabimi në konfigurimin e njërit nga hostet, disa kërkesa për shkruar u dërguan në serverin slave me emrin e përdoruesit që kishte të drejtat përkatëse.
Problemi nuk doli në pah menjëherë, sepse ngarkesa e rritur shkaktoi një vonesë tek slavet. Inkonistencat e të dhënave u zbuluan në mëngjes, kur pas importeve të natës, slavet nuk e «arritën» masterin. Ne e arsyetuam këtë me ngarkesën e lartë në vetë shërbimin dhe importin e lidhur me hapjen e dyqaneve të reja. Por ofrimi i të dhënave me një vonesë disa orëshe ishte e papranueshme, dhe ne kaluam proceset në slave-në e dytë analitike, sepse ai kishte mëoshumë burime dhe nuk ishte ngarkuar me kërkesa leximi (çfarë e shpjeguam për veten tonë si mungesë të vonesës në replikim).
Kur arritëm të zgjidhnim arsyet e «shkëputjes» së slave-it kryesor, slave analitik tashmë kishte dalë jashtë funksioni për të njëjtën arsye. Pavarësisht nga pranimi i dy serverëve shtesë, në të cilët planifikuam të transferonim ngarkesën në rast të dështimit të masterit, për shkak të një gabimi të padëshiruar rezultoi se në momentet kritike nuk kishte asnjë.
Por pasi bëmë jo vetëm dump të DB (restorimi në atë moment zgjaste rreth 5 orë), por gjithashtu snapshot të serverit master, arritëm të nisim replikën brenda 2 orëve. Megjithatë, pas kësaj na priste kalimi i logut të replikimit për një periudhë të gjatë (pasi processi zhvillohet në modin njëthëmbësh, por kjo është një histori tjetër krejtësisht).
Përfundimi: Pas një incident të tillë, u bë e qartë se duhej hequr dorë nga praktika e kufizimit të regjistrimit për përdoruesit dhe të shpallej në mënyrë readonly e gjithë serveri. Me një qasje të tillë, mund të mos dyshohet se replikat do të ishin të disponueshme në një moment kritik.
Optimizimi edhe i një kërkese të rëndë mund të "kthejë në jetë" DB-në.
MegjithĂ«se ne vazhdimisht pĂ«rditĂ«sojmĂ« katalogun nĂ« sit, kĂ«rkesat qĂ« ne i dĂ«rgonim nĂ« serverĂ«t Slave toleronin njĂ« vonesĂ« tĂ« vogĂ«l nga Master. Koha pĂ«r tĂ« zbuluar dhe eliminuar problemin e "slave-ve qĂ« papritmas dolĂ«n nga gara" ishte mĂ« e gjatĂ« se "bariera psiko-kologjike" (nĂ« atĂ« kohĂ« mund tĂ« kishte ndodhur njĂ« pĂ«rditĂ«sim çmimesh dhe klientĂ«t do tĂ« shihnin tĂ« dhĂ«na tĂ« skaduara), dhe ne u detyruam tĂ« kalonim tĂ« gjitha kĂ«rkesat nĂ« serverin kryesor tĂ« DB-sĂ«. Si rezultat, siti punoi ngadalĂ«... por sĂ« paku funksionoi. Dhe derisa Slave po rikuperohej, nuk na mbetej asgjĂ« tjetĂ«r pĂ«rveç optimizimit.Â
Ndërsa serverët Slave po rikuperoheshin, minutat kalonin ngadalë, Master mbetej i ngarkuar, dhe ne hodhëm të gjitha forcat në optimizimin e detyrave aktive sipas "Rregullit të Paretos": zgjodhëm kërkesat TOP që jepnin pjesën më të madhe të ngarkesës dhe filluam tuning. Kjo bëhej në mënyrë të drejtpërdrejtë.
NjĂ« efekt interesant ishte se MySQL, e mbushur deri nĂ« pikĂ«n kryesore, pĂ«rgjigjej edhe ndaj pĂ«rmirĂ«simit tĂ« vogĂ«l tĂ« proceseve. Optimizimi i disa kĂ«rkesave qĂ« jepnin vetĂ«m 5% tĂ« ngarkesĂ«s totale tregoi tashmĂ« njĂ« ulje tĂ« dukshme tĂ« CPU-sĂ«. Si rezultat, arritĂ«m tĂ« siguronim njĂ« rezervĂ« tĂ« pranueshme burimesh pĂ«r tĂ« punuar Master me bazĂ«n e tĂ« dhĂ«nave dhe tĂ« merrnim kohĂ«n e nevojshme pĂ«r rikuperimin e replikave.Â
Përfundimi: Edhe një optimizim i vogël lejon "të mbijetosh" gjatë ngarkesës për disa orë. Na mjaftoi kjo kohë për rikuperimin e serverëve me replikat. Për rrethanat teknike të optimizimit të kërkesave, do ta diskutojmë në një nga postimet e ardhshme. Prandaj, abonohuni në blogun tonë nëse kjo mund të jetë e dobishme për ju.
Organizoni monitorimin e funksionimit të shërbimeve partnere.
Ne merremi me pĂ«rpunimin e porosive nga klientĂ«t, dhe pĂ«r kĂ«tĂ« arsye shĂ«rbimet tona vazhdimisht ndĂ«rveprojnĂ« me API e jashtme â kĂ«to janĂ« porta pĂ«r dĂ«rgimin e SMS-ve, platformat e pagesave, sistemet e routing-ut, geokoduesi, shĂ«rbimi i FNSH-sĂ« dhe shumĂ« sisteme tĂ« tjera. Dhe kur ngarkesa filloi tĂ« rritej shpejt, filluam tĂ« hasim kufizimet e API-ve tĂ« shĂ«rbimeve partnere, pĂ«r tĂ« cilat nuk kishim menduar mĂ« parĂ«.
NjĂ« tejkalim i papritur i kuotave tĂ« shĂ«rbimeve partnere mund tĂ« çojĂ« nĂ« ndjekjen e rĂ«nies sĂ« shĂ«rbimeve tuaja. ShumĂ« API bllokojnĂ« klientĂ«t qĂ« tejkalojnĂ« kufijtĂ«, dhe nĂ« disa raste, njĂ« numĂ«r i madh kĂ«rkesash mund tĂ« ngarkojĂ« prodhimin e partnerit.Â
PĂ«r shembull, nĂ« momentin e rritjes sĂ« numrit tĂ« dĂ«rgesave, shĂ«rbimet ndihmĂ«se nuk arrinin tĂ« pĂ«rballonin detyrat e tyre pĂ«r shpĂ«rndarje dhe pĂ«rcaktim rrugĂ«sh. Si rezultat, ndodhte qĂ« porositĂ« ishin bĂ«rĂ«, por shĂ«rbimi qĂ« krijonte rrugĂ«n nuk funksiononte. Duhet tĂ« them se logjistĂ«t tanĂ« bĂ«nĂ« atĂ« qĂ« dukej pothuajse e pamundur nĂ« kĂ«to kushte, dhe ndĂ«rveprimi i qartĂ« i ekipit ndihmoi nĂ« kompensimin e dĂ«shtimeve tĂ« pĂ«rkohshme tĂ« shĂ«rbimeve. Por njĂ« volum kaq i madh porosish nuk mund tĂ« pĂ«rballohej vazhdimisht me dorĂ«, dhe pas njĂ« kohĂ« do tĂ« pĂ«rballeshim me njĂ« ndĂ«rprerje tĂ« papranueshme mes porosive dhe ekzekutimeve tĂ« tyre.Â
U miratua një sërë masash organizative dhe puna e përbashkët e kolektivit ndihmoi të fitonin disa kohë, derisa ne u dakorduam për kushtet e reja dhe prisnim modernizimin e shërbimeve nga disa partnerë. Ekzistojnë edhe API të tjera që gëzojnë qëndrushmëri të lartë dhe tarifa të larta në rastin e trafikut të madh. Për shembull, në fillim përdorshim një API të njohur për hartat për përcaktimin e adresës së pikës së dërgesës. Por pas përfundimit të muajit, morëm një faturë të madhe prej gati 2 milion rubla. Pas kësaj, vendosëm ta zëvendësonim atë menjëherë. Nuk do të merrem me reklamim, por do të them se shpenzimet tona u ulën ndjeshëm.
PĂ«rfundimi: Duhet patjetĂ«r tĂ« monitoroni kushtet e punĂ«s sĂ« tĂ« gjitha shĂ«rbimeve partnere dhe t'i keni parasysh. Edhe nĂ«se sot duket se ato kanĂ« 'rezerva tĂ« mĂ«dha', kjo nuk do tĂ« thotĂ« se nesĂ«r ato nuk do tĂ« bĂ«hen njĂ« pengesĂ« pĂ«r rritjen. Dhe, sigurisht, Ă«shtĂ« mĂ« mirĂ« tĂ« arrini marrĂ«veshje pĂ«r kushtet financiare tĂ« rritjes sĂ« kĂ«rkesave pĂ«r shĂ«rbimin paraprakisht.Â
Ndonjëherë rezulton se '' (c) nuk ndihmon
Jemi mĂ«suar me "ngĂ«rçet" nĂ« bazĂ«n e tĂ« dhĂ«nave kryesore ose nĂ« serverat e aplikacioneve, por gjatĂ« shkallĂ«zimit, problemet mund tĂ« shfaqen atje ku nuk i prisni. PĂ«r kĂ«rkimin me tekst tĂ« plotĂ« nĂ« sit, ne pĂ«rdorim motorin Apache Solr. Me rritjen e ngarkesĂ«s, ne vĂ«shtruam rĂ«nien e kohĂ«s sĂ« pĂ«rgjigjes, dhe ngarkesa e procesorit tĂ« serverit arriti tashmĂ« nĂ« 100%. ĂfarĂ« mund tĂ« jetĂ« mĂ« e thjeshtĂ« â t'i japim kontejnerit me Solr mĂ« shumĂ« burime.
NĂ« vend tĂ« rritjes sĂ« pritur tĂ« performancĂ«s, serveri thjesht "vdiq". Ai menjĂ«herĂ« ngarkohej nĂ« 100% dhe pĂ«rgjigjej edhe mĂ« ngadalĂ«. Fillimisht kishim 2 bĂ«rthama dhe 2 GB RAM. VendosĂ«m tĂ« bĂ«jmĂ« atĂ« qĂ« zakonisht ndihmon â i dhamĂ« serverit 8 bĂ«rthama dhe 32 GB. TĂ« gjitha u bĂ«nĂ« shumĂ« mĂ« keq (si dhe pse, do tĂ« tregojmĂ« nĂ« njĂ« postim tjetĂ«r).Â
NĂ« disa ditĂ«, ne kuptuam hollĂ«sitĂ« e kĂ«saj çështjeje dhe arritĂ«m performancĂ«n optimale me 8 bĂ«rthama dhe 32 GB. Kjo konfigurim na lejon edhe sot tĂ« vazhdojmĂ« tĂ« rrisim ngarkesĂ«n, qĂ« Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme, sepse rritja po ndodh jo vetĂ«m pĂ«r klientĂ«t, por edhe pĂ«r numrin e dyqaneve tĂ« lidhura â brenda 2 muajve, numri i tyre u rrit dyfish.Â
PĂ«rfundimi: Metodat standarde si "shtoni mĂ« shumĂ« harduer" nuk funksionojnĂ« gjithmonĂ«. Prandaj, gjatĂ« shkallĂ«zimit tĂ« çdo shĂ«rbimi, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet mirĂ« si pĂ«rdor burimet dhe tĂ« testohet paraprakisht funksionimi i tij nĂ« kushte tĂ« reja.Â
Stateless â çelĂ«si pĂ«r shkallĂ«zimin horizontal tĂ« thjeshtĂ«
NĂ« pĂ«rgjithĂ«si, ekipi ynĂ« ndjek qasjen e njohur: shĂ«rbimet nuk duhet tĂ« kenĂ« njĂ« gjendje tĂ« brendshme (stateless) dhe duhet tĂ« jenĂ« tĂ« pavarura nga mjedisi ekzekutues. Kjo na lejoi tĂ« pĂ«rballonim rritjen e ngarkesĂ«s pĂ«rmes shkallĂ«zimit horizontal tĂ« thjeshtĂ«. Por kishim njĂ« shĂ«rbim pĂ«rjashtim â pĂ«rpunuesin e detyrave tĂ« gjata nĂ« sfond. Ai merrej me dĂ«rgimin e email-eve dhe SMS-ve, pĂ«rpunimin e ngjarjeve, gjenerimin e feed-eve, importimin e çmimeve dhe stokut, pĂ«rpunimin e imazheve. Siç ndodhi, ai varej nga ruajtja lokale e skedarĂ«ve dhe ishte nĂ« njĂ« ekzemplar tĂ« vetĂ«m.Â
Kur rritet numri i detyrave në radhën e përpunuesit (gjë që ndodhi natyrshëm me rritjen e numrit të porosive), performanca e host-it, ku ishin vendosur përpunuesi dhe ruajtja e skedarëve, u bë faktori kufizues. Si rezultat, ndaloi përditësimi i asortimentit dhe çmimeve, dërgimi i njoftimeve për përdoruesit dhe shumë funksione të tjera kritike që mbetën ngujuar në radhë. Ekipi i Ops migroi menjëherë ruajtjen e skedarëve në një ruajtje rrjeti të ngjashme me S3, dhe kjo na lejoi të ngrinim disa makina të fuqishme për të shkallëzuar përpunuesin e detyrave të prapambetura.
Përfundimi: Rregulli Stateless duhet të respektohet për të gjitha komponentët pa përjashtim, edhe nëse duket "se nuk do të hasim ndonjë problem këtu". Më mirë të kalosh pak kohë për organizimin e duhur të punës së të gjitha sistemeve, sesa më vonë të shkruash përsëri kodin dhe të riparosh shërbimin që po përjeton ngarkesë.
7 parime për rritje intensive
Megjithëse ekziston disponueshmëria e kapaciteteve shtesë, gjatë procesit të rritjes ne hasëm disa pengesa. Gjatë kësaj periudhe, numri i porosive u rrit më shumë se 4 herë. Tani ne tashmë po dërgojmë më shumë se 17,000 porosi në ditë në 62 qytete dhe planifikojmë të zgjerojmë akoma më shumë gjeografinë - në gjysmën e parë të vitit 2020 pritet të nisë shërbimi në të gjithë Rusinë. Për të përballuar ngarkesën në rritje, duke marrë parasysh pengesat e kaluara, ne kemi nxjerrë për vete 7 parime kryesore të punës në kushte rritje të vazhdueshme:
- Menaxhimi i incidenteve. Ne krijuam një tabelë në Jira, ku çdo incident pasqyrohet në formën e një tiketi. Kjo do të ndihmojë në përparimin dhe realizimin e detyrave të lidhura me incidentin. Sepse në thelb nuk është e frikshme të gabosh - është e frikshme të gabosh dy herë për të njëjtin arsyesh. Për rastet, kur incidentet përsëriten para se të mund të rregullohet shkaku, duhet të jetë gati një udhëzues veprimi, sepse gjatë ngarkesës së madhe është e rëndësishme të reagosh me shpejtësi.
- Monitorimi kërkohet për të gjithë elementët e infrastrukturës pa përjashtim. Pikërisht falë tij ne ishim në gjendje të parashikonim rritjen e ngarkesës dhe të zgjedhim saktë "ngushticat" për t'u përpriorizuar në zgjidhjen e tyre. Shumë gjasa, në raste ngarkese të lartë, do të prishet ose fillojë të ngadalësohet gjithçka që nuk keni menduar. Prandaj është më mirë të krijoni alerte të reja menjëherë pas ndodhisë së incidenteve të para, për të monitoruar dhe parandaluar ato.
- Alerte të duhura janë të domosdoshme kur ngarkohet ndjeshëm sistemi. Së pari, ato duhet të njoftojnë saktësisht se çfarë është prishur. Së dyti, nuk duhet të ketë shumë alerte, sepse mbizotërimi i alerteve jo kritike çon në injorimin e të gjitha njoftimeve në përgjithësi.
- Aplikacionet duhet të jenë pa shtet. Ne u siguruam që për këtë rregull nuk duhet të ketë përjashtime. Duhet të ekzistojë një pavarësi e plotë nga mjedisi i ekzekutimit. Për këtë, ju mund të ruani të dhëna të ndara në DB ose, për shembull, direkt në S3. E akoma më mirë të ndiqni rregullat. Gjatë rritjes së papritur në kohë, optimizimi i kodit nuk është mundësi, dhe do të duhet të përballeni me ngarkesën me anë të rritjes direkte të burimeve kompjuterike dhe shkallëzimit horizontal.
- Kota dhe performanca e shĂ«rbimeve tĂ« jashtme. NĂ« rastin e rritjes sĂ« shpejtĂ«, problemi mund tĂ« ndodhi jo vetĂ«m nĂ« infrastrukturĂ«n tuaj, por edhe nĂ« shĂ«rbimin e jashtĂ«m. E mĂ« e keqe Ă«shtĂ« kur kjo ndodh jo pĂ«r shkak tĂ« njĂ« defekti, por pĂ«r shkak tĂ« arritjes sĂ« kuotave ose limiteve. Prandaj, shĂ«rbimet e jashtme duhet tĂ« shkallĂ«zohen po aq mirĂ« sa dhe ju.Â
- Ndarja e proceseve dhe radhëve. Kjo ndihmon shumë kur ndonjë nga portat has një bllokim. Nuk do të përballeshim me vonesa në transmetimin e të dhënave nëse radhët e mbushura për dërgimin e SMS-ve nuk do të pengonin shkëmbimin e njoftimeve midis sistemeve informative. Po ashtu, do të ishte më e lehtë të rriteshin numri i punëtorëve nëse ata do të punonin veçmas.
- Realitetet financiare. Kur ndodhet një rritje eksplozive e fluksit të të dhënave, nuk ka kohë për të menduar për tarifa dhe abonime. Por ato duhet të mbahen mend, sidomos nëse jeni një kompani e vogël. Një faturë e madhe mund të lëshohet nga çdo pronar API, si dhe nga ofruesi juaj i hostimit. Pra, është e rëndësishme të lexoni kontratat me kujdes.
PĂ«rfundim
Nuk kishte humbje, por e kaluam kĂ«tĂ« fazĂ«, dhe sot pĂ«rpiqemi tĂ« respektojmĂ« tĂ« gjitha parimet e zbuluara, me çdo makinĂ« qĂ« ka mundĂ«sinĂ« pĂ«r rritje tĂ« lehtĂ« tĂ« kapacitetit deri nĂ« 4 herĂ«, pĂ«r tâu pĂ«rballur me ndonjĂ« papĂ«rgatitje.Â
Në postimet e ardhshme do të ndajmë përvojën tonë në hetimin e rënies së performancës në Apache Solr, gjithashtu do të flasim për optimizimin e pyetjeve dhe si bashkëpunimi me FNS ndihmon kompaninë të kursjë para. Abonohuni në blogun tonë që të mos humbisni asgjë dhe na tregoni në komentet nëse keni përjetuar ndonjëherë disa nga këto çështje gjatë rritjes së trafikut.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
A keni përjetuar ngadalësim/rënien e shërbimeve në rast të rritjes drastike të ngarkesës për shkak të:
55,6%Pamundësisë për të shtuar burime llogaritëse në mënyrë të shpejtë10
16,7%Kufijve të infrastrukturës së ofruesit të hosting3
33,3%Kufijve të API-ve të treta6
27,8%Shkeljeve të parimeve stateless të aplikacioneve tuaja5
88,9%Optimizimit të kodit të shërbimeve tuaja16
18 përdorues votuan. 6 përdorues u abstenuan.
Burimi: habr.com
