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.
Tradicionalno so strežniki za elektronsko poslovanje opremljeni tako, da podpirajo največje število hkratnih uporabnikov, in obremenitev je pogosto opredeljena na ta način. Pri uporabi tega pristopa za vodenje čakalne vrste za spletno mesto obstaja težava - to težavo rešujemo s stopnjami.
Težava nastane, ker obiskovalci dejansko uporabljajo spletni strežnik le, ko njihov brskalnik nalaga vsako spletno stran.
Recimo, da spletno mesto za e-trgovino prodaja vstopnice. Od začetka poti obiskovalca do konca poti obiskovalca (seje uporabnika) je šest strani, saj obiskovalec
Celoten postopek transakcije v povprečju traja pet minut.
Recimo, da vsako minuto pride 100 obiskovalcev, ki želijo kupiti vstopnice, povprečni čas za dokončanje postopka pa je pet minut. V vsakem trenutku je v postopku transakcije hkrati 500 ljudi in strežnik mora biti opremljen za podporo 500 hkratnih uporabnikov.
Lahko bi si mislili, da bi lahko ustvarili števec hkratnih uporabnikov, ki se poveča vsakič, ko na domačo stran pride nov obiskovalec, in zmanjša vsakič, ko obiskovalec zaključi transakcijo, ter da bi tako ugotovili, koliko uporabnikov v vsakem trenutku obravnava en strežnik, vendar to ne bo delovalo.
To ne bo delovalo, ker vsak obiskovalec ne opravi transakcije. Ljudje si premislijo, jih nekaj zmoti ali pa odidejo in se vrnejo pozneje. Ker spletni strežnik komunicira z obiskovalci le, ko njihovi brskalniki nalagajo strani, ne more vedeti, kdaj se je to zgodilo in komu.
Namesto tega mora posamezni strežnik, če želi ugotoviti, da obiskovalec ni več del postopka transakcije, počakati, da od tega obiskovalca ne pride več zahtevkov za stran, in nato prekiniti sejo tega obiskovalca. Časovno omejitev je treba vedno nastaviti na veliko daljši čas, kot je povprečni čas transakcije (v tem primeru na primer 20 minut), saj nekateri obiskovalci za dokončanje transakcije potrebujejo veliko več časa kot drugi.
Na ta način bi lahko dodali možnost, da se vsakič, ko seja obiskovalca preneha, zmanjša tudi teoretični števec za istočasne uporabnike, vendar to daje zelo slabe rezultate.
Če 10 % od 100 obiskovalcev, ki pridejo vsako minuto, ne zaključi transakcije, bodo obiskovalci, ki jo zaključijo, v povprečju aktivni pet minut, tisti, ki je ne zaključijo, pa bodo vedno aktivni vsaj 20 minut (pri upoštevanju več sej je dejansko bolj verjetno, da bo časovna omejitev seje plus povprečno trajanje seje).
To je 90 * 5 + 10 * 20 = 650 in strežnik bo sporočil 650 hkratnih uporabnikov, čeprav je dejansko manj zaseden!
Poleg tega kar 10 * 20 = 200 sočasnih uporabnikov dejansko ne uporablja spletnega mesta in je v postopku prekinitve, kar je več kot 30 % prijavljenih sočasnih uporabnikov, čeprav je le 10 % obiskovalcev, ki ne dokončajo transakcije.
Recimo, da želite na to spletno mesto dodati čakalno vrsto, ki jo nadzoruje naš števec za istočasne uporabnike. Ko je zmogljivost spletnega mesta dosežena, bo posameznik, ki je na čelu čakalne vrste, na spletno mesto prepuščen šele, ko se števec zmanjša. To se imenuje čakalna vrsta ena-iz-ena-in. V 30 % primerov bo oseba na začetku čakalne vrste čakala, da nekdo, ki ne bo dokončal svoje transakcije, ne bo dokončal svoje transakcije.
Poleg tega je potrebno dodatno tehnično povezovanje in obremenitev spletnega mesta zaradi ustvarjanja in delovanja števca ter izmenjave teh informacij s sistemom čakalnih vrst. Če mehanizem za izmenjavo ali štetje odpove ali se pokvari, se čakalna vrsta zatakne. Še huje, če je posamezni strežnik tako zaseden, da ne more posodobiti strežnika čakalne vrste in mu sporočiti, naj spusti naslednjo osebo, se tudi čakalna vrsta zatakne.
Vse te težave lahko preprosto in enostavno rešite tako, da namesto tega pošiljate obiskovalce s sprednje strani čakalne vrste s stalno, fiksno hitrostjo - v tem primeru 100 obiskovalcev na minuto.
Tako ni treba meriti dejanskega števila sočasnih uporabnikov, ni potrebe po zapleteni integraciji s spletnim mestom za prodajo vstopnic in ni nevarnosti, da bi se čakalna vrsta zataknila.
Zato smo leta 2004 izumili in patentirali virtualno čakalnico za zasedena spletna mesta, ki temelji na ceni.
Neverjeten in enostaven izdelek! Queue-Fair je res lep. Tako enostavno je nastaviti parametre v realnem času in tako enostavno ga je tudi integrirati. Podpora je odzivna in prijazna. Virtualno čakalnico sem nastavil v 15 minutah, vključno z nastavitvami! S Queue-Fair tako svojo infrastrukturo ščitim pred vsemi temi prometnimi konicami.
Vaša programska oprema je poskrbela, da so bili vsi uvrščeni v čakalno vrsto stran od našega strežnika, in omogočila blag pretok kupcev skozi sistem. Bilo je odlično! To bi bilo zelo koristno za vsako spletno trgovino, ki ima naval kupcev. Najlepša hvala in še naprej dobro delajte!
Odlično! Zelo smo srečni in zadovoljni s Queue-Fair, čudovito je imeti to raven podpore. Storitev deluje odlično - v kratkem času smo prodali na tisoče vstopnic, Queue-Fair pa nam je pomagal upravljati promet v času največjih konic! Družbo Queue-Fair priporočamo tudi našim storitvenim partnerjem. Res sem zadovoljen!
Ljudje iz Queue-Fair so nam v enem dnevu pomagali uvesti njihov sistem čakalnih vrst. Z več kot 25.000 ljudmi v čakalni vrsti so nam pomagali upravljati promet v času največjih konic. Queue-Fair počne to, kar je njegov namen: postavlja ljudi v vrsto po konkurenčni ceni. S sistemom Queue-Fair smo zadovoljni in ga bomo uporabljali tudi na prihodnjih dogodkih.
Queue-Fair je bil prav tisto, kar smo potrebovali za upravljanje prometa in podporna služba je odlična!. Sistem je deloval zelo dobro! Iskali smo več podjetij in brez dvoma smo našli najboljše! Najlepša hvala, Queue-Fair!
Velika hvala za tako hitro obračanje naše poizvedbe. V sredo ob 21.00 smo poslali e-pošto, v četrtek ob 11.00 pa prejeli popolnoma oblikovano stran čakalne vrste, pripravljeno za uporabo. Preprosto odlično! Nadzorna plošča in funkcije so odlične - res intuitivne, pregledne in enostavne za uporabo. Za naš dogodek ob predstavitvi izdelka smo v čakalno vrsto postavili več kot 22 000 ljudi, cena pa je bila izjemno konkurenčna. Najlepša hvala za vse! Res sem vesel, da lahko podjetju Queue-Fair podam bleščeče pričevanje, in bi ga priporočil vsem podjetjem, ki potrebujejo sistem čakalnih vrst za svoj dogodek ali promocijo.
Č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
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.
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!
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.
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.
Č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.
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.
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?
Da bi iz največjega skupnega števila hkratnih zahtevkov izračunali največje število hkratnih uporabnikov, morate vedeti tudi
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:
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).
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.
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.
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.
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, posnemanje obnašanja vsakega posameznega uporabnika na povsem pravilen način zamudno in težavno (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 pri 10 obiskovalcih na minuto ali stopnji transakcij na 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 baza sql v redu in (predvsem) če so vaše strani odzivne, ko pritisnete CTRL-SHIFT-R, jo povečajte za največ 20 %, počakajte nekaj časa in ponovite. Kmalu boste ugotovili dejansko stopnjo, 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 zvišate stopnjo č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!
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.
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.
Če obiskovalci potrebujejo več kot eno sekundo, da se jim prikažejo vaše strani, še pred tem pritisnejo gumb Osveži. Ko obiskovalec pritisne osvežitev, spletni strežnik ne ve, da obiskovalec ne čaka več na odgovor na prvotno zahtevo. Če sta prejeti tako prvotna kot osvežitvena zahteva, bo spletni strežnik obdelal obe. To pomeni več dela za vaš spletni strežnik, še počasnejše odzive za vse vaše obiskovalce in več ljudi, ki pritisnejo osvežitev, kar povzroči začaran krog, ki vaš spletni strežnik uniči, še preden začne pošiljati odgovore na napake.
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.
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:
Č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?
Tako lahko s Queue-Fair poskrbite za lepo in varno prodajo, pri čemer ne pozabite, da je vedno bolje biti varen kot žalosten.
2024 The Fair Queue People Ltd. - Vse pravice pridržane.
Del družine rešitev za čakalne vrste Orderly - OrderlyQ - OrderlyStats - WeQ4U
