{"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 rritjen e menj\u00ebhershme x10 t\u00eb ngarkes\u00ebs gjat\u00eb pun\u00ebs n\u00eb distanc\u00eb dhe \u00e7far\u00eb p\u00ebrfundimesh nxor\u00ebm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00ebrsh\u00ebndetje, Habr! Gjat\u00eb disa muajve t\u00eb fundit, kemi p\u00ebrjetuar nj\u00eb situat\u00eb shum\u00eb interesante, dhe do t\u00eb doja t\u00eb ndaja historin\u00eb ton\u00eb t\u00eb zgjerimit t\u00eb infrastruktur\u00ebs. Gjat\u00eb k\u00ebsaj kohe, SberMarket \u00ebsht\u00eb rritur kat\u00ebrfish n\u00eb porosi dhe ka lansuar sh\u00ebrbimin n\u00eb 17 qytete t\u00eb reja. Rritja eksplozive e k\u00ebrkes\u00ebs p\u00ebr dor\u00ebzim t\u00eb produkteve k\u00ebrkoi nga ne zgjerimin e infrastruktur\u00ebs. Rreth konkluzioneve m\u00eb interesante dhe t\u00eb dobishme lexoni posht\u00eb.<\/p>\n

\"Si
\n<\/a><\/noindex>
\nM\u00eb quajn\u00eb Dima Bobyl\u00ebv, un\u00eb jam drejtor teknik i SberMarket. Duke qen\u00eb se ky \u00ebsht\u00eb posti i par\u00eb n\u00eb blogun ton\u00eb, do t\u00eb them disa fjal\u00eb p\u00ebr veten dhe p\u00ebr kompanin\u00eb. N\u00eb vjesht\u00ebn e kaluar, kam marr\u00eb pjes\u00eb n\u00eb konkursin e lider\u00ebve t\u00eb rinj t\u00eb Runet. P\u00ebr k\u00ebt\u00eb contest un\u00eb kam shkruar nj\u00eb histori t\u00eb vog\u00ebl<\/a><\/noindex> rreth m\u00ebnyr\u00ebs se si ne n\u00eb SberMarket e shohim kultur\u00ebn e brendshme dhe qasjen ndaj zhvillimit t\u00eb sh\u00ebrbimit. Edhe pse nuk arrita t\u00eb fitoj n\u00eb konkurs, p\u00ebrkundrazi, kam formuluar p\u00ebr vete parimet themelore t\u00eb zhvillimit t\u00eb ekosistemit IT. <\/p>\n

Kur menaxhon nj\u00eb ekip, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptosh dhe t\u00eb gjesh nj\u00eb balanc\u00eb mes 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 rritjen e vazhdueshme t\u00eb volumit dhe ritmit t\u00eb zhvillimit. Megjithat\u00eb, ne i japim zhvilluesve mjaft koh\u00eb p\u00ebr analiz\u00ebn paraprake dhe p\u00ebr nj\u00eb kod t\u00eb cil\u00ebsis\u00eb s\u00eb lart\u00eb. Qasja e formuar ndihmon jo vet\u00ebm n\u00eb krijimin e nj\u00eb produkti funksional, por gjithashtu n\u00eb zgjerimin dhe zhvillimin e tij t\u00eb m\u00ebtejsh\u00ebm. Si rezultat i k\u00ebsaj rritjeje, SberMarket tashm\u00eb \u00ebsht\u00eb b\u00ebr\u00eb lider nd\u00ebr sh\u00ebrbimet e dor\u00ebzimit t\u00eb produkteve: ne dor\u00ebzojm\u00eb rreth 18 mij\u00eb porosi \u00e7do dit\u00eb, ndon\u00ebse n\u00eb fillim t\u00eb shkurtit ishin rreth 3500.<\/p>\n

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

Por t\u00eb kaluar te detajet. Gjat\u00eb disa muajve t\u00eb fundit, ne kemi punuar aktivisht n\u00eb zgjerimin e infrastruktur\u00ebs s\u00eb kompanis\u00eb son\u00eb. Ky nevoj\u00eb u justifikua nga faktor\u00eb t\u00eb jasht\u00ebm dhe t\u00eb brendsh\u00ebm. N\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb me rritjen e baz\u00ebs s\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, ne u p\u00ebrgatit\u00ebm, rezervuam infrastruktur\u00ebn kryesore dhe planifikuam mund\u00ebsin\u00eb e zgjerimit vertikal dhe horizontal t\u00eb t\u00eb gjitha makinave virtuale t\u00eb vendosura n\u00eb \u043e\u0431\u043b\u0430kun e Yandex. Megjithat\u00eb, praktika tregoi: \"Gjith\u00e7ka 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 ndodhen p\u00ebr k\u00ebto jav\u00eb. Shpresoj q\u00eb p\u00ebrvoja jon\u00eb t\u00eb jet\u00eb e dobishme p\u00ebr ju.<\/p>\n

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

\nEdhe p\u00ebrpara fillimit t\u00eb pandemis\u00eb, u p\u00ebrball\u00ebm me nj\u00eb rritje t\u00eb numrit t\u00eb k\u00ebrkesave n\u00eb serverat tan\u00eb backend. Tendenca p\u00ebr t\u00eb porositur produkte me dor\u00ebzim n\u00eb sht\u00ebpi filloi t\u00eb merrte hov, dhe me futjen e masave t\u00eb para t\u00eb vetizolimit p\u00ebr shkak t\u00eb COVID-19, ngarkesa po rritej dramatikisht para syve tan\u00eb gjat\u00eb gjith\u00eb dit\u00ebs. U shfaq nevoja p\u00ebr t\u00eb shkarkuar me urgjenc\u00eb serverat master t\u00eb baz\u00ebs kryesore t\u00eb t\u00eb dh\u00ebnave dhe p\u00ebr t\u00eb transferuar disa k\u00ebrkesa p\u00ebr lexim n\u00eb serverat-replik\u00eb (slave).<\/p>\n

Ne u p\u00ebrgatit\u00ebm paraprakisht p\u00ebr k\u00ebt\u00eb hap, dhe p\u00ebr k\u00ebt\u00eb manov\u00ebr tashm\u00eb ishin aktivizuar 2 servera slave. Ata kryesisht punonin me detyra batch p\u00ebr gjenerimin e feed-eve informative p\u00ebr shk\u00ebmbimin e t\u00eb dh\u00ebnave me partner\u00ebt. K\u00ebto procese krijonin nj\u00eb ngarkes\u00eb t\u00eb tep\u00ebrt dhe ishin krejt\u00ebsisht t\u00eb arsyeshme t\u00eb hiqeshin \"jasht\u00eb skanave\" disa muaj m\u00eb par\u00eb.\u00a0<\/p>\n

Duke qen\u00eb se replikimi ndodhte n\u00eb Slave, ne ndoq\u00ebm konceptin q\u00eb aplikacionet mund t\u00eb punojn\u00eb me to vet\u00ebm n\u00eb m\u00ebnyr\u00eb read only. Plani i Rim\u00ebk\u00ebmbjes nga Fatkeq\u00ebsit\u00eb parashikonte q\u00eb n\u00eb rast katastrofe, ne mund t\u00eb montonim thjesht Slave n\u00eb vend t\u00eb Master dhe t\u00eb kalonim t\u00eb gjitha k\u00ebrkesat p\u00ebr shkrim dhe lexim n\u00eb Slave. Megjithat\u00eb, ne gjithashtu d\u00ebshironim t\u00eb p\u00ebrdornim replikat p\u00ebr nevojat e departamentit t\u00eb analizave, k\u00ebshtu q\u00eb serverat nuk u transferuan plot\u00ebsisht n\u00eb statusin read only, dhe n\u00eb \u00e7do host kishte grupin e tij t\u00eb p\u00ebrdoruesve, dhe disa kishin t\u00eb drejta shkrimi p\u00ebr t\u00eb ruajtur rezultatet nd\u00ebrmjet\u00ebse t\u00eb llogaritjeve.<\/p>\n

Der nivel t\u00eb caktuar ngarkese na mjaftonte nj\u00eb master p\u00ebr t\u00eb shkruar dhe lexuar gjat\u00eb p\u00ebrpunimit t\u00eb k\u00ebrkesave http. N\u00eb mesin e marsit, pik\u00ebrisht kur Sbermarket vendosi t\u00eb kaloj\u00eb n\u00eb pun\u00eb t\u00eb larg\u00ebt, filluam nj\u00eb rritje t\u00eb ndjeshme t\u00eb RPS. Po aq shum\u00eb klient\u00eb tan\u00eb kaluan n\u00eb vet\u00ebizolim ose pun\u00eb nga sht\u00ebpia, gj\u00eb q\u00eb ndikoi n\u00eb treguesit e ngarkes\u00ebs.<\/p>\n

Performanca e \u00abmaster\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 transparenc\u00ebn e k\u00ebrkesave p\u00ebr shkruar n\u00eb master dhe p\u00ebr lexim n\u00eb slave, p\u00ebrdor\u00ebm gemin ruby \u00abOctopus<\/a><\/noindex>\u00bb. Krijuam nj\u00eb p\u00ebrdorues t\u00eb ve\u00e7ant\u00eb me postfixin _readonly pa t\u00eb drejta p\u00ebr shkruar. Por p\u00ebr shkak t\u00eb nj\u00eb gabimi n\u00eb konfigurimin e nj\u00ebrit nga hostet, disa k\u00ebrkesa p\u00ebr shkruar u d\u00ebrguan n\u00eb serverin slave me emrin e p\u00ebrdoruesit q\u00eb kishte t\u00eb drejtat p\u00ebrkat\u00ebse.<\/p>\n

Problemi nuk doli n\u00eb pah menj\u00ebher\u00eb, sepse ngarkesa e rritur shkaktoi nj\u00eb vones\u00eb tek slavet. Inkonistencat e t\u00eb dh\u00ebnave u zbuluan n\u00eb m\u00ebngjes, kur pas importeve t\u00eb nat\u00ebs, slavet nuk e \u00abarrit\u00ebn\u00bb masterin. Ne e arsyetuam k\u00ebt\u00eb me ngarkes\u00ebn e lart\u00eb n\u00eb vet\u00eb sh\u00ebrbimin dhe importin e lidhur me hapjen e dyqaneve t\u00eb reja. Por ofrimi i t\u00eb dh\u00ebnave me nj\u00eb vones\u00eb disa or\u00ebshe ishte e papranueshme, dhe ne kaluam proceset n\u00eb slave-n\u00eb e dyt\u00eb analitike, sepse ai kishte m\u00ebo<\/strong>shum\u00eb burime dhe nuk ishte ngarkuar me k\u00ebrkesa leximi (\u00e7far\u00eb e shpjeguam p\u00ebr veten ton\u00eb si munges\u00eb t\u00eb vones\u00ebs n\u00eb replikim).<\/p>\n

Kur arrit\u00ebm t\u00eb zgjidhnim arsyet e \u00abshk\u00ebputjes\u00bb s\u00eb slave-it kryesor, slave analitik tashm\u00eb kishte dal\u00eb jasht\u00eb funksioni p\u00ebr t\u00eb nj\u00ebjt\u00ebn arsye. Pavar\u00ebsisht nga pranimi i dy server\u00ebve shtes\u00eb, n\u00eb t\u00eb cil\u00ebt planifikuam 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 pad\u00ebshiruar rezultoi se n\u00eb momentet kritike 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 gjithashtu snapshot t\u00eb serverit master, arrit\u00ebm t\u00eb nisim replik\u00ebn brenda 2 or\u00ebve. Megjithat\u00eb, pas k\u00ebsaj na priste kalimi i logut t\u00eb replikimit p\u00ebr nj\u00eb periudh\u00eb t\u00eb gjat\u00eb (pasi processi zhvillohet n\u00eb modin nj\u00ebth\u00ebmb\u00ebsh, por kjo \u00ebsht\u00eb nj\u00eb histori tjet\u00ebr krejt\u00ebsisht).<\/p>\n

P\u00ebrfundimi:<\/strong> Pas nj\u00eb incident t\u00eb till\u00eb, u b\u00eb e qart\u00eb se duhej hequr dor\u00eb nga praktika e kufizimit t\u00eb regjistrimit p\u00ebr p\u00ebrdoruesit dhe t\u00eb shpallej n\u00eb m\u00ebnyr\u00eb readonly e gjith\u00eb serveri. Me nj\u00eb qasje t\u00eb till\u00eb, mund t\u00eb mos dyshohet se replikat do t\u00eb ishin t\u00eb disponueshme n\u00eb nj\u00eb moment kritik.<\/p><\/blockquote>\n

<\/p>\n

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

\nMegjith\u00ebse ne vazhdimisht p\u00ebrdit\u00ebsojm\u00eb katalogun n\u00eb sit, k\u00ebrkesat q\u00eb ne i d\u00ebrgonim n\u00eb server\u00ebt Slave toleronin nj\u00eb vones\u00eb t\u00eb vog\u00ebl nga Master. Koha p\u00ebr t\u00eb zbuluar dhe eliminuar problemin e \"slave-ve q\u00eb papritmas dol\u00ebn nga gara\" ishte m\u00eb e gjat\u00eb se \"bariera psiko-kologjike\" (n\u00eb at\u00eb koh\u00eb mund t\u00eb kishte ndodhur nj\u00eb p\u00ebrdit\u00ebsim \u00e7mimesh dhe klient\u00ebt do t\u00eb shihnin t\u00eb dh\u00ebna t\u00eb skaduara), dhe ne u detyruam t\u00eb kalonim t\u00eb gjitha k\u00ebrkesat n\u00eb serverin kryesor t\u00eb DB-s\u00eb. Si rezultat, siti punoi ngadal\u00eb... por s\u00eb paku funksionoi. Dhe derisa Slave po rikuperohej, nuk na mbetej asgj\u00eb tjet\u00ebr p\u00ebrve\u00e7 optimizimit.\u00a0<\/p>\n

Nd\u00ebrsa server\u00ebt Slave po rikuperoheshin, minutat kalonin ngadal\u00eb, Master mbetej i ngarkuar, dhe ne hodh\u00ebm t\u00eb gjitha forcat n\u00eb optimizimin e detyrave aktive sipas \"Rregullit t\u00eb Paretos\": zgjodh\u00ebm k\u00ebrkesat TOP q\u00eb jepnin pjes\u00ebn m\u00eb t\u00eb madhe t\u00eb ngarkes\u00ebs dhe filluam tuning. Kjo b\u00ebhej n\u00eb m\u00ebnyr\u00eb t\u00eb drejtp\u00ebrdrejt\u00eb.<\/p>\n

Nj\u00eb efekt interesant ishte se MySQL, e mbushur deri n\u00eb pik\u00ebn kryesore, p\u00ebrgjigjej edhe ndaj p\u00ebrmir\u00ebsimit t\u00eb vog\u00ebl t\u00eb proceseve. Optimizimi i disa k\u00ebrkesave q\u00eb jepnin vet\u00ebm 5% t\u00eb ngarkes\u00ebs totale tregoi tashm\u00eb nj\u00eb ulje t\u00eb dukshme t\u00eb CPU-s\u00eb. Si rezultat, arrit\u00ebm t\u00eb siguronim nj\u00eb rezerv\u00eb t\u00eb pranueshme burimesh p\u00ebr t\u00eb punuar Master me baz\u00ebn e t\u00eb dh\u00ebnave dhe t\u00eb merrnim koh\u00ebn e nevojshme p\u00ebr rikuperimin e replikave.\u00a0<\/p>\n

P\u00ebrfundimi:<\/strong> Edhe nj\u00eb optimizim i vog\u00ebl lejon \"t\u00eb mbijetosh\" gjat\u00eb ngarkes\u00ebs p\u00ebr disa or\u00eb. Na mjaftoi kjo koh\u00eb p\u00ebr rikuperimin e server\u00ebve me replikat. P\u00ebr rrethanat teknike t\u00eb optimizimit t\u00eb k\u00ebrkesave, do ta diskutojm\u00eb n\u00eb nj\u00eb nga postimet e ardhshme. Prandaj, abonohuni n\u00eb blogun ton\u00eb n\u00ebse kjo mund t\u00eb jet\u00eb e dobishme p\u00ebr ju.<\/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, dhe p\u00ebr k\u00ebt\u00eb arsye sh\u00ebrbimet tona vazhdimisht nd\u00ebrveprojn\u00eb me API e jashtme \u2014 k\u00ebto jan\u00eb porta p\u00ebr d\u00ebrgimin e SMS-ve, platformat e pagesave, sistemet e routing-ut, geokoduesi, sh\u00ebrbimi i FNSH-s\u00eb dhe shum\u00eb sisteme t\u00eb tjera. Dhe kur ngarkesa filloi t\u00eb rritej shpejt, filluam t\u00eb hasim kufizimet e API-ve t\u00eb sh\u00ebrbimeve partnere, p\u00ebr t\u00eb cilat nuk kishim menduar 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 ndjekjen e r\u00ebnies s\u00eb sh\u00ebrbimeve tuaja. Shum\u00eb API bllokojn\u00eb klient\u00ebt q\u00eb tejkalojn\u00eb kufijt\u00eb, dhe n\u00eb disa raste, nj\u00eb num\u00ebr i madh k\u00ebrkesash mund t\u00eb ngarkoj\u00eb prodhimin e partnerit.\u00a0<\/p>\n

P\u00ebr shembull, n\u00eb momentin e rritjes s\u00eb numrit t\u00eb d\u00ebrgesave, sh\u00ebrbimet ndihm\u00ebse nuk arrinin t\u00eb p\u00ebrballonin detyrat e tyre p\u00ebr shp\u00ebrndarje dhe p\u00ebrcaktim rrug\u00ebsh. Si rezultat, ndodhte q\u00eb porosit\u00eb ishin b\u00ebr\u00eb, por sh\u00ebrbimi q\u00eb krijonte rrug\u00ebn nuk funksiononte. Duhet t\u00eb them se logjist\u00ebt tan\u00eb b\u00ebn\u00eb at\u00eb q\u00eb dukej pothuajse e pamundur n\u00eb k\u00ebto kushte, dhe nd\u00ebrveprimi i qart\u00eb i ekipit ndihmoi n\u00eb kompensimin e d\u00ebshtimeve t\u00eb p\u00ebrkohshme t\u00eb sh\u00ebrbimeve. Por nj\u00eb volum kaq i madh porosish nuk mund t\u00eb p\u00ebrballohej vazhdimisht me dor\u00eb, dhe pas nj\u00eb koh\u00eb do t\u00eb p\u00ebrballeshim me nj\u00eb nd\u00ebrprerje t\u00eb papranueshme mes porosive dhe ekzekutimeve t\u00eb tyre.\u00a0<\/p>\n

U miratua nj\u00eb s\u00ebr\u00eb masash organizative dhe puna e p\u00ebrbashk\u00ebt e kolektivit ndihmoi t\u00eb fitonin disa koh\u00eb, derisa ne u dakorduam p\u00ebr kushtet e reja dhe prisnim modernizimin e sh\u00ebrbimeve nga disa partner\u00eb. Ekzistojn\u00eb edhe API t\u00eb tjera q\u00eb g\u00ebzojn\u00eb q\u00ebndrushm\u00ebri t\u00eb lart\u00eb dhe tarifa t\u00eb larta n\u00eb rastin e trafikut t\u00eb madh. P\u00ebr shembull, n\u00eb fillim p\u00ebrdorshim nj\u00eb API t\u00eb njohur p\u00ebr hartat p\u00ebr p\u00ebrcaktimin e adres\u00ebs s\u00eb pik\u00ebs s\u00eb d\u00ebrges\u00ebs. Por pas p\u00ebrfundimit t\u00eb muajit, mor\u00ebm nj\u00eb fatur\u00eb t\u00eb madhe prej gati 2 milion rubla. Pas k\u00ebsaj, vendos\u00ebm ta z\u00ebvend\u00ebsonim at\u00eb menj\u00ebher\u00eb. Nuk do t\u00eb merrem me reklamim, por do t\u00eb them se shpenzimet tona u ul\u00ebn ndjesh\u00ebm.
\n\"Si<\/p>\n

P\u00ebrfundimi: <\/strong>Duhet patjet\u00ebr t\u00eb monitoroni kushtet e pun\u00ebs s\u00eb t\u00eb gjitha sh\u00ebrbimeve partnere dhe t'i keni parasysh. Edhe n\u00ebse sot duket se ato kan\u00eb 'rezerva t\u00eb m\u00ebdha', kjo nuk do t\u00eb thot\u00eb se nes\u00ebr ato nuk do t\u00eb b\u00ebhen nj\u00eb penges\u00eb p\u00ebr rritjen. Dhe, sigurisht, \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb arrini marr\u00ebveshje p\u00ebr kushtet financiare t\u00eb rritjes s\u00eb k\u00ebrkesave p\u00ebr sh\u00ebrbimin paraprakisht.\u00a0<\/p><\/blockquote>\n

<\/p>\n

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

\nJemi m\u00ebsuar me \"ng\u00ebr\u00e7et\" n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave kryesore ose n\u00eb serverat e aplikacioneve, por gjat\u00eb shkall\u00ebzimit, problemet mund t\u00eb shfaqen atje ku nuk i prisni. P\u00ebr k\u00ebrkimin me tekst t\u00eb plot\u00eb n\u00eb sit, ne p\u00ebrdorim motorin Apache Solr. Me rritjen e ngarkes\u00ebs, ne v\u00ebshtruam r\u00ebnien e koh\u00ebs s\u00eb p\u00ebrgjigjes, dhe ngarkesa e procesorit t\u00eb serverit arriti tashm\u00eb n\u00eb 100%. \u00c7far\u00eb mund t\u00eb jet\u00eb m\u00eb e thjesht\u00eb \u2014 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 \"vdiq\". Ai menj\u00ebher\u00eb ngarkohej n\u00eb 100% dhe p\u00ebrgjigjej edhe m\u00eb ngadal\u00eb. Fillimisht kishim 2 b\u00ebrthama dhe 2 GB RAM. Vendos\u00ebm t\u00eb b\u00ebjm\u00eb at\u00eb q\u00eb zakonisht ndihmon \u2014 i dham\u00eb serverit 8 b\u00ebrthama dhe 32 GB. T\u00eb gjitha u b\u00ebn\u00eb shum\u00eb m\u00eb keq (si dhe pse, do t\u00eb tregojm\u00eb n\u00eb nj\u00eb postim tjet\u00ebr).\u00a0<\/p>\n

N\u00eb disa dit\u00eb, ne kuptuam holl\u00ebsit\u00eb e k\u00ebsaj \u00e7\u00ebshtjeje dhe arrit\u00ebm performanc\u00ebn optimale me 8 b\u00ebrthama dhe 32 GB. Kjo konfigurim na lejon edhe sot t\u00eb vazhdojm\u00eb t\u00eb rrisim ngarkes\u00ebn, q\u00eb \u00ebsht\u00eb shum\u00eb e r\u00ebnd\u00ebsishme, sepse rritja po ndodh jo vet\u00ebm p\u00ebr klient\u00ebt, por edhe p\u00ebr numrin e dyqaneve t\u00eb lidhura \u2014 brenda 2 muajve, numri i tyre u rrit dyfish.\u00a0<\/p>\n

P\u00ebrfundimi: <\/strong>Metodat standarde si \"shtoni m\u00eb shum\u00eb harduer\" nuk funksionojn\u00eb gjithmon\u00eb. Prandaj, gjat\u00eb shkall\u00ebzimit t\u00eb \u00e7do sh\u00ebrbimi, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptohet mir\u00eb si p\u00ebrdor burimet dhe t\u00eb testohet paraprakisht funksionimi i tij n\u00eb kushte t\u00eb reja.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 \u00e7el\u00ebsi p\u00ebr shkall\u00ebzimin horizontal t\u00eb thjesht\u00eb<\/h3>\n

\nN\u00eb p\u00ebrgjith\u00ebsi, ekipi yn\u00eb ndjek qasjen e 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 ekzekutues. Kjo na lejoi t\u00eb p\u00ebrballonim rritjen e ngarkes\u00ebs p\u00ebrmes shkall\u00ebzimit horizontal t\u00eb thjesht\u00eb. Por kishim nj\u00eb sh\u00ebrbim p\u00ebrjashtim \u2014 p\u00ebrpunuesin e 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 stokut, p\u00ebrpunimin e imazheve. Si\u00e7 ndodhi, ai varej nga ruajtja lokale e skedar\u00ebve dhe ishte n\u00eb nj\u00eb ekzemplar t\u00eb vet\u00ebm.\u00a0<\/p>\n

Kur rritet numri i detyrave n\u00eb radh\u00ebn e p\u00ebrpunuesit (gj\u00eb q\u00eb ndodhi natyrsh\u00ebm me rritjen e numrit t\u00eb porosive), performanca e host-it, ku ishin vendosur p\u00ebrpunuesi dhe ruajtja e skedar\u00ebve, u b\u00eb faktori kufizues. Si rezultat, ndaloi p\u00ebrdit\u00ebsimi i asortimentit dhe \u00e7mimeve, d\u00ebrgimi i njoftimeve p\u00ebr p\u00ebrdoruesit dhe shum\u00eb funksione t\u00eb tjera kritike q\u00eb mbet\u00ebn ngujuar n\u00eb radh\u00eb. Ekipi i Ops migroi menj\u00ebher\u00eb ruajtjen e skedar\u00ebve n\u00eb nj\u00eb ruajtje rrjeti t\u00eb ngjashme me S3, dhe kjo na lejoi t\u00eb ngrinim disa makina t\u00eb fuqishme p\u00ebr t\u00eb shkall\u00ebzuar p\u00ebrpunuesin e detyrave t\u00eb prapambetura.<\/p>\n

P\u00ebrfundimi: <\/strong>Rregulli Stateless duhet t\u00eb respektohet p\u00ebr t\u00eb gjitha komponent\u00ebt pa p\u00ebrjashtim, edhe n\u00ebse duket \"se nuk do t\u00eb hasim ndonj\u00eb problem k\u00ebtu\". M\u00eb mir\u00eb t\u00eb kalosh pak koh\u00eb p\u00ebr organizimin e duhur t\u00eb pun\u00ebs s\u00eb t\u00eb gjitha sistemeve, sesa m\u00eb von\u00eb t\u00eb shkruash p\u00ebrs\u00ebri kodin dhe t\u00eb riparosh sh\u00ebrbimin q\u00eb po p\u00ebrjeton ngarkes\u00eb.<\/p><\/blockquote>\n

<\/p>\n

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

\nMegjith\u00ebse ekziston disponueshm\u00ebria e kapaciteteve shtes\u00eb, gjat\u00eb procesit t\u00eb rritjes ne has\u00ebm disa pengesa. Gjat\u00eb k\u00ebsaj periudhe, numri i porosive u rrit m\u00eb shum\u00eb se 4 her\u00eb. Tani ne tashm\u00eb po d\u00ebrgojm\u00eb m\u00eb shum\u00eb se 17,000 porosi n\u00eb dit\u00eb n\u00eb 62 qytete dhe planifikojm\u00eb t\u00eb zgjerojm\u00eb akoma m\u00eb shum\u00eb gjeografin\u00eb - n\u00eb gjysm\u00ebn e par\u00eb t\u00eb vitit 2020 pritet t\u00eb nis\u00eb sh\u00ebrbimi n\u00eb t\u00eb gjith\u00eb Rusin\u00eb. P\u00ebr t\u00eb p\u00ebrballuar ngarkes\u00ebn n\u00eb rritje, duke marr\u00eb parasysh pengesat e kaluara, ne kemi nxjerr\u00eb p\u00ebr vete 7 parime kryesore t\u00eb pun\u00ebs n\u00eb kushte rritje t\u00eb vazhdueshme:<\/p>\n

    \n
  1. Menaxhimi i incidenteve<\/strong>. Ne krijuam nj\u00eb tabel\u00eb n\u00eb Jira, ku \u00e7do incident pasqyrohet n\u00eb form\u00ebn e nj\u00eb tiketi. Kjo do t\u00eb ndihmoj\u00eb n\u00eb p\u00ebrparimin dhe realizimin e detyrave t\u00eb lidhura me incidentin. Sepse n\u00eb thelb nuk \u00ebsht\u00eb e frikshme t\u00eb gabosh - \u00ebsht\u00eb e frikshme t\u00eb gabosh dy her\u00eb p\u00ebr t\u00eb nj\u00ebjtin arsyesh. P\u00ebr rastet, kur incidentet p\u00ebrs\u00ebriten para se t\u00eb mund t\u00eb rregullohet shkaku, duhet t\u00eb jet\u00eb gati nj\u00eb udh\u00ebzues veprimi, sepse gjat\u00eb ngarkes\u00ebs s\u00eb madhe \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb reagosh me shpejt\u00ebsi.<\/li>\n
  2. Monitorimi <\/strong>k\u00ebrkohet p\u00ebr t\u00eb gjith\u00eb element\u00ebt e infrastruktur\u00ebs pa p\u00ebrjashtim. Pik\u00ebrisht fal\u00eb tij ne ishim n\u00eb gjendje t\u00eb parashikonim rritjen e ngarkes\u00ebs dhe t\u00eb zgjedhim sakt\u00eb \"ngushticat\" p\u00ebr t'u p\u00ebrpriorizuar n\u00eb zgjidhjen e tyre. Shum\u00eb gjasa, n\u00eb raste ngarkese t\u00eb lart\u00eb, do t\u00eb prishet ose filloj\u00eb t\u00eb ngadal\u00ebsohet gjith\u00e7ka q\u00eb nuk keni menduar. Prandaj \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb krijoni alerte t\u00eb reja menj\u00ebher\u00eb pas ndodhis\u00eb s\u00eb incidenteve t\u00eb para, p\u00ebr t\u00eb monitoruar dhe parandaluar ato.<\/li>\n
  3. Alerte t\u00eb duhura<\/strong> jan\u00eb t\u00eb domosdoshme kur ngarkohet ndjesh\u00ebm sistemi. S\u00eb pari, ato duhet t\u00eb njoftojn\u00eb sakt\u00ebsisht se \u00e7far\u00eb \u00ebsht\u00eb prishur. S\u00eb dyti, nuk duhet t\u00eb ket\u00eb shum\u00eb alerte, sepse mbizot\u00ebrimi i alerteve 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 pa shtet. <\/strong>Ne u siguruam q\u00eb p\u00ebr k\u00ebt\u00eb rregull nuk duhet t\u00eb ket\u00eb p\u00ebrjashtime. Duhet t\u00eb ekzistoj\u00eb nj\u00eb pavar\u00ebsi e plot\u00eb nga mjedisi i ekzekutimit. P\u00ebr k\u00ebt\u00eb, ju mund t\u00eb ruani t\u00eb dh\u00ebna t\u00eb ndara n\u00eb DB ose, p\u00ebr shembull, direkt n\u00eb S3. E akoma m\u00eb mir\u00eb t\u00eb ndiqni rregullat https:\/\/12factor.net<\/a><\/noindex>. Gjat\u00eb rritjes s\u00eb papritur n\u00eb koh\u00eb, optimizimi i kodit nuk \u00ebsht\u00eb mund\u00ebsi, dhe do t\u00eb duhet t\u00eb p\u00ebrballeni me ngarkes\u00ebn me an\u00eb t\u00eb rritjes direkte t\u00eb burimeve kompjuterike dhe shkall\u00ebzimit horizontal.<\/li>\n
  5. Kota dhe performanca e sh\u00ebrbimeve t\u00eb jashtme. <\/strong>N\u00eb rastin e rritjes s\u00eb shpejt\u00eb, problemi mund t\u00eb ndodhi jo vet\u00ebm n\u00eb infrastruktur\u00ebn tuaj, por edhe n\u00eb sh\u00ebrbimin e jasht\u00ebm. E m\u00eb e keqe \u00ebsht\u00eb kur kjo ndodh jo p\u00ebr shkak t\u00eb nj\u00eb defekti, por p\u00ebr shkak t\u00eb arritjes s\u00eb kuotave ose limiteve. Prandaj, sh\u00ebrbimet e jashtme duhet t\u00eb shkall\u00ebzohen po aq mir\u00eb sa dhe ju.\u00a0<\/li>\n
  6. Ndarja e proceseve dhe radh\u00ebve. <\/strong>Kjo ndihmon shum\u00eb kur ndonj\u00eb nga portat has nj\u00eb bllokim. Nuk do t\u00eb p\u00ebrballeshim me vonesa n\u00eb transmetimin 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 midis sistemeve informative. 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 ve\u00e7mas.<\/li>\n
  7. Realitetet financiare.<\/strong> Kur ndodhet nj\u00eb rritje eksplozive e fluksit t\u00eb t\u00eb dh\u00ebnave, nuk ka koh\u00eb p\u00ebr t\u00eb menduar p\u00ebr tarifa dhe abonime. Por ato duhet t\u00eb mbahen mend, sidomos n\u00ebse jeni nj\u00eb kompani e vog\u00ebl. Nj\u00eb fatur\u00eb e madhe mund t\u00eb l\u00ebshohet nga \u00e7do pronar API, si dhe nga ofruesi juaj i hostimit. Pra, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb lexoni kontratat me kujdes.<\/li>\n<\/ol>\n

    <\/p>\n

    P\u00ebrfundim<\/h2>\n

    \nNuk kishte humbje, por e kaluam k\u00ebt\u00eb faz\u00eb, dhe sot p\u00ebrpiqemi t\u00eb respektojm\u00eb t\u00eb gjitha parimet e zbuluara, me \u00e7do makin\u00eb q\u00eb ka mund\u00ebsin\u00eb p\u00ebr rritje t\u00eb leht\u00eb t\u00eb kapacitetit deri n\u00eb 4 her\u00eb, p\u00ebr t\u2019u p\u00ebrballur me ndonj\u00eb pap\u00ebrgatitje.\u00a0<\/p>\n

    N\u00eb postimet e ardhshme do t\u00eb ndajm\u00eb p\u00ebrvoj\u00ebn ton\u00eb n\u00eb hetimin e r\u00ebnies s\u00eb performanc\u00ebs n\u00eb Apache Solr, gjithashtu do t\u00eb flasim p\u00ebr optimizimin e pyetjeve dhe si bashk\u00ebpunimi me FNS ndihmon kompanin\u00eb t\u00eb kursj\u00eb para. Abonohuni n\u00eb blogun ton\u00eb q\u00eb t\u00eb mos humbisni asgj\u00eb dhe na tregoni n\u00eb komentet n\u00ebse keni p\u00ebrjetuar ndonj\u00ebher\u00eb disa nga k\u00ebto \u00e7\u00ebshtje 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 lutem.<\/p>\n

    A keni p\u00ebrjetuar ngadal\u00ebsim\/r\u00ebnien e sh\u00ebrbimeve n\u00eb rast t\u00eb rritjes drastike t\u00eb ngarkes\u00ebs p\u00ebr shkak t\u00eb:<\/h2>\n