Kako uporaba naše spletne čakalne vrste preprečuje sesutje spletnega mesta in sesutje spletnega mesta - koliko sočasnih uporabnikov lahko prenese spletni strežnik?

Zakaj uporabljati virtualno čakalnico na podlagi tarife?

Na podlagi tarife ali na podlagi "enkrat izstopi, enkrat vstopi"? Ocenjujemo prednosti in slabosti.

Pravzaprav nismo našli nobene prednosti za "one-out" in "one-in". Na kratko, težava tega pristopa je, da kadar so uporabniki obiskovalci spletnih mest za elektronsko poslovanje, spletni strežnik ne ve, koliko sočasnih uporabnikov ima v danem trenutku. To je ovira. Zakaj.

V nadaljevanju tega članka vam povemo tudi, kako lahko za zaščito svojega spletnega mesta uporabite tudi virtualno sobo, ki temelji na stopnji.



Najbolje ocenjena virtualna čakalnica na G2

Kaj naše stranke pravijo o Queue-Fair


testiranje obremenitve http zahteve koliko zahtevkov spletni strežnik lahko prenese brez dodatnih virov strežnika

Koliko sočasnih uporabnikov lahko upravlja spletni strežnik?

Če veste, koliko sočasnih uporabnikov obravnava spletni strežnik, in povprečni čas transakcije ali trajanje obiska od prve strani v toku transakcije do strani za potrditev naročila, lahko to pretvorite v stopnjo čakalne vrste z uporabo Littleovega zakona tako, da število uporabnikov delite s trajanjem, kot sledi:

Stopnja čakalne vrste = število hkratnih uporabnikov / čas transakcije

Kako natančen je sistem čakalnih vrst, ki temelji na stopnji?

Queue-Fair bo na vaše spletno mesto pošiljal obiskovalce s hitrostjo, ki jo določite - imamo daleč najnatančnejšo umetno inteligenco čakalne vrste v poslu, ki zagotavlja, da je število obiskovalcev, ki jih želite vsako minuto, točno takšno, kot ga dobite vsako minuto, pri čemer samodejno upošteva ljudi, ki niso prisotni, ko so na vrsti, in ljudi, ki se vrnejo pozno.

Kako se to odraža v številu hkratnih uporabnikov? Seveda ne bo vsak obiskovalec, ki bo prišel na vaše spletno mesto, potreboval točno toliko povprečnega časa za dokončanje transakcije, vendar boste s Queue-Fair zaradi zakona velikih številk dobili zelo stalno število hkratnih uporabnikov.

Recimo, da je stopnja čakalne vrste 100 obiskovalcev na minuto. Vsako minuto bomo na vaše spletno mesto poslali 100 obiskovalcev v enakomernem toku - to je naše delo in pri tem smo osupljivo dobri. Recimo tudi, da ljudje vaše spletno mesto uporabljajo povprečno (povprečno) pet minut, pri čemer jih 70 % potrebuje od 4 do 6 minut od trenutka, ko jih sprejme čakalna vrsta, do trenutka, ko oddajo zadnjo zahtevo za stran (ne glede na to, ali opravijo transakcijo ali ne). Standardni odklon znaša eno minuto na vsaki strani povprečja. Statistično gledano to pomeni, da vsak obiskovalec, ki potrebuje pet minut in pol, potrebuje štiri minute in pol, zato se te razlike v trajanju posameznih obiskov med več sejami običajno izničijo, če jih na kakršen koli način štejete veliko. Zakon velikih števil pravi, da je to izničevanje toliko bolj natančno, kolikor večje je število vključenih oseb.

operacijski sistem največje število virov spletnega strežnika
izračun povprečne številke za sočasne uporabnike z intervalom zaupanja

Kako natančno? To lahko ugotovimo z malo statistike. Velikost vzorca je 5 * 100 = 500, kar je veliko število. To je število ljudi, ki jih štejete. To pomeni, da je standardna napaka v povprečju za čas transakcije 1 (standardni odklon, 1 minuta) deljena s kvadratnim korenom velikosti vzorca (torej kvadratnim korenom 500) v skladu s statistično formulo za standardno napako v povprečju, kar daje standardno napako v povprečju za čas transakcije 0,044 minute ali samo 2,7 sekunde, kar je manj kot en odstotek.

