{"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\/sq\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Si e p\u00ebrballuam nj\u00eb rritje t\u00eb papritur t\u00eb ngarkes\u00ebs x10 n\u00eb distanc\u00eb dhe cilat ishin p\u00ebrfundimet q\u00eb arrit\u00ebm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00ebrsh\u00ebndetje, Habr! Gjat\u00eb disa muajve t\u00eb fundit kemi kaluar n\u00eb nj\u00eb situat\u00eb shum\u00eb interesante, dhe do doja t\u00eb ndaj historin\u00eb ton\u00eb t\u00eb zgjerimit t\u00eb infrastruktur\u00ebs. Gjat\u00eb k\u00ebsaj kohe, SberMarket u rrit kat\u00ebrfish n\u00eb porosi dhe lan\u00e7oi sh\u00ebrbimin n\u00eb 17 qytete t\u00eb reja. Rritja eksplozive e k\u00ebrkes\u00ebs p\u00ebr dor\u00ebzim produkteve na detyroi t\u00eb zgjeronim infrastruktur\u00ebn. P\u00ebr p\u00ebrfundimet m\u00eb interesante dhe t\u00eb dobishme, lexoni m\u00eb posht\u00eb.<\/p>\n

\"Si
\n<\/a><\/noindex>
\nM\u00eb quaj Dima Bobylev, un\u00eb jam drejtor teknik i SberMarket. Si kjo \u00ebsht\u00eb postimi im i par\u00eb n\u00eb blogun ton\u00eb, do t\u00eb thosha disa fjal\u00eb p\u00ebr veten dhe p\u00ebr kompanin\u00eb. Vjesht\u00ebn e kaluar mora pjes\u00eb n\u00eb nj\u00eb gar\u00eb p\u00ebr lider\u00ebt e rinj t\u00eb Runet. P\u00ebr konkursin, un\u00eb shkrova nj\u00eb histori t\u00eb vog\u00ebl<\/a><\/noindex> p\u00ebr at\u00eb se si ne n\u00eb SberMarket e shohim kultur\u00ebn e brendshme dhe qasjen ndaj zhvillimit t\u00eb sh\u00ebrbimit. Dhe megjith\u00ebse nuk fitova n\u00eb konkurs, formuluam p\u00ebr vete parimet themelore t\u00eb zhvillimit t\u00eb ekosistemit IT. <\/p>\n

Kur menaxhoni nj\u00eb ekip, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptoni dhe t\u00eb gjeni balanc\u00ebn midis nevojave t\u00eb biznesit dhe k\u00ebrkesave t\u00eb \u00e7do zhvilluesi t\u00eb ve\u00e7ant\u00eb. Aktualisht, SberMarket po rritet 13 her\u00eb nga viti n\u00eb vit, dhe kjo ndikon n\u00eb produkt, duke k\u00ebrkuar q\u00eb t\u00eb rriten vazhdimisht sasis\u00eb dhe ritmi i zhvillimit. Megjithat\u00eb, ne i kushtojm\u00eb mjaft koh\u00eb zhvilluesve p\u00ebr analiz\u00ebn paraprake dhe p\u00ebr shkruarjen cil\u00ebsore t\u00eb kodit. Qasja e formuar ndihmon jo vet\u00ebm n\u00eb krijimin e nj\u00eb produkti funksional, por edhe n\u00eb zgjerimin dhe zhvillimin e tij t\u00eb m\u00ebtejsh\u00ebm. Si rezultat i nj\u00eb rritjeje t\u00eb till\u00eb, SberMarket ka b\u00ebr\u00eb tashm\u00eb lider n\u00eb mesin e sh\u00ebrbimeve t\u00eb shp\u00ebrndarjes s\u00eb produkteve: ne d\u00ebrgojm\u00eb \u00e7do dit\u00eb rreth 18 mij\u00eb porosi, ndon\u00ebse n\u00eb fillim t\u00eb shkurtit ishim rreth 3500.<\/p>\n

\"Si
\nNj\u00ebher\u00eb, nj\u00eb klient k\u00ebrkoi q\u00eb kurieri i SberMarket t\u00eb dor\u00ebzonte produktet n\u00eb m\u00ebnyr\u00eb pa kontakt \u2014 drejtp\u00ebrdrejt n\u00eb ballkon<\/i><\/p>\n

Por t'i kaluar n\u00eb detaje. Gjat\u00eb muajve t\u00eb fundit, ne kemi punuar aktivisht p\u00ebr zgjerimin e infrastruktur\u00ebs s\u00eb kompanis\u00eb son\u00eb. Nevoja p\u00ebr k\u00ebt\u00eb ishte e justifikuar nga faktor\u00eb t\u00eb brendsh\u00ebm dhe t\u00eb jasht\u00ebm. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb me rritjen e numrit t\u00eb klient\u00ebve, numri i dyqaneve t\u00eb lidhura u rrit nga 90 n\u00eb fillim t\u00eb vitit n\u00eb m\u00eb shum\u00eb se 200 deri n\u00eb mes t\u00eb majit. Sigurisht q\u00eb u p\u00ebrgatit\u00ebm, rezervuam infrastruktur\u00ebn kryesore dhe kalkuluam p\u00ebr mund\u00ebsin\u00eb e zgjerimit vertikal dhe horizontal t\u00eb t\u00eb gjith\u00eb makinave virtuale t\u00eb vendosura n\u00eb cloud-in e Yandex. Megjithat\u00eb, praktika tregoi: \"\u00c7do gj\u00eb q\u00eb mund t\u00eb shkoj\u00eb keq, do t\u00eb shkoj\u00eb keq\". Dhe sot dua t\u00eb ndaj situatat m\u00eb interesante q\u00eb ndodh\u00ebn gjat\u00eb k\u00ebtyre jav\u00ebve. Shpresoj q\u00eb p\u00ebrvoja jon\u00eb t\u00eb jet\u00eb e dobishme p\u00ebr ju.<\/p>\n

Slave n\u00eb gatishm\u00ebri t\u00eb plot\u00eb<\/h3>\n

\nPara fillimin e pandemis\u00eb, ne u p\u00ebrball\u00ebm me nj\u00eb rritje t\u00eb numrit t\u00eb k\u00ebrkesave p\u00ebr server\u00ebt tan\u00eb backend. Tendenca e porosis\u00eb s\u00eb produkteve p\u00ebr dor\u00ebzim n\u00eb sht\u00ebpi filloi t\u00eb merrte hov, dhe me hyrjen e masave t\u00eb para t\u00eb vet\u00ebizolimit p\u00ebr shkak t\u00eb COVID-19, ngarkesa u rrit dramatikisht gjat\u00eb gjith\u00eb dit\u00ebs. Ngritja e nevoj\u00ebs p\u00ebr t\u00eb leht\u00ebsuar n\u00eb m\u00ebnyr\u00eb urgjente server\u00ebt master t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave kryesore dhe p\u00ebr t\u00eb transferuar disa k\u00ebrkesa p\u00ebr lexim n\u00eb server\u00ebt-replik\u00eb (slave) u b\u00eb evidente.<\/p>\n

Ne ishim p\u00ebrgatitur paraprakisht p\u00ebr k\u00ebt\u00eb hap, dhe p\u00ebr k\u00ebt\u00eb manov\u00ebr ishin b\u00ebr\u00eb t\u00eb gatsh\u00ebm 2 server\u00eb slave. Aty kryesisht punonin detyrat batch p\u00ebr gjenerimin e informacioneve p\u00ebr shk\u00ebmbimin e t\u00eb dh\u00ebnave me partner\u00ebt. K\u00ebto procese krijonin ngarkes\u00eb shtes\u00eb dhe plot\u00ebsisht t\u00eb drejt\u00eb ishin nxjerr\u00eb \"jasht\u00eb sken\u00ebs\" disa muaj m\u00eb par\u00eb.\u00a0<\/p>\n

Meq\u00eb n\u00eb Slave po zhvillohej replikimi, ne ndiqnim konceptin se aplikacionet mund t\u00eb punonin me k\u00ebto vet\u00ebm n\u00eb modalitetin read only. Plani i Rim\u00ebk\u00ebmbjes nga Katastrofat parashikonte q\u00eb n\u00eb rast katastrofe ne mund t\u00eb thjesht montonim Slave n\u00eb vend t\u00eb Master dhe t\u00eb kalonim t\u00eb gjitha k\u00ebrkesat p\u00ebr t\u00eb shkruar dhe lexuar n\u00eb Slave. Megjithat\u00eb, ne gjithashtu d\u00ebshironim t\u00eb p\u00ebrdornim replikat p\u00ebr nevojat e departamentit t\u00eb analiz\u00ebs, k\u00ebshtu q\u00eb server\u00ebt nuk u shnd\u00ebrruan plot\u00ebsisht n\u00eb statusin read only, por n\u00eb \u00e7do host kishte nj\u00eb grup t\u00eb vet p\u00ebrdoruesish, dhe disa kishin t\u00eb drejta shkrimi p\u00ebr t\u00eb ruajtur rezultate t\u00eb nd\u00ebrmjetme t\u00eb llogaritjeve.<\/p>\n

Derisa arrit\u00ebm nj\u00eb nivel t\u00eb caktuar ngarkese, na mjaftonte masteri p\u00ebr t\u00eb shkruar dhe lexuar gjat\u00eb p\u00ebrpunimit t\u00eb k\u00ebrkesave http. N\u00eb mesin e marsit, sapo Sbermarket vendosi t\u00eb kaloj\u00eb plot\u00ebsisht n\u00eb pun\u00eb t\u00eb larg\u00ebt, ne filluam nj\u00eb rritje t\u00eb ndjeshme t\u00eb RPS. Ekipi yn\u00eb i gjithnj\u00eb e m\u00eb shum\u00eb klient\u00ebve po kalonte n\u00eb vet\u00ebizolim ose pun\u00eb nga sht\u00ebpia, gj\u00eb q\u00eb kishte nj\u00eb ndikim n\u00eb treguesit e ngarkes\u00ebs.<\/p>\n

P\u00ebrformanca e \u00abmaestro\u00bb nuk ishte m\u00eb e mjaftueshme, prandaj filluam t\u00eb transferonim disa nga k\u00ebrkesat m\u00eb t\u00eb r\u00ebnda p\u00ebr lexim n\u00eb replik\u00eb. P\u00ebr t\u00eb drejtuar n\u00eb m\u00ebnyr\u00eb transparente k\u00ebrkesat p\u00ebr shk writing n\u00eb maestro, dhe leximin n\u00eb skllev\u00ebr, p\u00ebrdor\u00ebm ruby gem \u00abOctopus<\/a><\/noindex>\u00bb. Krijuam nj\u00eb p\u00ebrdorues special me postfixin _readonly pa t\u00eb drejta p\u00ebr shk writing. Por, p\u00ebr shkak t\u00eb nj\u00eb gabimi n\u00eb konfigurimin e nj\u00eb nga host-\u00ebve, disa k\u00ebrkesa p\u00ebr shk writing u d\u00ebrguan n\u00eb serverin slave me emrin e p\u00ebrdoruesit, i cili kishte t\u00eb drejtat p\u00ebrkat\u00ebse.<\/p>\n

Problemi nuk u shfaq menj\u00ebher\u00eb, pasi ngarkesa e rritur rriti vonesat e skllev\u00ebrve. Inkonzistenca e t\u00eb dh\u00ebnave u zbulua n\u00eb m\u00ebngjes, kur pas importeve t\u00eb nat\u00ebs, skllev\u00ebr\u00ebt nuk \u00abkapan\u00bb maestro. E klasifikum k\u00ebt\u00eb si rezultat i ngarkes\u00ebs s\u00eb lart\u00eb n\u00eb sh\u00ebrbim dhe importit t\u00eb lidhur me hapjen e dyqaneve t\u00eb reja. Por, t\u00eb jepnim t\u00eb dh\u00ebna me vones\u00eb disa or\u00ebshe ishte e papranueshme, dhe ne kaluam proceset n\u00eb skllevrin analitik t\u00eb dyt\u00eb, sepse ai kishte m\u00ebo<\/strong>shum\u00eb burime dhe nuk ishte i ngarkuar me k\u00ebrkesa p\u00ebr lexim (\u00e7far\u00eb ne shpjeguam p\u00ebr veten ton\u00eb munges\u00ebn e vones\u00ebs s\u00eb replikimit).<\/p>\n

Pasi u shqyrtuam arsyet e \"shk\u00ebputjes\" s\u00eb slave kryesor, analitika tashm\u00eb kishte dal\u00eb jasht\u00eb funksioni p\u00ebr arsye t\u00eb nj\u00ebjta. Pavar\u00ebsisht se kishim dy server\u00eb t\u00eb tjer\u00eb shtes\u00eb, n\u00eb t\u00eb cil\u00ebt planifikonim t\u00eb transferonim ngarkes\u00ebn n\u00eb rast t\u00eb d\u00ebshtimit t\u00eb masterit, p\u00ebr shkak t\u00eb nj\u00eb gabimi t\u00eb bezdissh\u00ebm, n\u00eb momentin kritik nuk kishte asnj\u00eb.<\/p>\n

Por pasi b\u00ebm\u00eb jo vet\u00ebm dump t\u00eb DB (restorimi n\u00eb at\u00eb moment zgjaste rreth 5 or\u00eb), por edhe snapshot t\u00eb serverit master, arrit\u00ebm t\u00eb nisnim replik\u00ebn brenda 2 or\u00ebve. Megjithat\u00eb, pas k\u00ebsaj na prit nj\u00eb periudh\u00eb e gjat\u00eb p\u00ebrderisa u p\u00ebrdit\u00ebsua logu i replikimit (sepse procesi zhvillohet n\u00eb mod t\u00eb vet\u00ebm-fibrave, por kjo \u00ebsht\u00eb nj\u00eb histori krejt tjet\u00ebr).<\/p>\n

Dalja:<\/strong> Pas nj\u00eb incidenti t\u00eb till\u00eb, b\u00ebri t\u00eb qart\u00eb se duhej t\u00eb hiqnim dor\u00eb nga praktika e kufizimit t\u00eb shkrimit p\u00ebr p\u00ebrdoruesit dhe t\u00eb shpallnim serverin t\u00eb gjith\u00eb si readonly. Me k\u00ebt\u00eb qasje, nuk mund t\u00eb dyshojm\u00eb se replikat do t\u00eb jen\u00eb t\u00eb dost\u0119pne n\u00eb momentet kritik\u00eb.<\/p><\/blockquote>\n

<\/p>\n

Optimizimi edhe i nj\u00eb k\u00ebrkese t\u00eb r\u00ebnd\u00eb mund t\u00eb \"rikthej\u00eb n\u00eb jet\u00eb\" DB-n\u00eb.<\/h3>\n

\nEdhe pse ne p\u00ebrdit\u00ebsojm\u00eb vazhdimisht katalogun n\u00eb faqen ton\u00eb, k\u00ebrkesat q\u00eb kemi d\u00ebrguar n\u00eb server\u00ebt Slave kishin nj\u00eb vones\u00eb t\u00eb vog\u00ebl nga Master. Koha q\u00eb na duhet p\u00ebr t\u00eb zbuluar dhe zgjidhur problemin e \"slave-ve q\u00eb papritur dol\u00ebn nga gara\" ishte m\u00eb e madhe se \"bariera psikologjike\" (n\u00eb k\u00ebt\u00eb koh\u00eb mund t\u00eb ndodhte p\u00ebrdit\u00ebsimi i \u00e7mimeve, dhe klient\u00ebt do t\u00eb shikonin t\u00eb dh\u00ebna t\u00eb prapambetura), dhe ishim t\u00eb detyruar t\u00eb kalonim t\u00eb gjitha k\u00ebrkesat n\u00eb serverin kryesor t\u00eb DB. Si rezultat, faqja funksiononte ngadal\u00eb... por t\u00eb pakt\u00ebn funksiononte. Dhe nd\u00ebrsa Slave po rikuperohej, nuk na mbetej gj\u00eb tjet\u00ebr ve\u00e7se optimizimi.\u00a0<\/p>\n

Nd\u00ebrsa server\u00ebt Slave po rikuperoheshin, minutat kalonin ngadal\u00eb, Master mbetej i ngarkuar, dhe ne vendos\u00ebm t\u00eb fokusohemi n\u00eb optimizimin e detyrave aktive sipas \"Rregullit t\u00eb Pareto\": zgjodh\u00ebm K\u00cbRKESAT TOP q\u00eb jepnin pjes\u00ebn m\u00eb t\u00eb madhe t\u00eb ngarkes\u00ebs dhe filluam tuning-un. Kjo b\u00ebhej direkt \"n\u00eb fluturim\".<\/p>\n

Efekti interesante ishte se MySQL, i ngarkuar deri n\u00eb kufi, reagon edhe ndaj p\u00ebrmir\u00ebsimeve t\u00eb vogla n\u00eb procese. Optimizimi i disa pyetjeve q\u00eb japin vet\u00ebm 5% t\u00eb ngarkes\u00ebs totale tashm\u00eb tregoi nj\u00eb \u00e7lirim t\u00eb konsideruesh\u00ebm t\u00eb CPU. Si rezultat, arrit\u00ebm t\u00eb sigurojm\u00eb nj\u00eb rezerv\u00eb t\u00eb pranueshme burimesh p\u00ebr funksionimin e Master-it me baz\u00ebn e t\u00eb dh\u00ebnave dhe t\u00eb marrim koh\u00ebn e nevojshme p\u00ebr rikuperimin e replika.\u00a0<\/p>\n

Dalja:<\/strong> Madje, nj\u00eb optimizim i vog\u00ebl lejon \"t\u00eb mbijetosh\" n\u00ebn ngarkes\u00eb p\u00ebr disa or\u00eb. Na e arriti pik\u00ebrisht koh\u00ebn e nevojshme p\u00ebr rikuperimin e server\u00ebve me replika. E kaluara, ne do t\u00eb diskutojm\u00eb aspektet teknike t\u00eb optimizimit t\u00eb pyetjeve n\u00eb nj\u00eb nga postimet tona t\u00eb ardhshme. Pra, regjistrohuni n\u00eb blogun ton\u00eb, n\u00ebse kjo mund t'ju jet\u00eb e dobishme.<\/p><\/blockquote>\n

<\/p>\n

Organizoni monitorimin e funksionimit t\u00eb sh\u00ebrbimeve partnere.<\/h3>\n

\nNe merremi me p\u00ebrpunimin e porosive nga klient\u00ebt, prandaj sh\u00ebrbimet tona jan\u00eb n\u00eb vazhdim\u00ebsi n\u00eb bashk\u00ebpunim me API t\u00eb jashtme \u2014 k\u00ebto jan\u00eb porte p\u00ebr d\u00ebrgimin e SMS-ve, platforma pagesash, sisteme rruge, geokoder, sh\u00ebrbimi i FNS dhe shum\u00eb sisteme t\u00eb tjera. Dhe kur ngarkesa filloi t\u00eb rritet me shpejt\u00ebsi, filluam t\u00eb p\u00ebrballemi me kufizimet e API-ve t\u00eb sh\u00ebrbimeve partnere, p\u00ebr t\u00eb cilat nuk kishim menduar kurr\u00eb m\u00eb par\u00eb.<\/p>\n

Nj\u00eb tejkalim i papritur i kuotave t\u00eb sh\u00ebrbimeve partnere mund t\u00eb \u00e7oj\u00eb n\u00eb shp\u00ebrthime n\u00eb sh\u00ebrbimin tuaj. Shum\u00eb API bllokojn\u00eb klient\u00ebt q\u00eb tejkalojn\u00eb limitet, dhe n\u00eb disa raste, nj\u00eb num\u00ebr i tep\u00ebrt k\u00ebrkesash mund t\u00eb mbingarkoj\u00eb prodhimin e partnerit.\u00a0<\/p>\n

P\u00ebr shembull, gjat\u00eb rritjes s\u00eb numrit t\u00eb d\u00ebrgesave, sh\u00ebrbimet p\u00ebrkat\u00ebse nuk ishin n\u00eb gjendje t\u00eb menaxhonin detyrat e shp\u00ebrndarjes dhe p\u00ebrcaktimin e rrug\u00ebve. Si rezultat, b\u00ebhej e qart\u00eb se porosit\u00eb ishin b\u00ebr\u00eb, por sh\u00ebrbimi q\u00eb krijonte rrug\u00ebn nuk funksiononte. Duhet th\u00ebn\u00eb se logjist\u00ebt tan\u00eb b\u00ebn\u00eb pothuajse t\u00eb pamundur\u00ebn n\u00eb k\u00ebto kushte, dhe bashk\u00ebpunimi i qart\u00eb i ekipit ndihmoi n\u00eb kompensimin e d\u00ebshtimeve p\u00ebrkohshme t\u00eb sh\u00ebrbimeve. Por nj\u00eb volum t\u00eb till\u00eb porosish nuk \u00ebsht\u00eb e realizueshme ta p\u00ebrpunosh n\u00eb m\u00ebnyr\u00eb manuale vazhdimisht, dhe pas nj\u00eb kohe do t\u00eb p\u00ebrballeshim me nj\u00eb boshll\u00ebk t\u00eb papranuesh\u00ebm mes porosive dhe realizimit t\u00eb tyre.\u00a0<\/p>\n

U m\u00ebnyr\u00eb efektive, nj\u00eb seri masash organizative dhe puna e p\u00ebrbashk\u00ebt e ekipit na ndihmuan t\u00eb fitojm\u00eb koh\u00eb, derisa u pajtuam p\u00ebr kushte t\u00eb reja dhe prisnim modernizimin e sh\u00ebrbimeve nga disa partner\u00eb. Ekzistojn\u00eb edhe API t\u00eb tjera q\u00eb ofrojn\u00eb nj\u00eb q\u00ebndrueshm\u00ebri t\u00eb lart\u00eb dhe tarifa t\u00eb arsyeshme p\u00ebr trafik t\u00eb lart\u00eb. P\u00ebr shembull, n\u00eb fillim p\u00ebrdor\u00ebm nj\u00eb API t\u00eb njohur t\u00eb hartave p\u00ebr t\u00eb p\u00ebrcaktuar adres\u00ebn e pik\u00ebs s\u00eb d\u00ebrges\u00ebs. Por pas nj\u00eb muaji mor\u00ebm nj\u00eb fatur\u00eb t\u00eb madhe prej pothuajse 2 milion rubla. Pas k\u00ebsaj, vendos\u00ebm ta z\u00ebvend\u00ebsojm\u00eb at\u00eb me urgjenc\u00eb. Nuk do t\u00eb merrem me reklamim, por them se shpenzimet tona u reduktuan ndjesh\u00ebm.
\n\"Si<\/p>\n

Dalja: <\/strong>\u00cbsht\u00eb thelb\u00ebsore t\u00eb monitoroni kushtet e pun\u00ebs s\u00eb t\u00eb gjith\u00eb sh\u00ebrbimeve partnere dhe t'i keni ato n\u00eb mendje. Edhe n\u00ebse sot duket se ato jan\u00eb \"me nj\u00eb rezerv\u00eb t\u00eb madhe\", kjo nuk do t\u00eb thot\u00eb se nes\u00ebr ato nuk do t\u00eb b\u00ebhen nj\u00eb penges\u00eb p\u00ebr rritje. Dhe, sigurisht, \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb merrni p\u00ebrsip\u00ebr kushte financiare p\u00ebr k\u00ebrkesat e rritura p\u00ebr sh\u00ebrbimin paraprakisht.\u00a0<\/p><\/blockquote>\n

<\/p>\n

Ndonj\u00ebher\u00eb duket se \"duhet m\u00eb shum\u00eb ar<\/a><\/noindex>\" (c) nuk ndihmon<\/h3>\n

\nJemi t\u00eb zakonsh\u00ebm me \u00abng\u00ebr\u00e7et\u00bb n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave kryesore ose n\u00eb server\u00ebt e aplikacioneve, por gjat\u00eb skalimit, problemi mund t\u00eb shfaqet aty ku nuk e prisnim. P\u00ebr k\u00ebrkimin n\u00eb tekst t\u00eb plot\u00eb n\u00eb faqen ton\u00eb, ne p\u00ebrdorim motorin Apache Solr. Me rritjen e ngarkes\u00ebs, ne v\u00ebrejt\u00ebm nj\u00eb r\u00ebnie t\u00eb koh\u00ebs s\u00eb p\u00ebrgjigjes, dhe ngarkesa e procesorit t\u00eb serverit arriti deri n\u00eb 100%. \u00c7far\u00eb mund t\u00eb jet\u00eb m\u00eb e leht\u00eb \u2014 do t'i japim kontejnerit me Solr m\u00eb shum\u00eb burime.<\/p>\n

N\u00eb vend t\u00eb rritjes s\u00eb pritur t\u00eb performanc\u00ebs, serveri thjesht \u00abvdiq\u00bb. Ai menj\u00ebher\u00eb u ngarkua n\u00eb 100% dhe dha p\u00ebrgjigje edhe m\u00eb ngadal\u00eb. Fillimisht kishim 2 b\u00ebrtham\u00eb dhe 2 GB RAM. Ne vendos\u00ebm t\u00eb b\u00ebnim at\u00eb q\u00eb zakonisht ndihmon \u2014 i dham\u00eb serverit 8 b\u00ebrthama dhe 32 GB. \u00cbsht\u00eb b\u00ebr\u00eb shum\u00eb m\u00eb keq (se si dhe pse \u2014 do ta p\u00ebrshkruajm\u00eb n\u00eb nj\u00eb postim t\u00eb ve\u00e7ant\u00eb).\u00a0<\/p>\n

Gjat\u00eb disa dit\u00ebve ne e kuptuam n\u00eb thell\u00ebsi k\u00ebt\u00eb \u00e7\u00ebshtje dhe arrit\u00ebm performanc\u00ebn optimale me 8 b\u00ebrthama dhe 32 GB RAM. Kjo konfigurim lejon q\u00eb sot t\u00eb vazhdojm\u00eb t\u00eb rrisim ngarkes\u00ebn, q\u00eb \u00ebsht\u00eb shum\u00eb e r\u00ebnd\u00ebsishme, sepse rritja ndodh jo vet\u00ebm me klient\u00ebt, por edhe me numrin e dyqaneve t\u00eb lidhura \u2014 brenda 2 muajve numri i tyre \u00ebsht\u00eb dyfishuar.\u00a0<\/p>\n

Dalja: <\/strong>Metodat standarde t\u00eb tipit \"shto m\u00eb shum\u00eb harduer\" nuk funksionojn\u00eb gjithmon\u00eb. Prandaj, kur zmadhojm\u00eb \u00e7do sh\u00ebrbim, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptojm\u00eb mir\u00eb se si p\u00ebrdor burimet dhe t\u00eb testojm\u00eb paraprakisht performanc\u00ebn e tij n\u00eb kushte t\u00eb reja.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 \u00e7el\u00ebsi p\u00ebr nj\u00eb zmadhojm\u00eb horizontale t\u00eb thjesht\u00eb<\/h3>\n

\nN\u00eb p\u00ebrgjith\u00ebsi, ekipi yn\u00eb ndjek nj\u00eb qasje t\u00eb njohur: sh\u00ebrbimet nuk duhet t\u00eb ken\u00eb nj\u00eb gjendje t\u00eb brendshme (stateless) dhe duhet t\u00eb jen\u00eb t\u00eb pavarura nga mjedisi i ekzekutimit. Kjo na ka lejuar t\u00eb p\u00ebrballojm\u00eb rritjen e ngarkes\u00ebs p\u00ebrmes zmadhojve horizontale t\u00eb thjeshta. Por p\u00ebr ne kishte nj\u00eb sh\u00ebrbim p\u00ebrjashtimi \u2013 menaxhuesi i detyrave t\u00eb gjata n\u00eb sfond. Ai merrej me d\u00ebrgimin e email-eve dhe sms-ve, p\u00ebrpunimin e ngjarjeve, gjenerimin e feed-eve, importimin e \u00e7mimeve dhe stoqeve, p\u00ebrpunimin e imazheve. Raste do t\u00eb ndodhte q\u00eb ai varej nga ruajtja e skedar\u00ebve lokale dhe ishte n\u00eb nj\u00eb eksemplar t\u00eb vet\u00ebm.\u00a0<\/p>\n

Kur rritet numri i detyrave n\u00eb radh\u00ebn e p\u00ebrpunuesit (\u00e7ka \u00ebsht\u00eb natyrsh\u00ebm ndodhur me rritjen e numrit t\u00eb porosive), performanca e hostit, n\u00eb t\u00eb cilin ishin vendosur p\u00ebrpunuesi dhe ruajtja e skedar\u00ebve, u b\u00eb faktori kufizues. Si rezultat, u ndal nj\u00ebher\u00eb p\u00ebrdit\u00ebsimi i asortimentit dhe \u00e7mimeve, d\u00ebrgimi i njoftimeve p\u00ebr p\u00ebrdoruesit dhe shum\u00eb funksione kritike t\u00eb tjera, t\u00eb bllokuara n\u00eb radh\u00eb. Ekipi Ops migroi menj\u00ebher\u00eb ruajtjen e skedar\u00ebve n\u00eb nj\u00eb sistem t\u00eb ngjash\u00ebm me S3, dhe kjo na lejoi t\u00eb ngrejm\u00eb disa makina t\u00eb fuqishme p\u00ebr t\u00eb skalituar p\u00ebrpunuesin e detyrave n\u00eb sfond.<\/p>\n

Dalja: <\/strong>Rregulli Stateless duhet t\u00eb respektohet p\u00ebr t\u00eb gjith\u00eb komponent\u00ebt pa p\u00ebrjashtim, edhe n\u00ebse duket \"se k\u00ebtu sigurisht nuk do t\u00eb hasim n\u00eb ndonj\u00eb kufizim\". M\u00eb mir\u00eb t\u00eb investoni pak koh\u00eb n\u00eb organizimin e duhur t\u00eb pun\u00ebs s\u00eb t\u00eb gjitha sistemeve sesa m\u00eb von\u00eb t\u00eb shkruani p\u00ebrs\u00ebri kodin dhe t\u00eb rregulloni sh\u00ebrbimin q\u00eb po p\u00ebrballet me ngarkes\u00eb.<\/p><\/blockquote>\n

<\/p>\n

7 principe p\u00ebr rritje intensive<\/h2>\n

\nMegjith\u00ebse disponojm\u00eb kapacitete shtes\u00eb, gjat\u00eb rritjes kemi hasur n\u00eb disa gabime. Gjat\u00eb k\u00ebsaj periudhe, numri i porosive \u00ebsht\u00eb rritur m\u00eb shum\u00eb se 4 her\u00eb. Tani ne tashm\u00eb dor\u00ebzojm\u00eb m\u00eb shum\u00eb se 17,000 porosi n\u00eb dit\u00eb n\u00eb 62 qytete dhe planifikojm\u00eb t\u00eb zgjedhim edhe m\u00eb shum\u00eb gjeografi - n\u00eb gjysm\u00ebn e par\u00eb t\u00eb vitit 2020 pritet t\u00eb fillojm\u00eb sh\u00ebrbimin n\u00eb t\u00eb gjith\u00eb Rusin\u00eb. P\u00ebr t\u00eb menaxhuar ngarkes\u00ebn n\u00eb rritje, duke marr parasysh gabimet e kaluara, ne kemi formuluar 7 parime kryesore p\u00ebr t\u00eb punuar n\u00eb kushte rritjeje t\u00eb vazhdueshme:<\/p>\n

    \n
  1. Menaxhimi i incidenteve<\/strong>. Ne krijuam nj\u00eb board n\u00eb Jira, ku \u00e7do incident pasqyrohet n\u00eb form\u00ebn e nj\u00eb tiketi. Kjo ndihmon p\u00ebr prioritizimin dhe realizimin e detyrave t\u00eb lidhura me incidentin. Sepse n\u00eb thelb, nuk \u00ebsht\u00eb e tmerrshme t\u00eb gabosh - e tmerrshme \u00ebsht\u00eb t\u00eb gabosh dy her\u00eb p\u00ebr t\u00eb nj\u00ebjtin arsye. P\u00ebr rastet kur incidentet p\u00ebrs\u00ebriten para se t\u00eb mund t\u00eb rregullojm\u00eb shkakun, duhet t\u00eb kemi nj\u00eb udh\u00ebzim p\u00ebr veprim, sepse gjat\u00eb ngarkes\u00ebs s\u00eb madhe \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb reagosh menj\u00ebher\u00eb.<\/li>\n
  2. Monitorimi <\/strong>\u00ebsht\u00eb e nevojshme p\u00ebr t\u00eb gjitha elementet e infrastruktur\u00ebs pa p\u00ebrjashtim. Pik\u00ebrisht fal\u00eb tij ne mund\u00ebm t\u00eb parashikojm\u00eb rritjen e ngarkes\u00ebs dhe t\u00eb zgjedhim sakt\u00eb \"kokat e shisheve\" p\u00ebr prioritizimin e zgjidhjes. Me siguri, n\u00eb raste ngarkese t\u00eb lart\u00eb do t\u00eb d\u00ebshtoj\u00eb ose do t\u00eb shkaktoj\u00eb ngadal\u00ebsim gjith\u00e7ka q\u00eb nuk e kishe menduar. Prandaj, aler\u00ebt e rinj \u00ebsht\u00eb m\u00eb mir\u00eb t'i krijosh menj\u00ebher\u00eb pas ndodhis\u00eb s\u00eb par\u00eb, p\u00ebr t'i monitoruar dhe parashikuar ato.<\/li>\n
  3. Aler\u00ebt e duhur<\/strong> jan\u00eb thjesht t\u00eb nevojsh\u00ebm kur ka nj\u00eb rritje t\u00eb papritur t\u00eb ngarkes\u00ebs. S\u00eb pari, ata duhet t\u00eb raportojn\u00eb sakt\u00ebsisht se \u00e7far\u00eb ka d\u00ebshtuar. S\u00eb dyti, nuk duhet t\u00eb ket\u00eb shum\u00eb aler\u00eb, sepse nj\u00eb num\u00ebr i madh aleresh jo-kritike \u00e7on n\u00eb injorimin e t\u00eb gjitha njoftimeve n\u00eb p\u00ebrgjith\u00ebsi.<\/li>\n
  4. Aplikacionet duhet t\u00eb jen\u00eb stateless. <\/strong>Ne e kemi konfirmuar se p\u00ebr k\u00ebt\u00eb rregull nuk duhet t\u00eb ket\u00eb p\u00ebrjashtime. Nevojitet nj\u00eb pavar\u00ebsi e plot\u00eb nga mjedisi i ekzekutimit. P\u00ebr k\u00ebt\u00eb, mund t\u00eb ruani t\u00eb dh\u00ebnat e ndara n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave ose, p\u00ebr shembull, drejtp\u00ebrdrejt n\u00eb S3. Dhe akoma m\u00eb mir\u00eb \u00ebsht\u00eb t\u00eb ndjek\u00ebsh rregullat. https:\/\/12factor.net<\/a><\/noindex>. Gjat\u00eb rritjes s\u00eb shpejt\u00eb, optimizimi i kodit \u00ebsht\u00eb i pamundur, dhe do t'ju duhet t\u00eb p\u00ebrballoni ngarkes\u00ebn duke rritur thjesht burimet llogarit\u00ebse dhe duke p\u00ebrdorur skalimin horizontal.<\/li>\n
  5. Kuotat dhe performanca e sh\u00ebrbimeve t\u00eb jashtme. <\/strong>Kur rritja \u00ebsht\u00eb e shpejt\u00eb, problemi mund t\u00eb ndodh\u00eb jo vet\u00ebm n\u00eb infrastruktur\u00ebn tuaj, por edhe n\u00eb sh\u00ebrbimin e jasht\u00ebm. E mjerueshme \u00ebsht\u00eb kur ndodh kjo jo p\u00ebr shkak t\u00eb nj\u00eb defekti, por p\u00ebr shkak t\u00eb arritjes s\u00eb kuotave ose kufijve. Prandaj, sh\u00ebrbimet e jashtme duhet t\u00eb ken\u00eb nj\u00eb kapacitet rritjeje t\u00eb nj\u00ebjt\u00eb si ju.\u00a0<\/li>\n
  6. Ndani proceset dhe radh\u00ebt. <\/strong>Kjo ndihmon shum\u00eb kur nj\u00eb nga porta p\u00ebrjeton ngushtic\u00eb. Nuk do t\u00eb p\u00ebrballeshim me vonesa n\u00eb transferimin e t\u00eb dh\u00ebnave n\u00ebse radh\u00ebt e mbushura p\u00ebr d\u00ebrgimin e SMS-ve nuk do t\u00eb pengonin shk\u00ebmbimin e njoftimeve mes sistemeve informacioni. Po ashtu, do t\u00eb ishte m\u00eb e leht\u00eb t\u00eb rriteshin numri i pun\u00ebtor\u00ebve n\u00ebse ata do t\u00eb punonin ndaras.<\/li>\n
  7. Realitetet financiare.<\/strong> Kur ka nj\u00eb rritje t\u00eb shpejt\u00eb t\u00eb fluksit t\u00eb t\u00eb dh\u00ebnave, nuk ka koh\u00eb p\u00ebr t\u00eb menduar p\u00ebr tarifa dhe abonime. Por, duhet t'i mbani mend ato, ve\u00e7an\u00ebrisht n\u00ebse jeni nj\u00eb kompani e vog\u00ebl. Nj\u00eb fatur\u00eb e madhe mund t\u00eb vij\u00eb nga \u00e7do pronar API, si dhe nga ofruesi juaj i hostimit. Prandaj, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb lexoni me kujdes kontratat.<\/li>\n<\/ol>\n

    <\/p>\n

    P\u00ebrfundimi<\/h2>\n

    \nMe ndonj\u00eb humbje, por e kaluam k\u00ebt\u00eb faz\u00eb, dhe sot mundohemi t\u00eb mbajm\u00eb t\u00eb gjitha parimet e gjetura, p\u00ebrderisa \u00e7do makin\u00eb ka mund\u00ebsin\u00eb p\u00ebr t\u00eb rritur performanc\u00ebn e saj 4 her\u00eb, p\u00ebr t\u00eb p\u00ebrballuar ndonj\u00eb papritur.\u00a0<\/p>\n

    N\u00eb postimet e ardhshme ne do t\u00eb ndajm\u00eb p\u00ebrvoj\u00ebn ton\u00eb n\u00eb hetimin e r\u00ebnies s\u00eb performanc\u00ebs n\u00eb Apache Solr, si dhe do t\u00eb flasim p\u00ebr optimizimin e k\u00ebrkesave dhe si bashk\u00ebpunimi me FNS ndihmon kompanin\u00eb p\u00ebr t\u00eb kursyer para. Abonohuni n\u00eb blogun ton\u00eb p\u00ebr t\u00eb mos humbur asgj\u00eb dhe tregoni n\u00eb komentet tuaj n\u00ebse keni hasur n\u00eb probleme t\u00eb ngjashme gjat\u00eb rritjes s\u00eb trafikut.<\/p>\n

    \"Si<\/p>\n

    Vet\u00ebm p\u00ebrdoruesit e regjistruar mund t\u00eb marrin pjes\u00eb n\u00eb anket\u00eb. Hyni<\/a><\/noindex>, ju lutemi.<\/p>\n

    A keni p\u00ebrjetuar ngadal\u00ebsim\/r\u00ebnien e sh\u00ebrbimit p\u00ebr shkak t\u00eb nj\u00eb rritjeje t\u00eb papritur t\u00eb ngarkes\u00ebs p\u00ebr:<\/h2>\n