ProHoster > Blogs > Administrācija > Kā attālināti pārdzīvojām x10 slodzes pieaugumu un kādus secinājumus izdarījām

Kā attālināti pārdzīvojām x10 slodzes pieaugumu un kādus secinājumus izdarījām

Sveiks, Habr! Pēdējo pāris mēneÅ”u laikā esam piedzÄ«vojuÅ”i ļoti interesantu situāciju, un es vēlētos padalÄ«ties ar mÅ«su infrastruktÅ«ras paplaÅ”ināŔanas stāstu. Å ajā laikā SberMarket pasÅ«tÄ«jumi četrkārÅ”ojās, un mēs ieviesām pakalpojumu 17 jaunās pilsētās. Pārtikas preču piegādes pieprasÄ«juma straujais pieaugums lika mums paplaÅ”ināt savu infrastruktÅ«ru. Lasiet tālāk, lai uzzinātu par interesantākajiem un noderÄ«gākajiem atklājumiem.

Kā attālināti pārdzīvojām x10 slodzes pieaugumu un kādus secinājumus izdarījām

Mani sauc Dima Bobilevs, un esmu SberMarket tehniskais direktors. Tā kā Å”is ir pirmais ieraksts mÅ«su emuārā, pastāstÄ«Å”u dažus vārdus par sevi un uzņēmumu. PagājuÅ”ajā rudenÄ« piedalÄ«jos Jauno RuNet lÄ«deru konkursā. Konkursam es uzrakstÄ«ja Ä«su stāstu Es apspriedu, kā mēs SberMarket uztveram savu iekŔējo kultÅ«ru un pieeju pakalpojumu attÄ«stÄ«bai. Lai gan es neuzvarēju konkursā, es izstrādāju galvenos principus IT ekosistēmas attÄ«stÄ«bai.

Vadot komandu, ir svarÄ«gi izprast un lÄ«dzsvarot uzņēmuma vajadzÄ«bas ar katra izstrādātāja individuālajām vajadzÄ«bām. SberMarket paÅ”laik aug 13 reizes salÄ«dzinājumā ar iepriekŔējo gadu, un tas ietekmē produktu, pieprasot pastāvÄ«gu izstrādes apjoma un tempa palielināŔanu. Neskatoties uz to, mēs veltām pietiekami daudz laika izstrādātājiem sākotnējai analÄ«zei un augstas kvalitātes koda rakstÄ«Å”anai. Å Ä« iedibinātā pieeja palÄ«dz ne tikai izveidot funkcionējoÅ”u produktu, bet arÄ« to turpmākajā mērogoÅ”anā un attÄ«stÄ«bā. Å Ä«s izaugsmes rezultātā SberMarket jau ir kļuvis par lÄ«deri pārtikas preču piegādes pakalpojumu jomā: mēs katru dienu piegādājam aptuveni 18 000 pasÅ«tÄ«jumu, salÄ«dzinot ar aptuveni 3500 februāra sākumā.

Kā attālināti pārdzīvojām x10 slodzes pieaugumu un kādus secinājumus izdarījām
Kādu dienu kāds klients lÅ«dza SberMarket kurjeram piegādāt viņa pārtikas preces bezkontakta veidā ā€” tieÅ”i uz viņa balkona.

Bet pievērsÄ«simies konkrētÄ«bai. Pēdējo mēneÅ”u laikā mēs esam aktÄ«vi paplaÅ”inājuÅ”i mÅ«su uzņēmuma infrastruktÅ«ru. Å o nepiecieÅ”amÄ«bu noteica gan ārēji, gan iekŔēji faktori. LÄ«dz ar mÅ«su klientu bāzes paplaÅ”ināŔanos, pieslēgto veikalu skaits pieauga no 90 gada sākumā lÄ«dz vairāk nekā 200 lÄ«dz maija vidum. Protams, mēs bijām sagatavojuÅ”ies, dublējot pamata infrastruktÅ«ru un paļaujoties uz iespēju palielināt un samazināt visu Yandex mākonÄ« mitināto virtuālo maŔīnu skaitu. Tomēr pieredze rāda, ka "viss, kas var noiet greizi, noies greizi". Å odien es vēlētos dalÄ«ties ar dažām no interesantākajām situācijām, kas raduŔās pēdējo nedēļu laikā. Ceru, ka mÅ«su pieredze jums bÅ«s noderÄ«ga.