To pomeni, da lahko pri hitrosti čakalne vrste 100 in času transakcije 5 minut plus minus minuta za vsakega posameznega obiskovalca pričakujete 495 do 505 sočasnih uporabnikov na spletnem mestu približno 70 % časa, zato matematika pravi, da bo uporaba čakalne vrste na podlagi hitrosti zagotovila zelo stabilno obremenitev spletnih strežnikov, kot je želeno.

Toda ali je matematika točna? Tu je nekaj subtilnosti - na primer velikost vzorca, ki ga veselo kvadratno ukoreninjamo, ni vedno natanko 500 ob vsakem štetju sočasnih uporabnikov (tj. v vsakem danem trenutku), prav tako pa lahko normalna (Gaussova) porazdelitev daje negativne čase transakcij, ki se v resničnem življenju ne pojavljajo. Zato za preverjanje tovrstnih izračunov uporabljamo simulator obiskovalca za obiskovalcem, sekundo za sekundo, ki izvaja meritve, in ta nam pove, da bi morali z zgornjimi številkami v 70 % primerov pričakovati med 493 in 507 obiskovalcev, torej se matematika izredno dobro drži! Meritve podatkov nam prav tako kažejo, da bo vaše spletno mesto imelo 500 ± 15 hkratnih uporabnikov vsaj 95 % časa.

To je verjetno bolj zanesljivo kot natančnost, s katero lahko vaš spletni strežnik izmeri število ljudi, ki uporabljajo vaše spletno mesto! Še več, zelo dobro je, da tudi če nimate pojma, kakšen je povprečni čas transakcije ali standardni odklon za vaše obiskovalce, te matematične količine obstajajo, ne glede na to, ali jih poznate ali ne, in v vsakem primeru boste imeli stabilno obremenitev.

Queue-Fair bo s skoraj popolno natančnostjo zagotavljal želeno število obiskovalcev na minuto, kar pomeni zelo stabilno število sočasnih uporabnikov na vašem spletnem mestu in stabilno obremenitev spletnega strežnika, nad katero imate popoln nadzor.

Hura!


servers capacity can be exceeced with inaccurate queues Zdaj pa še opozorilo. Treba je opozoriti, da je stabilnost števila sočasnih uporabnikov na vašem spletnem mestu - in s tem stabilnost obremenitve strežnika - v veliki meri odvisna od tega, kako natančno vam ponudnik virtualne čakalnice pošilja želeno število obiskovalcev vsako minuto, zato je to ključni dejavnik pri izbiri platforme virtualne čakalnice. Ker zagotavljamo najbolj natančno virtualno čakalnico na svetu, nihče ne zaustavi poplavljanja vaših strežnikov bolje kot družba Queue-Fair.

Enostaven način za izračun hitrosti čakanja v vrsti

Kaj pa, če ne veste, koliko hkratnih uporabnikov lahko upravlja strežnik ali koliko časa transakcije? Ogledate si lahko stran, ki je verjetno ozko grlo - običajno je to stran, na kateri kliknete gumb "Kupi zdaj". Z orodjem Google Analytics poiščite mesečne edinstvene obiskovalce te strani ali preštejte mesečna naročila. To število delite s 30 * 24 * 60 = 43 200, kar je število minut v mesecu (približno). To je vaš povprečni obiskovalec na minuto v celotnem mesecu. To pomnožite s tri. To je vaš povprečni obiskovalec na minuto med delovnim časom (približno). To število podvojite. To je verjetno varna vrednost za stopnjo čakalne vrste.

