Me ei leidnud tegelikult ühtegi plussi, et üks välja, üks sisse. Lühidalt öeldes seisneb selle lähenemisviisi probleem selles, et kui kasutajad on e-kaubanduse veebisaitide külastajad, ei tea veebiserver, mitu samaaegset kasutajat tal igal ajahetkel on. See on showstopper. Siin on põhjus.
Hiljem selles artiklis räägime ka sellest, kuidas kasutada oma saidi kaitsmiseks ka määrapõhist virtuaalset ruumi.
Traditsiooniliselt on e-kaubanduse serverid seadistatud nii, et need toetaksid maksimaalset arvu samaaegseid kasutajaid, ja koormus on sageli määratletud sel viisil. Sellise lähenemisviisi kasutamisel veebisaidi järjekorra käivitamisel on probleem - probleemi lahendame tariifidega.
Probleem tekib seetõttu, et külastajad kasutavad veebiserverit tegelikult ainult siis, kui nende brauser laadib iga veebilehte.
Oletame näiteks, et üks e-kaubanduse sait müüb pileteid. Külastaja teekonna algusest kuni selle lõpuni (kasutaja sessioon) on kuus lehekülge, sest külastaja on
Kogu tehinguprotsess võtab keskmiselt viis minutit.
Oletame, et näiteks 100 külastajat saabub iga minut pileteid ostma ja keskmine aeg protsessi lõpuleviimiseks on viis minutit. Igal ajahetkel on tehinguprotsessis samaaegselt 500 inimest ja server peab olema ette nähtud 500 samaaegse kasutaja toetamiseks.
Võiks arvata, et võiks luua samaaegsete kasutajate loenduri, mida suurendatakse iga kord, kui uus külastaja saabub kodulehele, ja vähendatakse iga kord, kui külastaja lõpetab tehingu, ning et see ütleks, kui palju kasutajaid üks server korraga käsitleb, kuid see ei toimi.
See ei toimi, sest mitte iga külastaja ei vii tehingut lõpule. Inimesed muudavad meelt või segavad end või lähevad ära ja tulevad hiljem tagasi. Kuna veebiserver suhtleb külastajatega ainult siis, kui nende veebilehitsejad laadivad lehti, ei saa veebiserver kuidagi teada, millal ja kellega see on juhtunud.
Selle asemel, et teha kindlaks, et külastaja ei osale enam tehinguprotsessis, peab üksik server ootama, et näha, kas sellelt külastajalt ei tule enam ühtegi lehepäringut, ja seejärel lõpetama selle külastaja seansi. Aegumistähtajad tuleb alati määrata palju pikemaks kui keskmine tehingu aeg (näiteks 20 minutit selles näites), sest mõnedel külastajatel võtab tehingu lõpuleviimine palju kauem aega kui teistel.
Võiks lisada võimaluse vähendada ka oma mõttelist samaaegse kasutaja loendurit iga kord, kui külastaja sessioon aegub, kuid see annab väga halbu tulemusi.
Kui 10 % 100 külastajast, kes saabuvad iga minut, ei vii tehingut lõpule, siis need, kes viivad tehingu lõpule, on keskmiselt viis minutit aktiivsed ja need, kes ei vii tehingut lõpule, loetakse alati aktiivseks vähemalt 20 minutit (tegelikult on sessiooni aegumine pluss keskmine sessiooni kestus tõenäolisem, kui arvestada mitut sessiooni).
See on 90 * 5 + 10 * 20 = 650, ja server teatab 650 samaaegset kasutajat, kuigi tegelikult on ta vähem hõivatud!
Lisaks sellele ei kasuta 10 * 20 = 200 neist samaaegsetest kasutajatest tegelikult saiti ja on välja lülitunud, mis on üle 30% teatatud samaaegsetest kasutajatest, kuigi ainult 10% külastajatest ei lõpeta tehingut.
Oletame, et sellele veebisaidile soovitakse lisada järjekord, mida kontrollib meie samaaegsete kasutajate loendur. Kui sait on täitunud, siis saab järjekorra eesotsas olev inimene saiti alles siis, kui loendur väheneb. Seda nimetatakse ühe välja-ühe sisse järjekorrana. Mis juhtub, on see, et 30% ajast ootab järjekorra eesotsas olev isik, et keegi, kes ei kavatse oma tehingut lõpule viia, ei lõpeta oma tehingut.
Lisaks sellele tuleb teha täiendavat tehnilist integreerimistööd ja koormata veebisaiti, et luua ja käivitada loendur ning jagada seda teavet järjekorrasüsteemiga. Kui jagamise või loendusmehhanism läheb katki või läheb katki, jääb järjekord kinni. Veelgi hullem on see, et kui üksik server on nii hõivatud, et ta ei suuda järjekorraserverit uuendada, et öelda järjekorraserverile, et ta laseks järgmise inimese sisse, siis jääb ka järjekord kinni.
Kõik need probleemid on hõlpsasti ja lihtsalt lahendatavad, kui külastajad saadetakse selle asemel järjekorra esiplaanile konstantse, fikseeritud kiirusega - antud juhul 100 külastajat minutis.
Nii ei ole vaja mõõta samaaegsete kasutajate tegelikku arvu, ei ole vaja keerulist integratsiooni piletimüügi veebisaidiga ega ohtu, et järjekord jääb kinni.
Seepärast leiutasime ja patenteerisime 2004. aastal hõivatud veebisaitide jaoks virtuaalse ooteruumi, mis põhineb tariifil.
‘Stressitõrjerakendus! Me teadsime, et uue e-valitsuse teenuse kaudu, mille me käivitasime, tekib taotluste tulv. Tahtsime kasutada järjekorda pidevalt kaitseks. Queue-Fair pakkus meile kaubamärgiga järjekorra lehekülje ja lihtsasti kasutatavaid vahendeid meie ooteruumi kohandamiseks ja haldamiseks. Nende tugi oli suurepärane ja nendega oli meeldiv suhelda. Queue-Fair oli pidevalt meie jaoks olemas ja meie jaoks on oluline, et me saime tõepoolest vajaliku teenuse. Täname teid Queue-Fair!’
‘Me töötame koos mõne suurima brändiga ning sellega kaasneb suur nõudlus müügi- ja müügitööde ajal. Vajame õiglast järjekorra platvormi, et pakkuda kõigile klientidele õiglast ja valutut kogemust meie platvormiga suhtlemisel. Queue-Fair-d ei olnud mitte ainult väga lihtne rakendada - ühe päevaga! - ja toimis sujuvalt, vaid ka meeskond mõistis meie vajadusi ja suutis meiega koos töötada, et saavutada meie eesmärgid.’
‘Viie tärni Queue-Fair arvustus! Meeskond on äärmiselt professionaalne ja lahke, väga täpne ja kliendi vajaduste suhtes täpne. Ausalt öeldes saame igas aspektis hästi läbi. Queue-Fair on oluline vahend paljude osalejatega ürituste haldamiseks.’
‘Queue-Fair on ausalt öeldes hämmastav toode - väga soovitatav. Ma soovin, et me oleksime varem vahetanud! Kogu protsess kuni rakendamiseni oli üks sujuvamaid protsesse, mida ma olen kunagi kogenud. Queue-Fair-l on lisafunktsioone, mida meie eelmine tarnija ei suutnud saavutada, nii et üleminek oli lihtne. Kõik, kes otsivad järjekorra toodet, ei tohiks enam edasi otsida. Me armastame seda!’
‘Suurepärane tööriist päästis meie kaupluse. Klienditeenindus on väga hea. Queue-Fair lahendab meie jaoks serveri küllastumise hõivatud piletimüügi puhul. Seadistamine oli lihtne ja mulle meeldis tööriista tõhusus.’
‘Äärmiselt hea toode liikluskorralduseks. Meil oli vaja sujuvat kasutajakogemust esimestel käivitamispäevadel, mis oli saavutatav ainult Queue-Fair lisamisega. Meile meeldis, kui lihtne oli Queue Fairi seadistamine mitmes keeles. Koodide kohandamisvõimalused olid suurepärased ja me ühtlustasime ooteruumi meie kujundussüsteemiga. Ka tugi oli kogu aeg äärmiselt abivalmis. Väga soovitatav. Queue-Fair tegi oma tööd suurepäraselt.’
‘Hämmastav ja lihtne toode! Queue-Fair on tõesti ilus. Nii lihtne määrata parameetrid reaalajas ja seda on nii lihtne integreerida ka. Tugi on reaktiivne ja sõbralik. Sain virtuaalse ooteruumi üles seatud 15 minutiga koos seadistustega! Nii et ma kaitsen oma infrastruktuuri kõigi nende liikluse tippude eest Queue-Fair-ga.’
‘Queue Fair on töökindel ja kasutajasõbralik lahendus külastajate arvu oodatavate ja ootamatute tippude käsitlemiseks. Juhendamine ja suhtlemine meeskonnaga oli väga meeldiv; meie küsimustele vastati kiiresti. On rahustav teada, et me saame alati rakendada juhtimismeetmeid, aktiveerides Queue Fairi, et tulla toime ootamatult suure külastajate arvuga. Queue-Fair kasutamisel ei ole mingeid puudusi.’
‘Queue-Fair on elupäästja! Töö alustamine nendega oli kiire ja lihtne. Niioo kiire ja lihtne - 2 sammu 1 päev! Massiivsed eelmüügiüritused panid meie saidi varem kokku kukkuma, nüüd saavad inimesed virtuaalsesse ritta - väga tõhus. Soovitan Queue-Fair-d ka teistele, kahtlemata!’
‘Peale süsteemi enda, mis töötab väga hästi, eristub Queue-Fair teistest ka selle taga olevate inimeste poolest. Nad olid olemas, et vastata kõigile minu küsimustele, et aidata mind rakendamisel ja isegi siis, kui ma olin valmis tootmisse minema, olid nad ikka veel olemas! Ma võin rahulikult puhata, teades, et tippnõudlus ei tekita minu süsteemis enam probleeme. Kõik on täiuslik!’
‘Queue-Fair oli just see, mida me vajasime liikluse haldamiseks ja tugiteenus on suurepärane!. Süsteem on töötanud väga hästi! Otsisime mitu ettevõtet ja kahtlemata oleme leidnud parima! Suur tänu, Queue-Fair!’
‘Hämmastav tugi, kõik toimib kohe algusest peale. Queue-Fair aitab meil vähendada suurt nõudlust meie veebisaidil, vältides selle kokkuvarisemist. Käivitamise sammud olid oodatust palju lihtsamini ja tugi on olnud fenomenaalne. Dokumentatsioon on väga selge ja ülevaatlik. Ootejärjekorra käivitamise ajal ei tuvastatud mingeid probleeme. Üldiselt on see meie jaoks ideaalne lahendus. Kõik on olnud suurepärane.’
Kui te teate, kui palju samaaegseid kasutajaid veebiserver töötleb ja kui pikk on tehingu keskmine kestus või külastuse kestus alates tehinguvoo esimesest leheküljest kuni tellimuse kinnitamise leheküljeni, saate selle teisendada Queue Rate'iks, kasutades Little'i seadust, jagades kasutajate arvu kestusega, näiteks nii:
Ootejärjekorra kiirus = samaaegsed kasutajad / tehingu aeg
Queue-Fair toimetab külastajad teie veebisaidile teie poolt määratud kiirusega - meil on kaugelt kõige täpsem järjekorra AI, mis tagab, et soovitud külastajate arv iga minut on see, mida te iga minut saate, võttes automaatselt arvesse inimesi, kes ei ole kohal, kui nende kord on kutsutud, samuti inimesi, kes tulevad tagasi hilinemisega.
Kuidas see väljendub samaaegsete kasutajate arvus? Loomulikult ei võta iga külastaja, kes teie saidile jõuab, täpselt sama palju aega, et oma tehing lõpule viia, kuid suurte arvude seaduse tõttu saate Queue-Fair abil väga püsiva arvu samaaegseid kasutajaid.
Oletame näiteks, et teie järjekorra määr on 100 külastajat minutis. Me saadame teie saidile 100 külastajat iga minut ühtlase vooguna - see on see, mida me teeme, ja me oleme selles hämmastavalt head. Ütleme ka, et inimesed kasutavad teie veebisaiti keskmiselt (keskmiselt) viis minutit, kusjuures 70% neist kulub 4 kuni 6 minutit alates hetkest, mil nad järjekorrast mööduvad, kuni hetkeni, mil nad teevad oma viimase lehepäringu (olenemata sellest, kas nad viivad tehingu lõpule või mitte). See tähendab, et standardhälve on üks minut mõlemal pool keskmisest. Statistiliselt tähendab see, et iga külastaja kohta, kellel kulub viis ja pool minutit, leidub teine, kellel kulub neli ja pool minutit, ning need erinevused üksikute külastuste kestuses mitme seansi lõikes kipuvad seega üksteist neutraliseerima, kui te loete palju neid kuidagi. Suurte arvude seadus ütleb, et see tühistamine muutub seda täpsemaks, mida suurem on kaasatud inimeste arv.
Kui täpselt? Me saame selle välja töötada väikese statistika abil. Valimi suurus on 5 * 100 = 500, mis on siinkohal suur arv. Nii palju inimesi te loete. See tähendab, et tehingu aja keskväärtuse standardviga on 1 (standardhälve, 1 minut) jagatud valimi suuruse ruutjuurega (seega 500 ruutjuurega) vastavalt keskväärtuse standardvea statistilisele valemile, mis annab tehingu aja keskväärtuse standardveaks 0,044 minutit ehk kõigest 2,7 sekundit, mis on vähem kui üks protsent.
See tähendab, et kui järjekorra määr on 100 ja tehingu aeg on 5 minutit pluss või miinus minut iga üksiku külastaja kohta, siis peaksite ootama 495-505 samaaegset kasutajat teie saidil umbes 70% ajast, nii et matemaatika ütleb, et kiirusel põhineva järjekorra kasutamine tagab teie veebiserveritele soovitud väga püsiva koormuse.
Aga kas matemaatika on täpne? Siin on mõningaid nüansse - näiteks ei ole valimi suurus, mida me rõõmsalt ruudustame, iga kord, kui samaaegseid kasutajaid loendatakse (st igal ajahetkel), alati täpselt 500, ja ka normaalne (Gaussi) jaotus võib anda negatiivseid tehinguaegu, mida tegelikus elus ei esine. Niisiis, me kasutame külastajate kaupa, sekundi kaupa simulaatorit, et teha mõõtmisi selliste arvutuste kontrollimiseks, ja see ütleb meile, et ülaltoodud arvude puhul peaksite 70% ajast ootama 493-507 külastajat, nii et matemaatika peab märkimisväärselt hästi paika! Andmete mõõtmine ütleb meile ka, et teie saidil on vähemalt 95% ajast 500 ± 15 samaaegset kasutajat.
See on tõenäoliselt stabiilsem kui täpsus, millega teie veebiserver suudab mõõta teie veebilehe kasutajate arvu! Veelgi parem on see, et isegi kui te ei tea, milline on teie külastajate keskmine tehinguaeg või standardhälve, on need matemaatilised suurused olemas, olenemata sellest, kas te teate neid või mitte, ja te saate niikuinii stabiilse koormuse.
Tulemuseks on see, et Queue-Fair annab soovitud külastajate arvu minutis peaaegu täiusliku täpsusega, mille tulemuseks on väga stabiilne samaaegsete kasutajate arv teie saidil ja stabiilne veebiserveri koormus, mille üle teil on täielik kontroll.
Hurraa!
Ja nüüd hoiatus. Tasub märkida, et samaaegsete kasutajate arvu stabiilsus teie saidil - ja seega teie serveri koormuse stabiilsus - sõltub kriitiliselt sellest, kui täpselt teie virtuaalse ooteruumi teenusepakkuja saadab teile iga minut soovitud külastajate arvu, ja seetõttu on see võtmetegur virtuaalse ooteruumi platvormi valimisel. Kuna me pakume kõige täpsemat Virtual Waiting Room'i maailmas, ei peata keegi teie serverite üleujutusi paremini kui Queue-Fair.
Mis siis, kui te ei tea, kui palju samaaegseid kasutajaid server suudab käsitleda või kui palju tehinguaega? Võite vaadata lehte, mis tõenäoliselt on teie kitsaskoht - tavaliselt see, mis on "Osta kohe" nupule klõpsamise tulemus. Kasutage Google Analyticsit, et leida selle lehe igakuised unikaalsed külastajad või loendage oma igakuiseid tellimusi. Jagage see 30 * 24 * 60 = 43 200, mis on minutite arv kuus (ligikaudu). See on teie keskmine külastajate arv minutis kogu kuu jooksul. Korrutage see kolmega. See on teie keskmine külastajate arv minutis tööajal (ligikaudu). Tihendage see kahekordseks. See on tõenäoliselt turvaline arv, mida saab kasutada järjekorra määrana.
Oletame näiteks, et te töötlete 100 000 tellimust kuus - see tähendab 100 000 "Osta kohe" nupu klikke. See on 100 000 / 43 200 = 2,31 tellimust minutis. Eeldate, et enamik neist tellimustest tehakse päeval ja teie serverid on öösel vaiksemad, seega korrutage see 3 ja see on 7 tellimust minutis, mis on ligikaudne hinnang, kui hõivatud on teie server tööajal. Kui saadud arv on väiksem kui 50: nõudluses on tippude ja madalseisude aeg, nii et kui teie server ei ole tipptundidel märgatavalt aeglane, korrutage see 2ga, et saada 14 aktiivset kasutajat minutis. Kui arv on suurem kui 50: minutiliste tippude ja madalseisude arv on võrreldes sellega väiksem ja selle kahekordistamine ei ole ohutu. See arv, millele te lõpuks jõuate, on tõenäoliselt ohutu arv Queue Rate'i jaoks, millega alustada, ja vastab sellele, kui palju päringuid sekundis saate ohutult hallata; te võite seda alati suurendada, kui leiate, et teie süsteemid reageerivad lõppkasutajate jõudlusele selle kiiruse juures veel hästi.
Kui teie tellimused on ajatempliga, saate vaadata ka maksimaalset tellimuste arvu, mille olete viimase kuu jooksul ühe minuti jooksul võtnud - kuid kasutage seda ettevaatlikult, sest te ei tea, kui palju tellimusi te selle minuti jooksul olete serverite aeglustumise tõttu langenud, seega vähendage seda 20% võrra.
Selle artikli ülejäänud osas käsitletakse mõningaid muid viise, kuidas järjekorra kiirust välja arvutada.
Väärib märkimist, et üldkasutuses on vähemalt kaks "samaaegsete kasutajate" määratlust.
Me kasutame määratlust "tehinguvoos osalevate inimeste arv igal ajal". See on võtmenumber, mida on vaja teada, et määrata järjekorra määr. See on see, kui palju kasutajaid vaatab teie saiti praegu. Samaaegsete seansside arv on tavaliselt mõnevõrra suurem kui samaaegsete ühenduste või samaaegsete kasutajate arv, sest osa seansse on ajastusprotsessis, mis suurendab seansi keskmist kestust.
Vastupidiselt sellele, kui palju on samaaegseid päringuid, mis on teie veebiserveri poolt korraga töödeldavate HTTP-päringute arv. Väga segadust tekitav on see, et paljud tehnikainimesed mõtlevad, kui nad ütlevad, mitu samaaegset taotlust, kui nad ütlevad, mitu samaaegset kasutajat.
Siis on veel Concurrent Connections (ehk samaaegsed TCP-ühendused samale serveripordile teie võrgukaardil), mis on teie serveripordil või backend-teenusel korraga avatud TCP/IP-sokkide arv. Lehekülje päringute tegemisel jätavad brauserid vaikimisi ühenduse avatuks, juhul kui lehe poolt tehakse täiendavaid päringuid või kui kasutaja läheb teisele lehele. See vähendab uute TCP/IP-ühenduste avamiseks tehtavate päringute arvu sekundis, muutes serveriprotsessi tõhusamaks. Nende samaaegsete ühenduste aegumistähtajad varieeruvad brauserite kaupa, alates 60 sekundist kuni mitte kunagi sulgemiseni. Teie server võib automaatselt sulgeda ühendusi ka pärast tegevusetuse perioodi. Linuxi veebiserverites saate selle käsuga teada, kui palju on samaaegseid ühendusi samale serveripordile: netstat -aenp | grep ":80 \|:443 " | wc -l
mida võite proovida, kui olete uudishimulik. Jällegi, mõned inimesed nimetavad seda ka "Concurrent Users", kuigi tegelikult tähendab see samaaegseid ühendusi.
Tõepoolest, kui te palute oma veebimajutuse pakkujal öelda teile maksimaalset samaaegsete kasutajate arvu, mida teie veebiserver suudab käsitleda (kui palju tipptasemel liiklust), siis nad tõenäoliselt annavad teile tegelikult üheaegsete seansside, üheaegsete päringute või üheaegsete ühenduste arvu, sel lihtsal põhjusel, et nad ei tea teie keskmist tehingu aega, lehekülgede arvu teie tehinguvoos või muud teavet, mis võimaldaks neil öelda, kui palju üheaegseid kasutajaid teie veebiserver käsitleb. Kõigil neil numbritel on erinevad väärtused.
Kui küsite oma hostinguteenuse pakkujalt või tehnikameeskonnalt teavet maksimaalse liiklustaseme kohta, on ülimalt oluline, et te selgitaksite, kas nad mõtlevad samaaegseid kasutajaid, samaaegseid seansse, samaaegseid päringuid või samaaegseid ühendusi.
Siin on põhjus. Iga lehekülg on üks HTTP päring, kuid kõik teie veebirakendusest tulevad pildid, skriptid ja muud failid, mida brauser kasutab lehe kuvamiseks, on samuti HTTP päringud.
Kujutame ette, et teie tehniline meeskond on teile öelnud, et server toetab 500 samaaegset kasutajat, kuid tegelikult tähendab see 500 samaaegset päringut. Kasutades oma 5-minutilist tehinguaega, kasutate ülaltoodud valemit ja eeldate, et teie sait suudab toetada 100 külastajat minutis.
Kas see on võimalik? Ei.
Kui inimesed läbivad tehinguvoo, teevad nad tegelikult ainult päringuid teie serveritelt, kui iga lehekülg laetakse. See mõjutab seda, kui palju liiklust sekundis või aktiivseid kasutajaid teie server suudab käsitleda. Viie minuti pikkusest tehinguajast on see keskmise kasutaja jaoks vaid paar sekundit. Seetõttu võite arvata, et 500 samaaegset päringut tähendab, et saate käsitleda palju rohkem samaaegseid kasutajaid, kuid te võite eksida. Kas nüüd näete, kuidas teie veebisaidi läbilaskevõime mõistmine selles osas, kui palju liiklust või aktiivsete kasutajate koguarvu on nii keeruline asi?
Selleks, et arvutada oma maksimaalne samaaegsete kasutajate arv samaaegsete taotluste maksimaalsest koguarvust, peate samuti teadma järgmist
Ilmselt teate juba 1) ja 2) - meie näites on see 6 lehekülge ja 5 minutit. Te võite hõlpsasti lugeda lehekülgi, mida te näete tehingu tegemise ajal. Kui te ei tea keskmist tehinguaega, võib Google Analytics seda teile öelda või võite kontrollida oma veebiserveri logisid.
Punktide 3) ja 4) puhul aitab Firefoxi brauser. Tehke oma saidi lehel paremklõps, valige Inspect Element ja vahekaart Network. Seejärel vajutage CTRL-SHIFT-R, et lehekülge täielikult värskendada. Saate näha võrgu laadimisaega iga lehe elemendi kohta loetelus. Tahate veenduda, et näete ülekandesuurusi veerus Transferred, sest vastasel juhul võidakse faile serveerida vahemälust, mis võib teie arvutusi segi ajada. Te võite näha, et mõned skriptid ja muud ressursid pärinevad teistest serveritest kui teie sait, seega võite sisestada oma saidi domeeninime vasakul asuvasse filtrikasti. Et näha veeru Duration (kestus), klõpsake paremal nupul ükskõik millise veeru päises ja valige hüpikmenüüst Timings -> Duration (ajastus -> kestus). Teie ekraan peaks välja nägema selline:
Firefoxi võrgu vahekaart selle lehekülje jaoks, mis näitab päringute kestust ja arvu queue-fair.com'ist pärit päringute arvu.
Teie lehekülgede kuvamisel kasutatavad failid võivad pärineda mitmest erinevast saidist, seega soovite kasutada ka filtrit üleval vasakul, et näidata ainult teie saidi faile - kuid ainult siis, kui olete kindel , et need failid teistelt saitidelt ei ole aeglase lehe laadimise põhjus või osa teie kitsaskohast.
Firefox loeb taotlusi teie jaoks ekraani vasakus allosas ja näitab 36 HTTP-päringut ainult selle ühe leheküljekohta.
Te peate seda tegema iga lehekülje kohta oma tehinguvoos - loendage kokku ja jagage lehekülgede arvuga, et leida iga lehekülje keskmine HTTP päringute arv (number 3) meie nimekirjas. Nüüd näete, miks on iga HTML-lehe lastepäringute arv selline võtmetegur, mis määrab, kui palju liiklust teie veebiserver suudab töödelda.
Numbri 4) puhul peate vaatama veergu Duration (kestus) ja leidma kõigi teie lehekülgede kõigi HTTP-päringute keskmise. Kui te ei ole kindel, eeldage, et see on pool sekundit - selles on niikuinii palju ebakindlust (vt allpool).
Esitame mõned näited. Me ütlesime juba, et näidisserveri protsessivoolus on kuus dünaamilist lehekülge, mis on 1), ja et keskmine tehingu aeg on viis minutit, mis on 2). Oletame, et lehekülje kohta on 36 HTTP päringut, mis on 3), ja et iga HTTP päringu töötlemisaeg on pool sekundit, mis on 4).
Nende numbrite abil saab server, mis suudab käsitleda 500 samaaegset päringut, käsitleda 500 / (0,5 sekundit) = 1000 HTTP päringut sekundis, mis on 60 000 HTTP päringut minutis, kui see on täielikult ammendatud.
Viie minuti jooksul suudab see 5 * 60 000 = 300 000 HTTP-päringut töödelda. Tundub palju, eks?
Kuid iga külastaja kohta on kuus lehekülge, millest igaühel on keskmiselt 36 HTTP päringut, seega 6 * 36 = 216 päringut.
Seega, 300 000 HTTP taotluse maht võib teoreetiliselt käsitleda 300 000 / 216 = 1 389 samaaegset kasutajat.
Hei, see on suurepärane! Me arvasime, et meie järjekorra määr on ainult 100, kuid 1389 / 5 minutit = 278 külastajat minutis, nii et meil võib olla suurem järjekorra määr!
Tõenäoliselt mitte. Esiteks, teie külastajad ei saada päringuid täpselt poole sekundi tagant, nagu eespool esitatud arvutused eeldavad. Veelgi olulisem on see, et te olete mõõtnud oma sisendandmeid siis, kui sait ei ole hõivatud. Prügi sisse, prügi välja.
Kui sait on hõivatud, võtab serveril päringute töötlemine kauem aega - olete seda märganud ka teistel saitidel, kui asjad on hõivatud, et te ootate lehti kauem. See suurendab keskmist aega, mis serveril kulub ühe HTTP-päringu töötlemiseks (4), mis vähendab maksimaalset läbilaskevõimet. Seega võtke 278 külastajat minutis ja vähendage see poole võrra. Seejärel vähendage see uuesti poole võrra. Maksimaalse koormuse korral on teil tõenäoliselt reaalselt umbes 70 uut külastajat minutis.
Muud segavad tegurid on vahemälu, mis tähendab, et teie külastajate brauserid ei pea tegema iga lehe kohta iga üksiku päringu - see tähendab, et server vajab vähem ressursse ja võib suurendada uute külastajate arvu minutis, millega teie server suudab toime tulla. Koormuse tasakaalustajad, mis jaotavad koormust mitme serveri vahel, ja staatilise sisu, mitte dünaamiliste lehekülgede serveerimine võivad samuti kiirendada teie serveriprotsessi, kuna iga server vajab vähem ressursse.
Samuti leiate, et kõik leheküljed ei võta sama kaua aega, sest mõnede tegemiseks ja serveerimiseks on vaja vähem ressursse kui teiste tegemiseks. Andmebaasiotsingud, otsingupäringud ja uuendused võtavad kõige kauem aega, nii et teie protsessis tekib kusagil kitsaskoht, kus inimesed kuhjuvad, oodates krediitkaardiandmete töötlemist ja tellimuste salvestamist või oodates, et kontrollitakse saadavust. Igal tehinguvoolul on kõige aeglasem samm, seega on alati kusagil kitsaskoht, ja alati on olemas maksimaalse väärtusega vastus küsimusele, kui paljude samaaegsete kasutajatega veebiserver hakkama saab - ja siin võib olla mitu piirangut. Sellisel juhul soovite seada oma Queue Rate'i piisavalt madalaks, et tagada, et teie serveril on cpu-aegne võimsus, et töödelda piisavalt palju inimesi samaaegselt teie protsessi kõige aeglasema sammu jaoks, nii et inimesed ei kuhjuks seal. Vastasel juhul võib teie veebiserver sõna otseses mõttes seisma jääda.
Meie kogemus näitab, et esimese müügi puhul hindavad kõik üle oma serverite võimet tulla toime suure andmemahuga.
Kõik.
Keskmise sessiooni kestuse ja lõppkasutaja jõudluse täpne määramine aeglase või tippliikluse ajal ei ole nõrganärviliste jaoks. Kõige parem on teha korralik koormustest, kus "võltskliendid" läbivad koormustesti ajal tellimisprotsessi täpselt nii, nagu nad seda ka päriselus teeksid, tehes koormustesti ajal samu HTTP-päringuid samas järjekorras ja samade ooteaegadega lehekülgede vahel nagu päriselus, ning jälgige oma protsessori koormust, IO läbilaskevõimet ja vastamisaega, kui suurendate virtuaalsete külastajate arvu. Võite kasutada selleks Apache JMeterit (meile meeldib ka K6 kergemate koormuste või aeglasemate masinate puhul), kuid ükskõik, millist vahendit te kasutate, on aeganõudev ja keeruline jäljendada iga kasutaja käitumist täpselt õigel viisil (eriti seoses vahemälu kasutamise keerukusega). Isegi siis võtke oma maksimaalne arv ja vähendage seda poole võrra.
Selle puudumisel olge ettevaatlikumad.
Queue-Fair-portaali kaudu saate igal ajal hõlpsasti muuta Queue-Fair-järjekorra kiirust. Alustage 10 külastajaga minutis või oma tehingukiirusega tavalisemal päeval, vaadake, kuidas see läheb natuke aega pärast piletite müüki minekut, ja kui kõik tundub hea, teie protsessori koormus on madal, teie sql-andmebaas on korras ja (eelkõige) teie leheküljed reageerivad, kui vajutate CTRL-SHIFT-R, tõstke seda mitte rohkem kui 20 protsendi võrra, oodake natuke ja korrake. Selle "koormuse tasakaalustamise" (näete, mida me seal tegime?) käigus leiate peagi tegeliku määra, mida vajate, ja pidage meeles, et kliendikogemuse seisukohast on okei tõsta järjekorra määra, sest see põhjustab hinnangulise ooteaja vähenemist, mida teie kliendid järjekorras näevad, ja kõik on rahul, kui reageerimisaeg pakub lühemat hinnangulist ooteaega.
Mida te soovite vältida, on järjekorra määra liiga kõrgeks seadmine ja seejärel selle langetamine, sest see a) tähendab, et saidi kasutajatel on aeglane lehekülje laadimine ja b) põhjustab hinnanguliste ooteaegade suurenemist. Kõik teie järjekorras olevad inimesed ohkavad!
Pidage meeles, et kusagil teie tellimisprotsessis on kitsaskoht - igal tehingul on kõige aeglasem samm - ja sinna kuhjuvad mitu seanssi. Mida te ei taha teha, on see, et saate piletimüügiga minut aega, näete, et teie serveri protsessori koormus on tunduvalt alla selle maksimumarvu, ja tõstate kiirust. Teie külastajad ei ole tõenäoliselt jõudnud veel nupuni "Osta kohe". Te soovite oodata, kuni teie sql-andmebaas teatab uutest tellimustest sama või sarnase kiirusega kui teie järjekorra määr ja teha siis oma mõõtmised ja reageerimisvõime testid. Pidage meeles, et iga kord, kui te suurendate määra, kulub sama palju aega, et lisakülastajad jõuaksid teie kitsaskohani, nii et te ei saa täpselt hinnata, kuidas teie server uue määra juures toimib, enne kui see aeg on möödunud.
Me juba arutasime, kuidas on kõige parem suurendada järjekorra kiirust järk-järgult, kui järjekord on avatud. Tõenäoliselt olete teadlik, et teie serveritel on piir, mida ei saa ületada ilma süsteemi kokkuvarisemiseta, ja võib-olla olete isegi teadlik sellest, mis see piir on - kuid mida te ei pruugi teada, on see, et kui koormus läheneb sellele piirile, on tavaliselt väga vähe märke - sageli ainult mõned vead või hoiatused või protsessori koormus üle 80%.
Kui veebiteenused ebaõnnestuvad, kipuvad nad väga kiiresti "kokku vajuma" või katkema. Tavaliselt on see tingitud sellest, et kui teie süsteem ei suuda enam päringuid nii kiiresti töödelda, kui need laekuvad, tekivad sisemised järjekorrad. Seejärel peab teie süsteem tegema tööd nii oma sisemiste järjekordade kui ka päringute töötlemiseks, haldamiseks ja säilitamiseks ning see ongi see, mis serverid üle jõu käivitab. Väga kiiresti. Kui see juhtub, võivad teie serverid mõnda aega vastata vealehega, kuid see ei aita teid, sest külastajad, kes seda näevad, vajutavad kohe "Värskenda", mis suurendab koormust.
Isegi enne seda, kui külastajatel kulub rohkem kui umbes sekund, et teie lehekülge näha, vajutavad nad Refresh. Kui külastaja vajutab refresh, ei tea teie veebiserver, et külastaja ei oota enam vastust algsele päringule. Kui saabub nii algne kui ka värskenduspäring, töötleb teie veebiserver neid mõlemaid. See tähendab teie veebiserverile rohkem tööd, veelgi aeglasemaid vastuseid kõigile teie külastajatele ja rohkem inimesi, kes vajutavad värskendust, mille tulemuseks on nõiaring, mis krabab teie veebiserverit enne, kui see hakkab isegi vigade vastuseid saatma.
Nii et ärge suruge oma servereid rohkem kui vaja. Viimase 20% cpu ajamahutavuse poole püüdlemine ei ole tavaliselt riski väärt. Kui Queue-Fair-portaalis näidatud järjekorra suurus (kollane ooteaega näitav joon ja joon graafikutes) väheneb või isegi lihtsalt kasvab aeglasemalt, minuti kaupa, ja näidatud ooteaeg on 50 minutit või vähem, siis töötlete tellimusi piisavalt kiiresti ja järjekord tühjeneb lõpuks ning lõpetab automaatselt järjekorra näitamise, ilma et te peaksite midagi tegema ja ilma, et peaksite oma ülemusele ütlema, et surusite seda liiga kõvasti ja rikkusite selle. Te jõuate lõpuks selleni, kui järjekorra eesmise osa kiirus on suurem kui liitumiste arv minutis (mõlemad on näidatud Queue-Fair portaalis) - pöördepunkt on tavaliselt vähemalt mõne minuti pärast iga sündmuse lõppu. Kui te müüte piiratud kogusega toodet, müüakse see tõenäoliselt enne pöördepunkti jõudmist välja.
Hea uudis on see, et kui te kogemata seate järjekorra kiiruse liiga kõrgeks ja teie serverid murduvad, aitab Queue-Fair teil kiiresti tööle saada - pange järjekord lihtsalt ootele, kuni teie serverid on jälle valmis külastajate käitlemiseks. Hoidmisrežiimis näevad järjekorras olevad inimesed spetsiaalset hoidmislehte, mille saate kujundada enne veebisündmust. Kui järjekord on ootel, ei lasta kedagi järjekorra esiosast läbi, kuid uued internetikülastajad saavad siiski järjekorda liituda tagapool, et neid saaks õiglaselt järjekorda seada, kui ummistus on kõrvaldatud, mis juhtub väga kiiresti, sest Queue-Fair kaitseb teie saiti nõudluse eest. Ooteleht on parem kasutajakogemus kui järjekorra määramine tõesti madalaks, eriti kui te uuendate seda, et öelda külastajatele, millal te ootate järjekorra taasavamist, mida on lihtne teha portaalilehe redaktoriga, isegi kui järjekorras on juba sadu tuhandeid inimesi - ja ootelehel saate neid isegi ükshaaval läbi lasta Queue-Fair unikaalse Admit One nupu abil, kui teil on vaja, kuni teie süsteem taastub oma sakist.
Seega, kui teie serverid peavad ürituse ajal pausi tegema, siis on lehe "Hoidke" kasutamine just see, mida te selleks vajate, ja aitab teie serveritel kiiremini taastuda.
Selles artiklis oleme selgitanud, miks kiirusel põhinev järjekord on alati parim viis ja andnud kaks meetodit vajaliku kiiruse arvutamiseks, kuid kui te ei ole teinud täielikku ja täpset virtuaalset külastajate koormuse testimist kogu oma tehinguvoo kohta ja olete selles osas tõesti super extra mega kindel, on meie nõuanne alati sama:
Kui te müüte piiratud koguses toodet, ei pea te ka sammule 7 tähelepanu pöörama.
See on teie esimese järjekorra jaoks, kui te ei tea tegelikku maksimaalset järjekorra kiirust, mida teie süsteem suudab toetada. Kui te olete mõõtnud järjekorra kiiruse, mida teie süsteem tegelikult suudab taluda, saate järgnevate järjekordade puhul kasutada sama arvu uuesti - kuid ainult juhul, kui teie süsteemis ei ole midagi muutunud. Tegelikkuses on teie süsteemi tõenäoliselt pidevalt arendatud ja muudetud ning te ei pruugi teada, kuidas hiljutised muudatused on mõjutanud teie maksimaalset järjekorra kiirust - seega miks mitte alustada pooltest eelmistest mõõdetud näitajatest ja korrata ülaltoodud protsessi?
Niisiis, kuidas kasutada Queue-Fair-d, et teha oma onsale kõik kenasti ja turvaliselt, ja pidage meeles, et alati on parem olla kindel kui kahetseda.
2004. aastal leiutatud ja patenteeritud Queue-Fair on originaalne virtuaalne ooteruum, mis pakub hõivatud veebisaitide ja rakenduste jaoks veebipõhist järjekorra haldamist.
2024 The Fair Queue People Ltd. - Kõik õigused kaitstud.
Kuulub järjekorra lahenduste perekonda Orderly - OrderlyQ - OrderlyStats - WeQ4U