Vergs ir pilnā kaujas gatavībā

Pat pirms pandēmijas mēs piedzÄ«vojām pieprasÄ«jumu skaita pieaugumu mÅ«su serveros. Pārtikas preču pasÅ«tÄ«Å”anas tendence ar piegādi mājās ieguva apgriezienus, un lÄ«dz ar pirmo COVID-19 ierobežojumu ievieÅ”anu slodze dienas laikā ievērojami palielinājās. Radās nepiecieÅ”amÄ«ba ātri samazināt primārās datubāzes galveno serveru slodzi un pārvietot dažus lasÄ«Å”anas pieprasÄ«jumus uz replikas serveriem (pakārtotajiem serveriem).

Mēs Å”im solim bijām gatavojuÅ”ies jau iepriekÅ”, un Å”im manevram jau bija palaisti divi pakārtoti serveri. Tie galvenokārt veica pakeÅ”uzdevumus, Ä£enerējot informācijas plÅ«smas datu apmaiņai ar partneriem. Å ie procesi radÄ«ja nevajadzÄ«gu darba slodzi un pamatoti tika atlikti pāris mēneÅ”us iepriekÅ”. 

Tā kā replikācija notika pakārtotajā serverÄ« (Slave), mēs pieturējāmies pie koncepcijas, ka lietojumprogrammas var strādāt ar tiem tikai lasÄ«Å”anas režīmā. Katastrofu atkopÅ”anas plāns pieņēma, ka katastrofas gadÄ«jumā mēs varam vienkārÅ”i uzstādÄ«t pakārtoto serveri galvenā servera vietā un visus lasÄ«Å”anas un rakstÄ«Å”anas pieprasÄ«jumus pārslēgt uz pakārtoto serveri. Tomēr mēs vēlējāmies izmantot replikas arÄ« analÄ«tikas nodaļai, tāpēc serveri nebija pilnÄ«bā iestatÄ«ti tikai lasÄ«Å”anas režīmā. Katram resursdatoram bija savs lietotāju kopums, dažiem no kuriem bija rakstÄ«Å”anas piekļuve, lai saglabātu starpposma aprēķinu rezultātus.

LÄ«dz noteiktam slodzes lÄ«menim mums bija pietiekami daudz resursu gan HTTP pieprasÄ«jumu rakstÄ«Å”anai, gan lasÄ«Å”anai. Marta vidÅ«, tieÅ”i tad, kad Sbermarket nolēma pilnÄ«bā pāriet attālināti, mēs piedzÄ«vojām ievērojamu RPS pieaugumu. Arvien vairāk mÅ«su klientu atradās paÅ”izolācijā vai strādāja no mājām, kas ietekmēja mÅ«su slodzes rādÄ«tājus.

Galvenā datora veiktspēja vairs nebija pietiekama, tāpēc mēs sākām daļu no smagākajiem lasÄ«Å”anas pieprasÄ«jumiem novirzÄ«t replikai. Lai caurspÄ«dÄ«gi novirzÄ«tu rakstÄ«Å”anas pieprasÄ«jumus uz galveno datoru un lasÄ«Å”anas pieprasÄ«jumus uz pakārtoto datoru, mēs izmantojām Ruby dārgakmeni.Astoņkājis"Mēs izveidojām Ä«paÅ”u lietotāju ar _readonly pēcfiksu bez rakstÄ«Å”anas atļaujām. Tomēr viena no resursdatoru konfigurācijas kļūdas dēļ daži rakstÄ«Å”anas pieprasÄ«jumi tika nosÅ«tÄ«ti uz pakārtoto serveri ar lietotāja vārdu, kuram bija atbilstoÅ”as ā€‹ā€‹atļaujas."