Recimo, da mesečno obdelate 100.000 naročil - to pomeni 100.000 klikov na gumb "Kupi zdaj". To je 100.000 / 43.200 = 2,31 naročila na minuto. Pričakovali bi, da bo večina teh naročil potekala podnevi in da bodo vaši strežniki ponoči mirnejši, zato to pomnožite s 3 in dobite 7 naročil na minuto kot grobo oceno, kako zaseden je vaš strežnik med delovnim časom. Če je dobljena številka manjša od 50: povpraševanje bo imelo viške in padce, zato, če vaš strežnik v času konic ni opazno počasen, to pomnožite z 2 in dobite 14 aktivnih uporabnikov na minuto. Če je številka večja od 50: konice in padci od minute do minute bodo v primerjavi z njo manjši, zato podvojitev te vrednosti ni varna. Številka, ki jo dobite na koncu, je verjetno varna številka za stopnjo čakalne vrste za začetek in ustreza temu, koliko zahtevkov na sekundo lahko varno upravljate; vedno jo lahko povečate, če ugotovite, da so vaši sistemi pri tej stopnji še vedno odzivni za delovanje končnih uporabnikov.

izračun največje ravni aktivnih uporabnikov za vašo spletno aplikacijo.

Če so vaša naročila označena s časovnim žigom, si lahko ogledate tudi največje število naročil, ki ste jih sprejeli v eni minuti v zadnjem mesecu - vendar previdno, saj ne boste vedeli, koliko naročil ste v tej minuti morda zavrgli zaradi upočasnitve strežnikov, zato to število zmanjšajte za 20 %.

V nadaljevanju tega članka so opisani nekateri drugi načini določanja stopnje čakalne vrste.

zmeda glede sočasnih uporabnikov sočasnih povezav sočasnih sej in povprečnega trajanja seje

Gotcha #1: Hkratni uporabniki vs Hkratni zahtevki vs Hkratne povezave vs Hkratne seje

Treba je poudariti, da v splošni rabi obstajata vsaj dve opredelitvi pojma "hkratni uporabniki".

Uporabljamo opredelitev "število ljudi, ki so v vsakem trenutku vključeni v transakcijski tok ". To je ključno število, ki ga morate poznati za nastavitev stopnje čakalne vrste. To je število uporabnikov, ki si trenutno ogledujejo vaše spletno mesto. Število sočasnih sej je običajno nekoliko večje od števila sočasnih povezav ali sočasnih uporabnikov, saj so nekatere seje v procesu časovnega zamika, kar podaljša povprečno trajanje seje.

V nasprotju s številom hkratnih zahtevkov, ki je število zahtevkov HTTP, ki jih spletni strežnik obdeluje v vsakem trenutku. Veliko tehničnih strokovnjakov zelo zmedeno reče, koliko je hkratnih zahtevkov, ko rečejo, koliko je hkratnih uporabnikov.

Potem so tu še hkratne povezave (ali hkratne povezave TCP na ista vrata strežnika na kartici omrežnega vmesnika), kar je število vtičnic TCP/IP, odprtih na vratih strežnika ali zaledni storitvi v vsakem trenutku. Pri zahtevkih za strani bodo brskalniki privzeto pustili povezavo odprto, če bo stran zahtevala nadaljnje zahteve ali če bo uporabnik prešel na drugo stran. S tem se zmanjša število zahtevkov na sekundo za odpiranje novih povezav TCP/IP, zaradi česar je proces strežnika učinkovitejši. Časovni roki za te hkratne povezave se razlikujejo glede na brskalnik, in sicer od 60 sekund do nikoli zaprte povezave. Tudi vaš strežnik lahko samodejno zapre povezave po določenem obdobju brez dejavnosti. Na spletnih strežnikih Linux lahko s tem ukazom dobite število hkratnih povezav na ista vrata strežnika:

netstat -aenp | grep ":80 \|:443 " | wc -l

ki ga lahko preizkusite, če ste radovedni. Nekateri temu pravijo tudi "hkratni uporabniki", v resnici pa gre za hkratne povezave.

