Përshëndetje, Habr! Gjatë disa muajve të fundit kemi kaluar në një situatë shumë interesante, dhe do doja të ndaj historinë tonë të zgjerimit të infrastrukturës. Gjatë kësaj kohe, SberMarket u rrit katërfish në porosi dhe lançoi shërbimin në 17 qytete të reja. Rritja eksplozive e kërkesës për dorëzim produkteve na detyroi të zgjeronim infrastrukturën. Për përfundimet më interesante dhe të dobishme, lexoni më poshtë.
Më quaj Dima Bobylev, unë jam drejtor teknik i SberMarket. Si kjo është postimi im i parë në blogun tonë, do të thosha disa fjalë për veten dhe për kompaninë. Vjeshtën e kaluar mora pjesë në një garë për liderët e rinj të Runet. Për konkursin, unë për atë se si ne në SberMarket e shohim kulturën e brendshme dhe qasjen ndaj zhvillimit të shërbimit. Dhe megjithëse nuk fitova në konkurs, formuluam për vete parimet themelore të zhvillimit të ekosistemit IT.
Kur menaxhoni një ekip, është e rëndësishme të kuptoni dhe të gjeni balancën midis 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 që të rriten vazhdimisht sasisë dhe ritmi i zhvillimit. Megjithatë, ne i kushtojmë mjaft kohë zhvilluesve për analizën paraprake dhe për shkruarjen cilësore të kodit. Qasja e formuar ndihmon jo vetëm në krijimin e një produkti funksional, por edhe në zgjerimin dhe zhvillimin e tij të mëtejshëm. Si rezultat i një rritjeje të tillë, SberMarket ka bërë tashmë lider në mesin e shërbimeve të shpërndarjes së produkteve: ne dërgojmë çdo ditë rreth 18 mijë porosi, ndonëse në fillim të shkurtit ishim rreth 3500.
NjĂ«herĂ«, njĂ« klient kĂ«rkoi qĂ« kurieri i SberMarket tĂ« dorĂ«zonte produktet nĂ« mĂ«nyrĂ« pa kontakt â drejtpĂ«rdrejt nĂ« ballkon
Por t'i kaluar nĂ« detaje. GjatĂ« muajve tĂ« fundit, ne kemi punuar aktivisht pĂ«r zgjerimin e infrastrukturĂ«s sĂ« kompanisĂ« sonĂ«. Nevoja pĂ«r kĂ«tĂ« ishte e justifikuar nga faktorĂ« tĂ« brendshĂ«m dhe tĂ« jashtĂ«m. NĂ« tĂ« njĂ«jtĂ«n kohĂ« me rritjen e numrit tĂ« 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 qĂ« u pĂ«rgatitĂ«m, rezervuam infrastrukturĂ«n kryesore dhe kalkuluam pĂ«r mundĂ«sinĂ« e zgjerimit vertikal dhe horizontal tĂ« tĂ« gjithĂ« makinave virtuale tĂ« vendosura nĂ« cloud-in e Yandex. MegjithatĂ«, praktika tregoi: "Ădo gjĂ« qĂ« mund tĂ« shkojĂ« keq, do tĂ« shkojĂ« keq". Dhe sot dua tĂ« ndaj situatat mĂ« interesante qĂ« ndodhĂ«n gjatĂ« kĂ«tyre javĂ«ve. Shpresoj qĂ« pĂ«rvoja jonĂ« tĂ« jetĂ« e dobishme pĂ«r ju.
Slave në gatishmëri të plotë
Para fillimin e pandemisë, ne u përballëm me një rritje të numrit të kërkesave për serverët tanë backend. Tendenca e porosisë së produkteve për dorëzim në shtëpi filloi të merrte hov, dhe me hyrjen e masave të para të vetëizolimit për shkak të COVID-19, ngarkesa u rrit dramatikisht gjatë gjithë ditës. Ngritja e nevojës për të lehtësuar në mënyrë urgjente serverët master të bazës së të dhënave kryesore dhe për të transferuar disa kërkesa për lexim në serverët-replikë (slave) u bë evidente.
Ne ishim pĂ«rgatitur paraprakisht pĂ«r kĂ«tĂ« hap, dhe pĂ«r kĂ«tĂ« manovĂ«r ishin bĂ«rĂ« tĂ« gatshĂ«m 2 serverĂ« slave. Aty kryesisht punonin detyrat batch pĂ«r gjenerimin e informacioneve pĂ«r shkĂ«mbimin e tĂ« dhĂ«nave me partnerĂ«t. KĂ«to procese krijonin ngarkesĂ« shtesĂ« dhe plotĂ«sisht tĂ« drejtĂ« ishin nxjerrĂ« "jashtĂ« skenĂ«s" disa muaj mĂ« parĂ«.Â
Meqë në Slave po zhvillohej replikimi, ne ndiqnim konceptin se aplikacionet mund të punonin me këto vetëm në modalitetin read only. Plani i Rimëkëmbjes nga Katastrofat parashikonte që në rast katastrofe ne mund të thjesht montonim Slave në vend të Master dhe të kalonim të gjitha kërkesat për të shkruar dhe lexuar në Slave. Megjithatë, ne gjithashtu dëshironim të përdornim replikat për nevojat e departamentit të analizës, kështu që serverët nuk u shndërruan plotësisht në statusin read only, por në çdo host kishte një grup të vet përdoruesish, dhe disa kishin të drejta shkrimi për të ruajtur rezultate të ndërmjetme të llogaritjeve.
Derisa arritëm një nivel të caktuar ngarkese, na mjaftonte masteri për të shkruar dhe lexuar gjatë përpunimit të kërkesave http. Në mesin e marsit, sapo Sbermarket vendosi të kalojë plotësisht në punë të largët, ne filluam një rritje të ndjeshme të RPS. Ekipi ynë i gjithnjë e më shumë klientëve po kalonte në vetëizolim ose punë nga shtëpia, gjë që kishte një ndikim në treguesit e ngarkesës.
Përformanca e «maestro» 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 në mënyrë transparente kërkesat për shk writing në maestro, dhe leximin në skllevër, përdorëm ruby gem «». Krijuam një përdorues special me postfixin _readonly pa të drejta për shk writing. Por, për shkak të një gabimi në konfigurimin e një nga host-ëve, disa kërkesa për shk writing u dërguan në serverin slave me emrin e përdoruesit, i cili kishte të drejtat përkatëse.
Problemi nuk u shfaq menjëherë, pasi ngarkesa e rritur rriti vonesat e skllevërve. Inkonzistenca e të dhënave u zbulua në mëngjes, kur pas importeve të natës, skllevërët nuk «kapan» maestro. E klasifikum këtë si rezultat i ngarkesës së lartë në shërbim dhe importit të lidhur me hapjen e dyqaneve të reja. Por, të jepnim të dhëna me vonesë disa orëshe ishte e papranueshme, dhe ne kaluam proceset në skllevrin analitik të dytë, sepse ai kishte mëoshumë burime dhe nuk ishte i ngarkuar me kërkesa për lexim (çfarë ne shpjeguam për veten tonë mungesën e vonesës së replikimit).
Pasi u shqyrtuam arsyet e "shkëputjes" së slave kryesor, analitika tashmë kishte dalë jashtë funksioni për arsye të njëjta. Pavarësisht se kishim dy serverë të tjerë shtesë, në të cilët planifikonim të transferonim ngarkesën në rast të dështimit të masterit, për shkak të një gabimi të bezdisshëm, në momentin kritik nuk kishte asnjë.
Por pasi bëmë jo vetëm dump të DB (restorimi në atë moment zgjaste rreth 5 orë), por edhe snapshot të serverit master, arritëm të nisnim replikën brenda 2 orëve. Megjithatë, pas kësaj na prit një periudhë e gjatë përderisa u përditësua logu i replikimit (sepse procesi zhvillohet në mod të vetëm-fibrave, por kjo është një histori krejt tjetër).
Dalja: Pas njĂ« incidenti tĂ« tillĂ«, bĂ«ri tĂ« qartĂ« se duhej tĂ« hiqnim dorĂ« nga praktika e kufizimit tĂ« shkrimit pĂ«r pĂ«rdoruesit dhe tĂ« shpallnim serverin tĂ« gjithĂ« si readonly. Me kĂ«tĂ« qasje, nuk mund tĂ« dyshojmĂ« se replikat do tĂ« jenĂ« tĂ« dostÄpne nĂ« momentet kritikĂ«.
Optimizimi edhe i një kërkese të rëndë mund të "rikthejë në jetë" DB-në.
Edhe pse ne pĂ«rditĂ«sojmĂ« vazhdimisht katalogun nĂ« faqen tonĂ«, kĂ«rkesat qĂ« kemi dĂ«rguar nĂ« serverĂ«t Slave kishin njĂ« vonesĂ« tĂ« vogĂ«l nga Master. Koha qĂ« na duhet pĂ«r tĂ« zbuluar dhe zgjidhur problemin e "slave-ve qĂ« papritur dolĂ«n nga gara" ishte mĂ« e madhe se "bariera psikologjike" (nĂ« kĂ«tĂ« kohĂ« mund tĂ« ndodhte pĂ«rditĂ«simi i çmimeve, dhe klientĂ«t do tĂ« shikonin tĂ« dhĂ«na tĂ« prapambetura), dhe ishim tĂ« detyruar tĂ« kalonim tĂ« gjitha kĂ«rkesat nĂ« serverin kryesor tĂ« DB. Si rezultat, faqja funksiononte ngadalĂ«... por tĂ« paktĂ«n funksiononte. Dhe ndĂ«rsa Slave po rikuperohej, nuk na mbetej gjĂ« tjetĂ«r veçse optimizimi.Â
NdĂ«rsa serverĂ«t Slave po rikuperoheshin, minutat kalonin ngadalĂ«, Master mbetej i ngarkuar, dhe ne vendosĂ«m tĂ« fokusohemi nĂ« optimizimin e detyrave aktive sipas "Rregullit tĂ« Pareto": zgjodhĂ«m KĂRKESAT TOP qĂ« jepnin pjesĂ«n mĂ« tĂ« madhe tĂ« ngarkesĂ«s dhe filluam tuning-un. Kjo bĂ«hej direkt "nĂ« fluturim".
Efekti interesante ishte se MySQL, i ngarkuar deri nĂ« kufi, reagon edhe ndaj pĂ«rmirĂ«simeve tĂ« vogla nĂ« procese. Optimizimi i disa pyetjeve qĂ« japin vetĂ«m 5% tĂ« ngarkesĂ«s totale tashmĂ« tregoi njĂ« çlirim tĂ« konsiderueshĂ«m tĂ« CPU. Si rezultat, arritĂ«m tĂ« sigurojmĂ« njĂ« rezervĂ« tĂ« pranueshme burimesh pĂ«r funksionimin e Master-it me bazĂ«n e tĂ« dhĂ«nave dhe tĂ« marrim kohĂ«n e nevojshme pĂ«r rikuperimin e replika.Â
Dalja: Madje, një optimizim i vogël lejon "të mbijetosh" nën ngarkesë për disa orë. Na e arriti pikërisht kohën e nevojshme për rikuperimin e serverëve me replika. E kaluara, ne do të diskutojmë aspektet teknike të optimizimit të pyetjeve në një nga postimet tona të ardhshme. Pra, regjistrohuni në blogun tonë, nëse kjo mund t'ju jetë e dobishme.
Organizoni monitorimin e funksionimit të shërbimeve partnere.
Ne merremi me pĂ«rpunimin e porosive nga klientĂ«t, prandaj shĂ«rbimet tona janĂ« nĂ« vazhdimĂ«si nĂ« bashkĂ«punim me API tĂ« jashtme â kĂ«to janĂ« porte pĂ«r dĂ«rgimin e SMS-ve, platforma pagesash, sisteme rruge, geokoder, shĂ«rbimi i FNS dhe shumĂ« sisteme tĂ« tjera. Dhe kur ngarkesa filloi tĂ« rritet me shpejtĂ«si, filluam tĂ« pĂ«rballemi me kufizimet e API-ve tĂ« shĂ«rbimeve partnere, pĂ«r tĂ« cilat nuk kishim menduar kurrĂ« mĂ« parĂ«.
NjĂ« tejkalim i papritur i kuotave tĂ« shĂ«rbimeve partnere mund tĂ« çojĂ« nĂ« shpĂ«rthime nĂ« shĂ«rbimin tuaj. ShumĂ« API bllokojnĂ« klientĂ«t qĂ« tejkalojnĂ« limitet, dhe nĂ« disa raste, njĂ« numĂ«r i tepĂ«rt kĂ«rkesash mund tĂ« mbingarkojĂ« prodhimin e partnerit.Â
PĂ«r shembull, gjatĂ« rritjes sĂ« numrit tĂ« dĂ«rgesave, shĂ«rbimet pĂ«rkatĂ«se nuk ishin nĂ« gjendje tĂ« menaxhonin detyrat e shpĂ«rndarjes dhe pĂ«rcaktimin e rrugĂ«ve. Si rezultat, bĂ«hej e qartĂ« se porositĂ« ishin bĂ«rĂ«, por shĂ«rbimi qĂ« krijonte rrugĂ«n nuk funksiononte. Duhet thĂ«nĂ« se logjistĂ«t tanĂ« bĂ«nĂ« pothuajse tĂ« pamundurĂ«n nĂ« kĂ«to kushte, dhe bashkĂ«punimi i qartĂ« i ekipit ndihmoi nĂ« kompensimin e dĂ«shtimeve pĂ«rkohshme tĂ« shĂ«rbimeve. Por njĂ« volum tĂ« tillĂ« porosish nuk Ă«shtĂ« e realizueshme ta pĂ«rpunosh nĂ« mĂ«nyrĂ« manuale vazhdimisht, dhe pas njĂ« kohe do tĂ« pĂ«rballeshim me njĂ« boshllĂ«k tĂ« papranueshĂ«m mes porosive dhe realizimit tĂ« tyre.Â
U mënyrë efektive, një seri masash organizative dhe puna e përbashkët e ekipit na ndihmuan të fitojmë kohë, derisa u pajtuam për kushte të reja dhe prisnim modernizimin e shërbimeve nga disa partnerë. Ekzistojnë edhe API të tjera që ofrojnë një qëndrueshmëri të lartë dhe tarifa të arsyeshme për trafik të lartë. Për shembull, në fillim përdorëm një API të njohur të hartave për të përcaktuar adresën e pikës së dërgesës. Por pas një muaji morëm një faturë të madhe prej pothuajse 2 milion rubla. Pas kësaj, vendosëm ta zëvendësojmë atë me urgjencë. Nuk do të merrem me reklamim, por them se shpenzimet tona u reduktuan ndjeshëm.
Dalja: ĂshtĂ« thelbĂ«sore tĂ« monitoroni kushtet e punĂ«s sĂ« tĂ« gjithĂ« shĂ«rbimeve partnere dhe t'i keni ato nĂ« mendje. Edhe nĂ«se sot duket se ato janĂ« "me njĂ« rezervĂ« tĂ« madhe", kjo nuk do tĂ« thotĂ« se nesĂ«r ato nuk do tĂ« bĂ«hen njĂ« pengesĂ« pĂ«r rritje. Dhe, sigurisht, Ă«shtĂ« mĂ« mirĂ« tĂ« merrni pĂ«rsipĂ«r kushte financiare pĂ«r kĂ«rkesat e rritura pĂ«r shĂ«rbimin paraprakisht.Â
Ndonjëherë duket se "" (c) nuk ndihmon
Jemi tĂ« zakonshĂ«m me «ngĂ«rçet» nĂ« bazĂ«n e tĂ« dhĂ«nave kryesore ose nĂ« serverĂ«t e aplikacioneve, por gjatĂ« skalimit, problemi mund tĂ« shfaqet aty ku nuk e prisnim. PĂ«r kĂ«rkimin nĂ« tekst tĂ« plotĂ« nĂ« faqen tonĂ«, ne pĂ«rdorim motorin Apache Solr. Me rritjen e ngarkesĂ«s, ne vĂ«rejtĂ«m njĂ« rĂ«nie tĂ« kohĂ«s sĂ« pĂ«rgjigjes, dhe ngarkesa e procesorit tĂ« serverit arriti deri nĂ« 100%. ĂfarĂ« mund tĂ« jetĂ« mĂ« e lehtĂ« â do t'i japim kontejnerit me Solr mĂ« shumĂ« burime.
NĂ« vend tĂ« rritjes sĂ« pritur tĂ« performancĂ«s, serveri thjesht «vdiq». Ai menjĂ«herĂ« u ngarkua nĂ« 100% dhe dha pĂ«rgjigje edhe mĂ« ngadalĂ«. Fillimisht kishim 2 bĂ«rthamĂ« dhe 2 GB RAM. Ne vendosĂ«m tĂ« bĂ«nim atĂ« qĂ« zakonisht ndihmon â i dhamĂ« serverit 8 bĂ«rthama dhe 32 GB. ĂshtĂ« bĂ«rĂ« shumĂ« mĂ« keq (se si dhe pse â do ta pĂ«rshkruajmĂ« nĂ« njĂ« postim tĂ« veçantĂ«).Â
GjatĂ« disa ditĂ«ve ne e kuptuam nĂ« thellĂ«si kĂ«tĂ« çështje dhe arritĂ«m performancĂ«n optimale me 8 bĂ«rthama dhe 32 GB RAM. Kjo konfigurim lejon qĂ« sot tĂ« vazhdojmĂ« tĂ« rrisim ngarkesĂ«n, qĂ« Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme, sepse rritja ndodh jo vetĂ«m me klientĂ«t, por edhe me numrin e dyqaneve tĂ« lidhura â brenda 2 muajve numri i tyre Ă«shtĂ« dyfishuar.Â
Dalja: Metodat standarde tĂ« tipit "shto mĂ« shumĂ« harduer" nuk funksionojnĂ« gjithmonĂ«. Prandaj, kur zmadhojmĂ« çdo shĂ«rbim, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« kuptojmĂ« mirĂ« se si pĂ«rdor burimet dhe tĂ« testojmĂ« paraprakisht performancĂ«n e tij nĂ« kushte tĂ« reja.Â
Stateless â çelĂ«si pĂ«r njĂ« zmadhojmĂ« horizontale tĂ« thjeshtĂ«
NĂ« pĂ«rgjithĂ«si, ekipi ynĂ« ndjek njĂ« qasje tĂ« njohur: shĂ«rbimet nuk duhet tĂ« kenĂ« njĂ« gjendje tĂ« brendshme (stateless) dhe duhet tĂ« jenĂ« tĂ« pavarura nga mjedisi i ekzekutimit. Kjo na ka lejuar tĂ« pĂ«rballojmĂ« rritjen e ngarkesĂ«s pĂ«rmes zmadhojve horizontale tĂ« thjeshta. Por pĂ«r ne kishte njĂ« shĂ«rbim pĂ«rjashtimi â menaxhuesi i 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 stoqeve, pĂ«rpunimin e imazheve. Raste do tĂ« ndodhte qĂ« ai varej nga ruajtja e skedarĂ«ve lokale dhe ishte nĂ« njĂ« eksemplar tĂ« vetĂ«m.Â
Kur rritet numri i detyrave në radhën e përpunuesit (çka është natyrshëm ndodhur me rritjen e numrit të porosive), performanca e hostit, në të cilin ishin vendosur përpunuesi dhe ruajtja e skedarëve, u bë faktori kufizues. Si rezultat, u ndal njëherë përditësimi i asortimentit dhe çmimeve, dërgimi i njoftimeve për përdoruesit dhe shumë funksione kritike të tjera, të bllokuara në radhë. Ekipi Ops migroi menjëherë ruajtjen e skedarëve në një sistem të ngjashëm me S3, dhe kjo na lejoi të ngrejmë disa makina të fuqishme për të skalituar përpunuesin e detyrave në sfond.
Dalja: Rregulli Stateless duhet të respektohet për të gjithë komponentët pa përjashtim, edhe nëse duket "se këtu sigurisht nuk do të hasim në ndonjë kufizim". Më mirë të investoni pak kohë në organizimin e duhur të punës së të gjitha sistemeve sesa më vonë të shkruani përsëri kodin dhe të rregulloni shërbimin që po përballet me ngarkesë.
7 principe për rritje intensive
Megjithëse disponojmë kapacitete shtesë, gjatë rritjes kemi hasur në disa gabime. Gjatë kësaj periudhe, numri i porosive është rritur më shumë se 4 herë. Tani ne tashmë dorëzojmë më shumë se 17,000 porosi në ditë në 62 qytete dhe planifikojmë të zgjedhim edhe më shumë gjeografi - në gjysmën e parë të vitit 2020 pritet të fillojmë shërbimin në të gjithë Rusinë. Për të menaxhuar ngarkesën në rritje, duke marr parasysh gabimet e kaluara, ne kemi formuluar 7 parime kryesore për të punuar në kushte rritjeje të vazhdueshme:
- Menaxhimi i incidenteve. Ne krijuam një board në Jira, ku çdo incident pasqyrohet në formën e një tiketi. Kjo ndihmon për prioritizimin dhe realizimin e detyrave të lidhura me incidentin. Sepse në thelb, nuk është e tmerrshme të gabosh - e tmerrshme është të gabosh dy herë për të njëjtin arsye. Për rastet kur incidentet përsëriten para se të mund të rregullojmë shkakun, duhet të kemi një udhëzim për veprim, sepse gjatë ngarkesës së madhe është e rëndësishme të reagosh menjëherë.
- Monitorimi është e nevojshme për të gjitha elementet e infrastrukturës pa përjashtim. Pikërisht falë tij ne mundëm të parashikojmë rritjen e ngarkesës dhe të zgjedhim saktë "kokat e shisheve" për prioritizimin e zgjidhjes. Me siguri, në raste ngarkese të lartë do të dështojë ose do të shkaktojë ngadalësim gjithçka që nuk e kishe menduar. Prandaj, alerët e rinj është më mirë t'i krijosh menjëherë pas ndodhisë së parë, për t'i monitoruar dhe parashikuar ato.
- Alerët e duhur janë thjesht të nevojshëm kur ka një rritje të papritur të ngarkesës. Së pari, ata duhet të raportojnë saktësisht se çfarë ka dështuar. Së dyti, nuk duhet të ketë shumë alerë, sepse një numër i madh aleresh jo-kritike çon në injorimin e të gjitha njoftimeve në përgjithësi.
- Aplikacionet duhet të jenë stateless. Ne e kemi konfirmuar se për këtë rregull nuk duhet të ketë përjashtime. Nevojitet një pavarësi e plotë nga mjedisi i ekzekutimit. Për këtë, mund të ruani të dhënat e ndara në bazën e të dhënave ose, për shembull, drejtpërdrejt në S3. Dhe akoma më mirë është të ndjekësh rregullat.. Gjatë rritjes së shpejtë, optimizimi i kodit është i pamundur, dhe do t'ju duhet të përballoni ngarkesën duke rritur thjesht burimet llogaritëse dhe duke përdorur skalimin horizontal.
- Kuotat dhe performanca e shĂ«rbimeve tĂ« jashtme. Kur rritja Ă«shtĂ« e shpejtĂ«, problemi mund tĂ« ndodhĂ« jo vetĂ«m nĂ« infrastrukturĂ«n tuaj, por edhe nĂ« shĂ«rbimin e jashtĂ«m. E mjerueshme Ă«shtĂ« kur ndodh kjo jo pĂ«r shkak tĂ« njĂ« defekti, por pĂ«r shkak tĂ« arritjes sĂ« kuotave ose kufijve. Prandaj, shĂ«rbimet e jashtme duhet tĂ« kenĂ« njĂ« kapacitet rritjeje tĂ« njĂ«jtĂ« si ju.Â
- Ndani proceset dhe radhët. Kjo ndihmon shumë kur një nga porta përjeton ngushticë. Nuk do të përballeshim me vonesa në transferimin 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 mes sistemeve informacioni. Po ashtu, do të ishte më e lehtë të rriteshin numri i punëtorëve nëse ata do të punonin ndaras.
- Realitetet financiare. Kur ka një rritje të shpejtë të fluksit të të dhënave, nuk ka kohë për të menduar për tarifa dhe abonime. Por, duhet t'i mbani mend ato, veçanërisht nëse jeni një kompani e vogël. Një faturë e madhe mund të vijë nga çdo pronar API, si dhe nga ofruesi juaj i hostimit. Prandaj, është e rëndësishme të lexoni me kujdes kontratat.
PĂ«rfundimi
Me ndonjĂ« humbje, por e kaluam kĂ«tĂ« fazĂ«, dhe sot mundohemi tĂ« mbajmĂ« tĂ« gjitha parimet e gjetura, pĂ«rderisa çdo makinĂ« ka mundĂ«sinĂ« pĂ«r tĂ« rritur performancĂ«n e saj 4 herĂ«, pĂ«r tĂ« pĂ«rballuar ndonjĂ« papritur.Â
Në postimet e ardhshme ne do të ndajmë përvojën tonë në hetimin e rënies së performancës në Apache Solr, si dhe do të flasim për optimizimin e kërkesave dhe si bashkëpunimi me FNS ndihmon kompaninë për të kursyer para. Abonohuni në blogun tonë për të mos humbur asgjë dhe tregoni në komentet tuaj nëse keni hasur në probleme të ngjashme gjatë rritjes së trafikut.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutemi.
A keni përjetuar ngadalësim/rënien e shërbimit për shkak të një rritjeje të papritur të ngarkesës për:
55,6%Për shkak të pamundësisë për të shtuar shpejt burime computuese
16,7%Kufizimeve të infrastrukturës së ofruesit të hostimit
33,3%Kufizimeve të API-ve të jashtme
27,8%Shkeljet e principeve stateless të aplikacioneve të saj
88,9%Optimizimi i kodit të shërbimeve të saj
Kanë votuar 18 përdorues. 6 përdorues abstenuan.
Burimi: habr.com