Problēma neizpaudās uzreiz, jo palielinātā slodze palielināja pakārtoto ierīču aizkavi. Datu neatbilstÄ«ba tika atklāta no rÄ«ta, kad pēc importÄ“Å”anas nakts laikā pakārtotajām ierÄ«cēm neizdevās "panākt" galveno ierÄ«ci. Mēs to attiecinājām uz lielo slodzi paÅ”am pakalpojumam un importu, kas saistÄ«ts ar jaunu veikalu palaiÅ”anu. Tomēr datu piegāde ar vairāku stundu kavÄ“Å”anos bija nepieņemama, tāpēc mēs pārslēdzām procesus uz otro analÄ«tisko pakārtoto ierÄ«ci, jo tā bija...Š¾lielāki resursi un nebija pārslogota ar lasÄ«Å”anas pieprasÄ«jumiem (tā mēs sev izskaidrojām replikācijas aizkaves neesamÄ«bu).

LÄ«dz brÄ«dim, kad mēs noskaidrojām primārā pakārtotā servera "nepastāvÄ“Å”anas" iemeslus, analÄ«tiskais serveris jau bija pārstājis darboties tā paÅ”a iemesla dēļ. Lai gan mums bija divi papildu serveri, uz kuriem plānojām pārsÅ«tÄ«t slodzi galvenā servera kļūmes gadÄ«jumā, neveiksmÄ«gas kļūdas dēļ neviens no tiem kritiskajā brÄ«dÄ« nebija pieejams.

Taču, tā kā mēs ne tikai izveidojām datubāzes izgāztuvi (atjaunoÅ”ana tajā brÄ«dÄ« aizņēma aptuveni 5 stundas), bet arÄ« izveidojām galvenā servera momentuzņēmumu, mēs varējām palaist repliku 2 stundu laikā. Tomēr pēc tam mēs saskārāmies ar ilgu replikācijas žurnāla uzkrāŔanos (jo process ir vienpavedienu, bet tas ir pavisam cits stāsts).

Secinājums: Pēc Ŕī incidenta kļuva skaidrs, ka mums ir jāatsakās no lietotāju rakstÄ«Å”anas piekļuves ierobežoÅ”anas prakses un jāpadara viss serveris tikai lasāms. Å Ä« pieeja nodroÅ”ina, ka replikas bÅ«s pieejamas kritiskos brīžos.

Pat viena sarežģīta vaicājuma optimizÄ“Å”ana var atdzÄ«vināt datubāzi.

Lai gan mēs pastāvÄ«gi atjauninājām vietnes katalogu, vaicājumi, ko sÅ«tÄ«jām uz pakārtotajiem serveriem, nedaudz atpalika no galvenā servera. Laiks, kas mums bija nepiecieÅ”ams, lai atklātu un novērstu problēmu ar pakārtoto serveru pēkŔņu darbÄ«bas pārtraukÅ”anu, bija ilgāks nekā "psiholoÄ£iskā barjera" (Å”ajā laikā varēja notikt cenu atjauninājumi, un klienti bÅ«tu redzējuÅ”i novecojuÅ”us datus), un mēs bijām spiesti pārslēgt visus vaicājumus uz galveno datubāzes serveri. Tā rezultātā vietne darbojās lēni... bet vismaz tā strādāja. Un, kamēr pakārtotais serveris atjaunojās, mums nebija citas izvēles kā vien optimizēt. 

Kamēr pakārtotie serveri atkopās, minÅ«tes vilkās, galvenais serveris joprojām bija pārslogots, un mēs visus savus spēkus koncentrējām uz aktÄ«vo uzdevumu optimizÄ“Å”anu saskaņā ar Pareto principu: mēs atlasÄ«jām galvenos vaicājumus, kas veidoja lielāko daļu slodzes, un sākām regulÄ“Å”anu. Tas tika darÄ«ts operatÄ«vi.