Če ponudnika gostovanja prosite, naj vam pove največje število hkratnih uporabnikov, ki jih upravlja vaš spletni strežnik (kolikšen je največji promet), vam bo verjetno dejansko navedel število hkratnih sej, hkratnih zahtevkov ali hkratnih povezav, in sicer iz preprostega razloga, ker ne pozna vašega povprečnega časa transakcije, števila strani v toku transakcije ali drugih informacij, na podlagi katerih bi lahko povedal, koliko hkratnih uporabnikov upravlja vaš spletni strežnik. Vse te številke imajo različne vrednosti.

Če od ponudnika gostovanja ali tehnične ekipe zahtevate informacije o največjih ravneh prometa, je zelo pomembno, da pojasnite, ali imajo v mislih hkratne uporabnike, hkratne seje, hkratne zahteve ali hkratne povezave.

Če to storite narobe, lahko pride do okvare spletnega mesta!

Zakaj. Vsaka stran je ena sama zahteva HTTP, vendar so tudi vse slike, skripte in druge datoteke, ki prihajajo iz vaše spletne aplikacije in jih brskalnik uporabi za prikaz strani, zahteve HTTP.

Predstavljajmo si, da vam je tehnična ekipa povedala, da strežnik podpira 500 hkratnih uporabnikov, vendar so v resnici mislili 500 hkratnih zahtevkov. Pri 5-minutnem času transakcije uporabite zgornjo formulo in predpostavimo, da lahko vaše spletno mesto podpira 100 obiskovalcev na minuto.

Ali je to mogoče? Ne.

Ko ljudje opravljajo transakcije, med nalaganjem posamezne strani od vaših strežnikov dejansko pošiljajo le zahteve. To vpliva na to, koliko prometa na sekundo ali aktivnih uporabnikov lahko prenese vaš strežnik. Od petminutnega časa transakcije je za povprečnega uporabnika to le nekaj sekund. Zato morda mislite, da 500 hkratnih zahtevkov pomeni, da lahko obravnavate veliko več hkratnih uporabnikov, vendar se morda motite. Ali zdaj vidite, kako zapleteno je razumevanje zmogljivosti vašega spletnega mesta v smislu, koliko prometa ali skupnega števila aktivnih uporabnikov?

najprej poskrbite za vire strežnika, ko ugotavljate, koliko zahtevkov lahko dobijo vaše spletne strani, da bo izkušnja za vsakega uporabnika dobra.

Pretvarjanje hkratnih zahtevkov v hkratne uporabnike

Da bi iz največjega skupnega števila hkratnih zahtevkov izračunali največje število hkratnih uporabnikov, morate vedeti tudi

  1. Število strani v toku transakcij
  2. Povprečni čas transakcije obiskovalca od prve do zadnje strani v vašem toku
  3. Koliko zahtevkov v povprečju sestavlja posamezno stran
  4. Povprečni čas, ki ga vaš strežnik potrebuje za obdelavo ene zahteve HTTP.

Verjetno že poznate 1) in 2) - v našem primeru je to 6 strani in 5 minut. Z lahkoto lahko preštejete strani, ki jih vidite med opravljanjem transakcije. Če ne poznate povprečnega časa transakcije, vam ga lahko pove Google Analytics ali pa preverite dnevnike spletnega strežnika.

Pri 3) in 4) si lahko pomagate z brskalnikom Firefox. Z desno tipko miške kliknite stran na svojem spletnem mestu, izberite možnost Inspect Element in zavihek Network (Omrežje). Nato pritisnite CTRL-SHIFT-R, da stran popolnoma osvežite. Na seznamu boste videli čase nalaganja v omrežju za vsak element strani. Prepričajte se, da lahko v stolpcu Preneseno vidite velikosti prenosa, saj se sicer datoteke lahko prikažejo iz predpomnilnika, kar lahko zmoti vaše izračune. Morda boste videli, da nekatere skripte in drugi viri prihajajo iz strežnikov, ki niso vaše spletno mesto, zato lahko v polje za filtriranje na levi strani vnesete ime domene svojega spletnega mesta. Če si želite ogledati stolpec Trajanje, z desno tipko miške kliknite katerikoli naslov stolpca in v priročnem meniju izberite Časovno obdobje -> Trajanje. Vaš zaslon mora biti videti takole:

