Watengenezaji programu huona programu zao mpya zikikwama mara tu watumiaji elfu chache wanapobofya “go,” na kusuasua huko mara chache huwa si hitilafu katika kodi – ni CPU na RAM ya seva zikipambana kutafuta nafasi. Kizuizi hiki huonekana kama muda mrefu wa kupakia kurasa, muda wa kusubiri (time-outs), au programu kufungwa kabisa, na hivyo kuharibu uzoefu wa mtumiaji, mapato, na imani katika chapa.

Kwa nini seva iliyofanya kazi vizuri maabarani inaweza kusimama kabisa wakati wa matumizi halisi (production)

Wakati wa uundaji, mtengenezaji mmoja hutuma maombi machache, hivyo rasilimali za seva hubaki bila kutumika kwa muda mwingi. Programu inapozinduliwa, kila mgeni hutoa ombi ambalo linahitaji viungo viwili muhimu:

  • CPU (central processing unit) – kichakataji kinachotekeleza kila mzunguko (loop), kazi (function), na hesabu. Ifikirie kama mpishi ambaye anaweza kuandaa idadi fulani tu ya vyakula kwa wakati mmoja. Agizo moja hutolewa papo hapo; maagizo mia moja yanamaanisha mpishi bado anafanya kazi kwa kasi ile ile, lakini wateja wanasubiri kwa muda mrefu zaidi.
  • RAM (random-access memory) – hifadhi ya muda kwa ajili ya data ambayo CPU inaihitaji wakati wa kushughulikia ombi. Ni kama meza ambapo mpishi huweka viungo vya kila chakula. Ikiwa meza imejaa, mpishi lazima aache kupokea maagizo mapya hadi nafasi itakapopatikana.

Watumiaji maelfu wanapoingia kwa wakati mmoja, kila ombi linachukua sehemu yake ya muda wa CPU na sehemu yake ya RAM. Rasilimali chache za seva zinagawanywa kati ya maombi hayo, na foleni inakua. Seva yenyewe haijakuwa polepole; muda wa kusubiri kwa kila ombi umeongezeka.

Ushawishi wa “kununua tu mashine kubwa zaidi”

Hatua ya kwanza ya kawaida ni kuboresha mashine – utaratibu unaoitwa vertical scaling. Kuongeza zaidi CPU cores au RAM zaidi kunaboresha uwezo: kutoka kwenye kiini (cores) 4 hadi 16, au kutoka 8 GB hadi 64 GB, kunaweza kuhimili ongezeko kubwa la trafiki bila kubadilisha kodi yoyote.

Hata hivyo, vertical scaling inakutana na kikomo kigumu:

  • Mipaka ya kifizikia – kila motherboard inaweza kuhifadhi idadi fulani tu ya kiini (cores) na kiasi fulani cha kumbukumbu.
  • Faida zinazopungua – kila kiini au gigabyte ya ziada inagharimu zaidi kuliko iliyopita, huku faida ya utendaji ikipungua.
  • Single point of failure – ikiwa seva hiyo kubwa itafeli, huduma nzima itatoweka.

Kutokana na vikwazo hivi, makampuni makubwa ya sekta hii – majukwaa ya utiririshaji (streaming), injini za utafutaji, tovuti za e-commerce – yameacha kutumia mashine moja kubwa sana.

Njia mbadala: kusambaza mzigo kwenye mashine nyingi ndogo ndogo

Badala ya kujenga mnara mrefu zaidi, waendeshaji huongeza seva nyingi za ukubwa wa wastani na kuziacha zishirikiane kutoa huduma kwa trafiki hiyo. Mtindo huu wa horizontal scaling unaweka kila mashine katika kiwango cha utendaji kinachofaa na kuepuka ongezeko la gharama linalozidi uwezo wa kutabirika la maboresho ya vertical.

Kuratibu mashine nyingi kunahitaji load balancer – programu au kifaa cha maunzi kinachopokea kila ombi linalokuja na kulielekeza kwenye seva yenye uwezo mkubwa zaidi unaopatikana. Balancer hiyo huficha utata kutoka kwa mteja; kwa mtazamo wa mtumiaji, tovuti bado inaonekana kama sehemu moja (single endpoint).

Horizontal scaling pia huleta ustahimilivu. Ikiwa node moja itafeli, balancer itahamisha trafiki kwa node nyingine zinazofanya kazi vizuri, na hivyo kuendeleza huduma.

Mambo ya kuzingatia unapoanza kuongeza mashine

  • Stateless design – maombi hayapaswi kutegemea data iliyohifadhiwa kwenye kumbukumbu ya seva mahususi pekee; vinginevyo mtumiaji anaweza kuhamishiwa kwenye node ambayo haina muktadha unaohitajika. Kutumia shared caches au kanzidata (databases) hutatua hili.
  • Health checks – balancer lazima iweze kutambua seva inayofeli haraka na kuacha kuitumia trafiki.
  • Auto-scaling policies – majukwaa mengi ya wingu (cloud) hukuruhusu kuweka viwango (matumizi ya CPU, latency ya ombi) ambavyo huanzisha au kuzima instances kiotomatiki, ili kuweka gharama sawa na mahitaji.

Upande mwingine: vertical scaling haijafa

Kwa timu ndogo au programu zenye trafiki ndogo, seva moja iliyoboreshwa inaweza kuwa suluhisho rahisi na la bei nafuu zaidi. Ikiwa ongezeko la trafiki linatabirika (kwa mfano, uzinduzi uliopangwa wa bidhaa), maboresho ya muda ya vertical yanaweza kuwa ya vitendo zaidi kuliko kuandaa jeshi zima la instances mpya.

Siri ni kutambua wakati mbinu ya “mashine kubwa zaidi” inapoacha kutoa thamani inayolingana na gharama, na kuanza kupanga kwa ajili ya usambazaji.

Muhtasari

Kupungua kwa kasi ya seva baada ya uzinduzi kwa kawaida ni tatizo la ushindani wa rasilimali, na si hitilafu ya kodi. Mizunguko ya CPU na nafasi za RAM ina kikomo, na maombi mengi yanapofika kwa pamoja, hujipanga kwenye foleni, jambo linaloongeza muda wa kuitikia. Upanuzi wa wima (Vertical scaling) unakupa uwezo wa ziada kwa muda, lakini hivi karibuni hukutana na mipaka ya kifizikia na kiuchumi. Upanuzi wa mlalo (Horizontal scaling)—kwa kuongeza seva nyingi ndogo nyuma ya kifaa cha kusawazisha mzigo (load balancer)—unatoa njia ya bei nafuu na yenye uimara zaidi kadiri msongamano wa maombi unavyoongezeka. Wakati unapoona foleni inazidi kuongezeka, ni wakati wa kutathmini ikiwa kuongeza 'cores' chache zaidi kutatosha au ikiwa unapaswa kuanza kusambaza mzigo huo kwenye mashine nyingi.

Source: dev.to article “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”