Interesants rezultāts bija tas, ka pilnÄ«bā ielādēta MySQL instance reaģēja pat uz nelieliem procesa uzlabojumiem. Optimizējot pāris vaicājumus, kas veidoja tikai 5% no kopējās slodzes, jau bija manāms centrālā procesora slodzes samazinājums. Rezultātā mēs varējām nodroÅ”ināt pieņemamu resursu rezervi galvenajai datubāzei un iegÅ«t nepiecieÅ”amo laiku repliku atjaunoÅ”anai. 

Secinājums: Pat nelielas optimizācijas ļauj mums izturēt pārslodzi vairākas stundas. Ar to pietika tieÅ”i tik, lai atjaunotu mÅ«su replikas serverus. Starp citu, vaicājumu optimizācijas tehniskos aspektus apspriedÄ«sim kādā no turpmākajiem ierakstiem. Tāpēc abonējiet mÅ«su emuāru, ja Ŕī informācija jums noder.

Organizēt partneru pakalpojumu veiktspējas uzraudzību

Mēs apstrādājam klientu pasÅ«tÄ«jumus, tāpēc mÅ«su pakalpojumi pastāvÄ«gi mijiedarbojas ar treÅ”o puÅ”u API ā€” SMS vārtejām, maksājumu platformām, marÅ”rutÄ“Å”anas sistēmām, Ä£eokoderiem, Federālo nodokļu dienestu un daudzām citām sistēmām. Un, kad slodze sāka strauji pieaugt, mēs sākām saskarties ar mÅ«su partneru pakalpojumu API ierobežojumiem, par kuriem iepriekÅ” pat nebijām domājuÅ”i.

NegaidÄ«ta partneru pakalpojumu kvotu pārsniegÅ”ana var izraisÄ«t jÅ«su paÅ”u pakalpojumu dÄ«kstāvi. Daudzi API bloķē klientus, kas pārsniedz savus ierobežojumus, un dažos gadÄ«jumos pārmērÄ«gie pieprasÄ«jumi var pārslogot partnera ražoÅ”anas sistēmu. 

Piemēram, palielinoties piegāžu apjomam, pavadoÅ”ie pakalpojumi nespēja tikt galā ar to sadali un marÅ”rutu noteikÅ”anu. Tā rezultātā pasÅ«tÄ«jumi tika veikti, bet marÅ”rutu izveides pakalpojums nedarbojās. Jāsaka, ka mÅ«su loÄ£istikas komanda Ŕādos apstākļos paveica gandrÄ«z neiespējamo, un komandas skaidrā komunikācija palÄ«dzēja kompensēt Ä«slaicÄ«gus pakalpojumu pārtraukumus. Tomēr Ŕādu pasÅ«tÄ«jumu apjomu nav iespējams nepārtraukti apstrādāt manuāli, un pēc kāda laika mēs saskartos ar nepieņemamu laika starpÄ«bu starp pasÅ«tÄ«jumiem un to izpildi. 

Tika Ä«stenoti vairāki organizatoriski pasākumi, un komandas koordinētais darbs palÄ«dzēja mums iegÅ«t laiku, kamēr risinājām sarunas par jauniem noteikumiem un gaidÄ«jām, kad daži partneri uzlabos savus pakalpojumus. Ir arÄ« citi API, kas lepojas ar izcilu noturÄ«bu un piedāvā pārmērÄ«gas cenas lielai datplÅ«smai. Piemēram, sākumā piegādes punkta adreses noteikÅ”anai mēs izmantojām labi pazÄ«stamu kartÄ“Å”anas API. Taču mēneÅ”a beigās saņēmām ievērojamu rēķinu gandrÄ«z 2 miljonu rubļu apmērā. Pēc tam nolēmām to ātri nomainÄ«t. NereklāmÄ“Å”u, bet teikÅ”u, ka mÅ«su izmaksas ir ievērojami samazinājuŔās.
Kā attālināti pārdzīvojām x10 slodzes pieaugumu un kādus secinājumus izdarījām