Google obdeluje pravilno konfiguriran nginx z Google Analytics za nalaganje slik

Omrežni zavihek Firefoxa za to stran, ki prikazuje trajanje in število zahtevkov iz queue-fair.com

Datoteke, ki se uporabljajo pri prikazovanju strani, lahko prihajajo z različnih spletnih mest, zato lahko s filtrom v zgornjem levem kotu prikažete samo tiste z vašega spletnega mesta, vendar le, če ste prepričani, da te datoteke z drugih spletnih mest niso razlog za počasno nalaganje strani ali del ozkega grla.

Firefox v spodnjem levem kotu zaslona prešteje zahtevke in prikaže 36 zahtevkov HTTP samo za to stran.

To morate storiti za vsako stran v toku transakcij - preštejte skupno število in ga delite s številom strani, da ugotovite povprečno število zahtevkov HTTP za vsako stran (številka 3) na našem seznamu. Zdaj lahko vidite, zakaj je število otroških zahtevkov za vsako stran HTML tako ključen dejavnik za to, koliko prometa lahko prenese vaš spletni strežnik.

Pri številki 4) si oglejte stolpec Trajanje in poiščite povprečje vseh zahtevkov HTTP za vse svoje strani. Če niste prepričani, predvidevajte pol sekunde - pri tem je vseeno veliko negotovosti (glejte spodaj).

izračunavanje, koliko sej hkrati, koliko uporabnikov in koliko zahtevkov na sekundo je v vaši spletni aplikaciji, pa naj gre za en strežnik ali statično vsebino.

Izračunavanje

Navedimo nekaj primerov številk. Povedali smo že, da je v vzorčnem procesu strežnika šest dinamičnih strani, kar je 1), in da je povprečni čas transakcije pet minut, kar je 2). Predpostavimo 36 zahtevkov HTTP na stran za 3) in pol sekunde za čas strežniške obdelave vsakega zahtevka HTTP, kar je 4).

Če upoštevate te številke, lahko strežnik, ki lahko prenese 500 hkratnih zahtevkov, prenese 500 / (0,5 sekunde) = 1000 zahtevkov HTTP na sekundo, kar pomeni 60 000 zahtevkov HTTP na minuto, ko je njegova zmogljivost popolnoma izčrpana.

V petih minutah trajanja transakcije lahko opravi 5 * 60.000 = 300.000 zahtevkov HTTP. Zdi se veliko, kajne?

Vsak obiskovalec ima šest strani s povprečno 36 zahtevki HTTP na vsaki, torej 6 * 36 = 216 zahtevkov.

Tako lahko zmogljivost 300.000 zahtevkov HTTP teoretično prenese 300.000 / 216 = 1.389 hkratnih uporabnikov.

Gotcha #2: Spletni strežniki postajajo počasnejši zaradi obremenitve

Hej, to je super! Mislili smo, da lahko imamo samo 100 obiskovalcev v vrsti, vendar je 1 389 / 5 minut = 278 obiskovalcev na minuto, zato lahko imamo višjo stopnjo čakanja v vrsti!

Verjetno ne. Obiskovalci namreč ne bodo pošiljali zahtevkov v intervalih natanko pol sekunde, kot predvideva zgornji izračun. Še pomembneje pa je, da boste vhodne podatke merili, ko spletno mesto ne bo zasedeno. Smeti noter, smeti ven.

Ko je spletno mesto zasedeno, strežnik dlje obdeluje zahteve - to ste opazili tudi na drugih spletnih mestih, ko je veliko dela, saj na strani čakate dlje. S tem se podaljša povprečni čas, ki ga strežnik potrebuje za obdelavo ene zahteve HTTP (4), kar zmanjšuje največjo prepustnost. Zato vzemite 278 obiskovalcev na minuto in jih prepolovite. Nato ga še enkrat prepolovite. Pri največji obremenitvi verjetno realno pričakujete približno 70 novih obiskovalcev na minuto.

večja kot je obremenitev zaradi prometnih skokov, počasnejši so stroji.

Drugi dejavniki, ki vplivajo na to, so predpomnilnik, kar pomeni, da brskalnikom obiskovalcev ni treba opraviti vseh zahtevkov za vsako stran - to pomeni, da strežnik potrebuje manj virov in lahko poveča število novih obiskovalcev na minuto, ki jih strežnik lahko sprejme. Tudi naprave za uravnavanje obremenitve, ki porazdelijo obremenitev med več strežnikov, in serviranje statične vsebine namesto dinamičnih strani lahko pospešijo proces vašega strežnika, saj vsak strežnik potrebuje manj virov.

Ugotovili boste tudi, da vse strani ne trajajo enako dolgo, saj nekatere zahtevajo manj virov kot druge. Iskanje po zbirkah podatkov, iskalne poizvedbe in posodobitve trajajo najdlje, zato boste nekje v procesu imeli ozko grlo, kjer se bodo ljudje kopičili in čakali na obdelavo podatkov o kreditnih karticah in shranjevanje naročil ali na preverjanje razpoložljivosti. Vsak tok transakcij ima najpočasnejši korak, zato je vedno kje ozko grlo, in vedno obstaja odgovor na vprašanje, koliko sočasnih uporabnikov lahko prenese spletni strežnik, pri čemer je lahko omejitev več. V tem primeru želite nastaviti dovolj nizko stopnjo čakalne vrste, da zagotovite, da ima vaš strežnik časovno zmogljivost procesorja za hkratno obdelavo dovolj ljudi za najpočasnejši korak v vašem postopku, da se ljudje tam ne bodo kopičili. V nasprotnem primeru se lahko vaš spletni strežnik dobesedno ustavi.

negotovo, kako oceniti zmogljivost strežnikov strežniških virov za vsakega posameznega uporabnika.

Kaj naj storim?

Po naših izkušnjah pri prvi prodaji vsi precenjujejo sposobnost svojih strežnikov, da se spopadejo z velikimi količinami prometa.

Vsi.

Natančno določanje povprečnega trajanja seje in zmogljivosti končnega uporabnika med počasnim prometom ali prometno konico ni za ljudi s slabim srcem. Najbolje je izvesti ustrezen test obremenitve, pri čemer "lažne" stranke med testiranjem obremenitve dejansko opravijo postopek naročanja natančno tako kot v resničnem življenju, izvajajo enake zahteve HTTP v enakem vrstnem redu in z enakim čakanjem med stranmi pri testiranju obremenitve kot v resničnem življenju, ter spremljati obremenitev procesorja, prepustnost IO in odzivne čase, ko povečujete število virtualnih obiskovalcev. Za to lahko uporabite Apache JMeter (za manjše obremenitve ali počasnejše računalnike nam je všeč tudi K6 ), vendar je ne glede na orodje, ki ga uporabljate, zamudno in zahtevno posnemati obnašanje vsakega posameznega uporabnika na povsem pravilen način (zlasti zaradi zapletenosti predpomnilnika). Tudi v tem primeru vzemite največje število in ga prepolovite.

Če tega ni, se raje odločite za previdnost.

Hitrost čakalne vrste za katero koli čakalno vrsto Queue-Fair lahko kadar koli preprosto spremenite prek portala Queue-Fair. Začnite z 10 obiskovalci na minuto ali s stopnjo transakcij na bolj običajen dan, poglejte, kako bo nekaj časa po začetku prodaje vstopnic, in če je vse videti dobro, če je obremenitev procesorja majhna, če je podatkovna zbirka sql v redu in (predvsem) če so vaše strani odzivne, ko pritisnete CTRL-SHIFT-R, jo podvojite, počakajte nekaj časa in ponovite. Kmalu boste ugotovili dejansko hitrost, ki jo potrebujete med tem "uravnoteženjem obremenitve" (vidite, kaj smo naredili?), in ne pozabite, da je z vidika uporabniške izkušnje v redu, če povečate hitrost čakalne vrste, saj se zaradi tega zmanjšajo predvideni čakalni časi, ki jih vidijo vaše stranke v čakalni vrsti, in vsi so veseli, da odzivni čas zagotavlja krajši predvideni čakalni čas.