Secinājums: Ir svarÄ«gi sekot lÄ«dzi visu partneru pakalpojumu noteikumiem un nosacÄ«jumiem un paturēt tos prātā. Pat ja Å”odien tie Ŕķiet "pārāk dārgi", tas nenozÄ«mē, ka rÄ«t tie nekļūs par Ŕķērsli izaugsmei. Un, protams, vislabāk ir iepriekÅ” vienoties par finanÅ”u nosacÄ«jumiem pieaugoÅ”a pakalpojumu pieprasÄ«juma gadÄ«jumā. 

Dažreiz izrādās, ka "vajag vairāk zelta"(c) nepalīdz

Esam pieraduÅ”i pie sastrēgumiem galvenajā datubāzē vai lietojumprogrammu serveros, taču mērogojot problēmas var rasties tur, kur tās vismazāk gaidāt. Pilna teksta meklÄ“Å”anai mÅ«su vietnē izmantojam Apache Solr dzinēju. Palielinoties slodzei, pamanÄ«jām reakcijas laika samazināŔanos, un servera centrālā procesora noslodze sasniedza 100%. Kas gan varētu bÅ«t vienkārŔāk? Mēs vienkārÅ”i pieŔķiram Solr konteineram vairāk resursu.

GaidÄ«tā veiktspējas palielinājuma vietā serveris vienkārÅ”i nomira. Tas nekavējoties ielādējās ar 100% jaudu un reaģēja vēl lēnāk. Sākotnēji mums bija divi kodoli un 2 GB RAM. Mēs nolēmām darÄ«t to, kas parasti darbojas ā€” uzlabot serveri lÄ«dz astoņiem kodoliem un 32 GB. Lietas kļuva daudz sliktākas (precÄ«zi kā un kāpēc, mēs paskaidrosim atseviŔķā ierakstā). 

Dažu dienu laikā mēs atrisinājām Ŕīs problēmas sarežģījumus un panācām optimālu veiktspēju ar 8 kodoliem un 32 GB atmiņu. Å Ä« konfigurācija ļauj mums turpināt palielināt slodzi, kas ir ļoti svarÄ«gi, jo izaugsme notiek ne tikai klientu, bet arÄ« pievienoto veikalu skaita ziņā ā€” to skaits divu mēneÅ”u laikā ir divkārÅ”ojies. 

Secinājums: Standarta metodes, piemēram, "papildu aparatÅ«ras pievienoÅ”ana", ne vienmēr darbojas. Tāpēc, mērogojot jebkuru pakalpojumu, jums ir rÅ«pÄ«gi jāsaprot, kā tas izmanto resursus, un iepriekÅ” jāpārbauda tā veiktspēja jaunos apstākļos. 

Bezvalstnieku sistēma ir vienkārÅ”as horizontālas mērogoÅ”anas atslēga

MÅ«su komanda parasti ievēro labi zināmu pieeju: pakalpojumiem jābÅ«t bez statusa un neatkarÄ«giem no izpildlaika vides. Tas ļāva mums tikt galā ar palielinātu slodzi, vienkārÅ”i horizontāli mērogojot. Tomēr mums bija viens izņēmums: ilgstoÅ”i darbojoÅ”s fona uzdevumu apstrādātājs. Tas apstrādāja e-pasta un Ä«sziņu sÅ«tÄ«Å”anu, notikumu apstrādi, plÅ«smas Ä£enerÄ“Å”anu, cenu un krājumu importÄ“Å”anu, kā arÄ« attēlu apstrādi. Sanāca tā, ka tas bija atkarÄ«gs no lokālās failu krātuves un bija viena instance. 