Ne smete nastaviti previsoke stopnje čakalne vrste in se nato znajti v položaju, ko jo morate znižati, saj to a) pomeni, da ljudje, ki uporabljajo spletno mesto, počasi nalagajo strani, in b) povzroči, da se ocenjeni časi čakanja povečajo. Vsi ljudje v čakalni vrsti bodo zavzdihnili!

Gotcha #3: prehitro povečanje stopnje po odprtju čakalne vrste

Ne pozabite, da bo v postopku naročanja nekje prišlo do ozkega grla - vsaka transakcija ima najpočasnejši korak - in tam se bo kopičilo več sej. Ne želite si, da bi po eni minuti prodaje vstopnic ugotovili, da je obremenitev procesorja vašega strežnika precej pod največjim številom, in zvišali hitrost. Vaši obiskovalci verjetno niso prišli niti do gumba "Kupi zdaj". Počakajte, da bo vaša podatkovna zbirka sql poročala o novih naročilih z enako ali podobno hitrostjo, kot je hitrost čakalne vrste, in takrat opravite meritve in preskuse odzivnosti. Ne pozabite, da bo vsakič, ko povečate hitrost, trajalo enako dolgo, da bodo dodatni obiskovalci dosegli ozko grlo, zato boste lahko natančno ocenili delovanje strežnika pri novi hitrosti šele po preteku tega časa.

upočasni odločitev o porabi strežniških virov.
strežniki se zaskočijo, ko je zmogljivost strežnikov presežena.

Gotcha #4: Odstranjevanje strežnikov

O tem, kako je najbolje postopno povečevati hitrost čakalne vrste, ko je čakalna vrsta odprta, smo že govorili. Verjetno se zavedate, da imajo vaši strežniki določeno mejo, ki je ni mogoče preseči, ne da bi se sistem zrušil, in morda celo veste, kakšna je ta meja - morda pa ne veste, da se obremenitev približuje tej meji, vendar je običajno zelo malo znakov - pogosto le nekaj napak ali opozoril ali obremenitev procesorja nad 80 %.

Kadar spletne storitve odpovejo, se običajno zelo hitro "zlomijo" ali zaustavijo. To se običajno zgodi zato, ker sistem ne more več obdelovati zahtevkov tako hitro, kot prihajajo, in se ustvarijo notranje čakalne vrste za obdelavo. Vaš sistem mora nato poleg zahtevkov obdelovati, upravljati in shranjevati tudi svoje notranje čakalne vrste, in to je tisto, kar strežnike spravi čez rob. Zelo hitro. Ko se to zgodi, se lahko vaši strežniki za nekaj časa odzovejo s stranjo z napako, vendar vam to ne pomaga, saj obiskovalci, ki jo vidijo, takoj pritisnejo gumb Osveži, s čimer se obremenitev še poveča.

Zato na strežnike ne pritiskajte bolj, kot je treba. Iskanje zadnjih 20 % zmogljivosti procesorja običajno ni vredno tveganja. Če se velikost čakalne vrste, prikazana na portalu Queue-Fair (rumena številka in črta Čakanje v grafikonih), iz minute v minuto zmanjšuje ali celo počasneje povečuje, prikazani čas čakanja pa je 50 minut ali manj, potem naročila obdelujete dovolj hitro in se bo čakalna vrsta sčasoma samodejno izpraznila in prenehala prikazovati strani čakalne vrste, ne da bi vam bilo treba kar koli storiti in ne da bi morali šefu povedati, da ste preveč pritiskali in jo pokvarili. To vam bo sčasoma uspelo, dokler je hitrost sprednjega dela čakalne vrste večja od števila pristopov vsako minuto (oboje je prikazano na portalu Queue-Fair) - prelomna točka je običajno vsaj nekaj minut po vsakem dogodku. Če prodajate izdelek z omejeno količino, ga boste verjetno prodali, še preden bo dosežena točka preobrata.

Dobra novica je, da vam lahko Queue-Fair pomaga hitro vzpostaviti delovanje, če slučajno nastavite previsoko hitrost čakalne vrste in se strežniki zlomijo - čakalno vrsto samo zadržite, dokler strežniki niso pripravljeni ponovno sprejemati obiskovalcev. V načinu zadržanja se ljudem v čakalni vrsti prikaže posebna stran za zadržanje, ki jo lahko oblikujete pred spletnim dogodkom. Ko je čakalna vrsta zadržana, nihče ni prepuščen s sprednje strani čakalne vrste, vendar se lahko novi spletni obiskovalci še vedno pridružijo čakalni vrsti na zadnji strani in se pošteno razvrstijo, ko se blokada odpravi, kar se bo zgodilo zelo hitro, saj Queue-Fair ščiti vaše spletno mesto pred povpraševanjem. Stran za zadržanje je boljša uporabniška izkušnja kot nastavitev stopnje čakalne vrste na zelo nizko raven, zlasti če jo posodobite tako, da obiskovalcem sporočite, kdaj pričakujete, da se bo čakalna vrsta ponovno odprla, kar je enostavno storiti z urejevalnikom strani portala, tudi če je v čakalni vrsti že več sto tisoč ljudi - in v načinu zadržanja jih lahko z edinstvenim gumbom Queue-Fair Admit One celo spustite po enega naenkrat, če je treba, medtem ko si vaš sistem opomore od zastoja.

Če se zgodi, da morajo vaši strežniki med dogodkom prekiniti, je stran Zadržanje točno to, kar potrebujete, poleg tega pa vam bo pomagala pri hitrejšem okrevanju strežnikov.

Zaključek

V tem članku smo razložili, zakaj je čakalna vrsta, ki temelji na stopnji, vedno prava pot naprej, in navedli dve metodi za izračun potrebne stopnje, vendar je naš nasvet vedno enak, razen če ste opravili popolno in natančno testiranje obremenitve virtualnih obiskovalcev za celoten tok transakcij in ste o tem res super ekstra ekstra mega prepričani:

  1. Najprej nastavite stopnjo čakalne vrste na 10 ali stopnjo transakcij na običajen dan.
  2. Spremljajte obremenitev procesorja in druge kazalnike zmogljivosti.
  3. Počakajte, da se nova naročila zabeležijo v podatkovno bazo sql z enako ali podobno hitrostjo, kot je hitrost čakalne vrste.
  4. Na straneh pritisnite CTRL-SHIFT-R in preverite odzivnost.
  5. Povečajte hitrost čakalne vrste za največ 20 %.
  6. Vrnite se na korak 2 in ponovno počakajte.
  7. Ko se velikost čakalne vrste zmanjšuje ali se vsako minuto manj hitro povečuje in je prikazani čas čakanja krajši od 50 minut, ni treba, da bi bil hitrejši.
  8. Sedite in se sprostite! Queue-Fair vas je poskrbel.

Če prodajate izdelek v omejeni količini, vam tudi ni treba biti pozorni na korak 7.

To velja za prvo čakalno vrsto, ko ne poznate dejanske največje hitrosti čakalne vrste, ki jo lahko podpira vaš sistem. Za naslednje čakalne vrste, ko izmerite hitrost čakalne vrste, ki jo vaš sistem dejansko lahko prenese, boste morda lahko ponovno uporabili isto vrednost - vendar le, če se v vašem sistemu ni nič spremenilo. V praksi se vaš sistem verjetno nenehno razvija in spreminja in morda ne veste, kako so nedavne spremembe vplivale na največjo hitrost čakalne vrste - zakaj torej ne bi začeli pri polovici prejšnje izmerjene vrednosti in ponovili zgornji postopek?

Ne pozabite, da je vedno bolje biti varen, kot pa se opravičevati.


Več sto vodilnih organizacij zaupa našim
rešitvam za čakalne vrste

Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6

Enostavna rešitev za povečanje internetnega prometa

Začnite z delom