Kad apstrādes rindā esoÅ”o uzdevumu skaits palielinājās (kas, protams, notika lÄ«dz ar pasÅ«tÄ«jumu skaita pieaugumu), procesoru un failu glabātuvi mitinoŔā resursdatora veiktspēja kļuva ierobežota. Tā rezultātā krājumu un cenu atjauninājumi, lietotāju paziņojumi un daudzas citas kritiski svarÄ«gas funkcijas apstājās uzkrāŔanās dēļ. Operāciju komanda ātri migrēja failu glabātuvi uz S3 lÄ«dzÄ«gu tÄ«kla krātuvi, ļaujot mums izvietot vairākas jaudÄ«gas iekārtas fona apstrādes mērogoÅ”anai.

Secinājums: Noteikums par bezvalstnieku statusu ir jāievēro visiem komponentiem bez izņēmuma, pat ja Ŕķiet, ka mēs vienkārÅ”i nesasniegsim savu robežu. Labāk ir veltÄ«t nedaudz laika, lai visas sistēmas darbotos pareizi, nekā steigties ar koda pārrakstÄ«Å”anu un pārslogota pakalpojuma laboÅ”anu.

7 intensīvas izaugsmes principi

Neskatoties uz papildu jaudas pieejamÄ«bu, izaugsmes gaitā esam saskāruÅ”ies ar vairākām grÅ«tÄ«bām. Å ajā laikā pasÅ«tÄ«jumu skaits ir vairāk nekā četrkārÅ”ojies. PaÅ”laik mēs piegādājam vairāk nekā 17 000 pasÅ«tÄ«jumu dienā 62 pilsētās un plānojam vēl vairāk paplaÅ”ināt savu Ä£eogrāfisko tvērumu ā€” mēs plānojam uzsākt pakalpojuma sniegÅ”anu visā Krievijā 2020. gada pirmajā pusē. Lai tiktu galā ar pieaugoÅ”o darba slodzi un izaicinājumiem, ar kuriem jau esam saskāruÅ”ies, esam izstrādājuÅ”i septiņus galvenos principus mÅ«su darbÄ«bas pārvaldÄ«bai pastāvÄ«gas izaugsmes kontekstā:

  1. Incidentu pārvaldÄ«baEsam izveidojuÅ”i Jira dēli, kurā katrs incidents tiek reÄ£istrēts kā pieprasÄ«jums. Tas mums palÄ«dzēs noteikt prioritātes un pabeigt ar incidentu saistÄ«tos uzdevumus. Galu galā runa nav par kļūdas pieļauÅ”anu, bet gan par vienas un tās paÅ”as kļūdas pieļauÅ”anu divreiz. GadÄ«jumos, kad incidenti atkārtojas, pirms var novērst pamatcēloni, mums ir jābÅ«t ieviestiem rÄ«cÄ«bas plāniem, jo ā€‹ā€‹lielas darba slodzes laikā ir ļoti svarÄ«gi reaģēt ātri.
  2. UzraudzÄ«ba Tas ir nepiecieÅ”ams visiem infrastruktÅ«ras elementiem bez izņēmuma. TieÅ”i pateicoties tam, mēs spējām paredzēt slodzes pieaugumu un pareizi identificēt vājās vietas, lai noteiktu prioritātes to risināŔanai. Lielas slodzes apstākļos pastāv liela iespēja, ka viss, par ko nekad nebijāt iedomājies, sabojāsies vai palēnināsies. Tāpēc vislabāk ir izveidot jaunus brÄ«dinājumus tÅ«lÄ«t pēc pirmo incidentu raÅ”anās, lai tos uzraudzÄ«tu un paredzētu.
  3. Pareizi brÄ«dinājumi Tie ir bÅ«tiski pēkŔņas slodzes pieauguma gadÄ«jumā. Pirmkārt, tiem skaidri jānorāda, kas ir bojāts. Otrkārt, nevajadzētu bÅ«t pārāk daudz brÄ«dinājumu, jo pārāk daudz nekritisku brÄ«dinājumu noved pie visu paziņojumu ignorÄ“Å”anas.
  4. Pieteikumiem jābÅ«t bez statusa. Esam pārliecinājuÅ”ies, ka Å”im noteikumam nevajadzētu bÅ«t izņēmumiem. Ir nepiecieÅ”ama pilnÄ«ga neatkarÄ«ba no izpildlaika vides. Lai to panāktu, koplietotus datus var glabāt datubāzē vai, piemēram, tieÅ”i S3. Vēl labāk, ievērojiet noteikumus. https://12factor.netPēkŔņa laika pieauguma laikā vienkārÅ”i nav laika optimizēt kodu, un slodze ir jāpārvalda, tieÅ”i palielinot skaitļoÅ”anas resursus un horizontāli mērogojot.
  5. Ārējo pakalpojumu kvotas un sniegums. Straujas izaugsmes rezultātā problēmas var rasties ne tikai jÅ«su infrastruktÅ«rā, bet arÄ« ārējos pakalpojumos. VisnepatÄ«kamāk ir tad, ja tas notiek nevis kļūmes dēļ, bet gan tāpēc, ka ir sasniegtas kvotas vai ierobežojumi. Tāpēc ārējiem pakalpojumiem ir jāpaplaÅ”inās tikpat labi kā jums. 
  6. Atdaliet procesus un rindas. Tas ir ļoti noderÄ«gi, ja kādā no vārtejām rodas sastrēgums. Datu pārsÅ«tÄ«Å”anas kavÄ“Å”anās nebÅ«tu radusies, ja pilnas Ä«sziņu rindas nebÅ«tu traucējuÅ”as paziņojumu apmaiņu starp informācijas sistēmām. Turklāt darbinieku skaitu bÅ«tu bijis vieglāk palielināt, ja tie darbotos atseviŔķi.
  7. Finansiālā realitāte. Kad datu plÅ«smas strauji pieaug, nav laika uztraukties par tarifiem un abonÄ“Å”anas maksām. Taču tie ir svarÄ«gi paturēt prātā, it Ä«paÅ”i, ja esat mazs uzņēmums. Jebkura API Ä«paÅ”nieks, kā arÄ« jÅ«su mitināŔanas pakalpojumu sniedzējs var jums iekasēt ievērojamu rēķinu. Tāpēc rÅ«pÄ«gi izlasiet savus lÄ«gumus.

Secinājums

Ne bez zaudējumiem, bet mēs pārvarējām Å”o posmu, un Å”odien mēs cenÅ”amies ievērot visus atklātos principus, un katrai maŔīnai ir iespēja viegli palielināt produktivitāti x4, lai tiktu galā ar jebkādiem negaidÄ«tiem notikumiem. 

Turpmākajos ierakstos mēs dalÄ«simies pieredzē, pētot veiktspējas kritumus Apache Solr, apspriedÄ«sim vaicājumu optimizāciju un to, kā sadarbÄ«ba ar Federālo nodokļu dienestu palÄ«dz uzņēmumam ietaupÄ«t naudu. Abonējiet mÅ«su emuāru, lai bÅ«tu lietas kursā, un komentāros paziņojiet mums, ja esat saskāruÅ”ies ar lÄ«dzÄ«gām problēmām palielinātas datplÅ«smas laikā.

Kā attālināti pārdzīvojām x10 slodzes pieaugumu un kādus secinājumus izdarījām

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai esat kādreiz saskāries ar pakalpojuma palēnināŔanos/samazinājumu pēkŔņas slodzes palielināŔanās dēļ, ko izraisÄ«jis:

  • 55,6%Nespēja ātri pievienot skaitļoÅ”anas resursus10

  • 16,7%Hostinga pakalpojumu sniedzēja infrastruktÅ«ras ierobežojumi3

  • 33,3%TreŔās puses API ierobežojumi6

  • 27,8%Viņu pieteikumu bezvalstniecÄ«bas principu pārkāpumi5

  • 88,9%PaÅ”u pakalpojumu koda neoptimalitāte16

Nobalsoja 18 lietotāji. 6 lietotāji atturējās.

Avots: www.habr.com

Iegādājieties uzticamu mitināŔanu vietnēm ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa vietņu mitināŔanu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster