Vi kunne faktisk ikke finde nogen fordele ved one-out, one-in. Kort sagt er problemet med denne fremgangsmåde, at når brugerne er besøgende på e-handelswebsteder, ved webserveren ikke, hvor mange samtidige brugere den har på et hvilket som helst tidspunkt. Det er en showstopper. Her er grunden.
Senere i denne artikel fortæller vi dig også, hvordan du kan bruge et virtuelt rum baseret på takster til at beskytte dit websted.
Traditionelt er e-handelsservere konfigureret til at understøtte et maksimalt antal samtidige brugere, og belastningen defineres ofte på denne måde. Der er et problem ved at bruge denne fremgangsmåde til at køre en kø til et websted - et problem, som vi løser med hastigheder.
Problemet opstår, fordi de besøgende kun bruger webserveren, mens deres browser indlæser hver enkelt webside.
Lad os f.eks. sige, at et e-handelswebsted sælger billetter. Fra starten af besøgsrejsen til slutningen af besøgsrejsen (brugersessionen) er der seks sider, da den besøgende
Hele transaktionsprocessen tager i gennemsnit fem minutter.
Lad os sige, at der kommer 100 besøgende for at købe billetter hvert minut, og at den gennemsnitlige tid til at gennemføre processen er fem minutter. På et hvilket som helst tidspunkt er der 500 personer i transaktionsprocessen på samme tid, og serveren skal være udstyret til at understøtte 500 samtidige brugere.
Man kunne måske tro, at man kunne oprette en Concurrent User Counter, der øges hver gang en ny besøgende ankommer til hjemmesiden, og nedskrives hver gang en besøgende afslutter transaktionen, og at dette ville fortælle dig, hvor mange brugere en enkelt server håndterer på et hvilket som helst tidspunkt, men det vil ikke fungere.
Det vil ikke fungere, fordi det ikke er alle besøgende, der gennemfører transaktionen. Folk ændrer mening, bliver distraheret eller går væk og kommer tilbage senere. Da webserveren kun interagerer med de besøgende, når deres browsere indlæser sider, har webserveren ingen mulighed for at vide, hvornår dette er sket, eller hvem der har gjort det.
For at fastslå, at en besøgende ikke længere er en del af transaktionsprocessen, skal den enkelte server i stedet vente for at se, om der ikke kommer flere sideanmodninger fra den pågældende besøgende, og derefter afbryde den besøgendes session. Timeouts skal altid sættes til meget længere tid end den gennemsnitlige transaktionstid (f.eks. 20 minutter i dette eksempel), da nogle besøgende tager meget længere tid end andre til at gennemføre deres transaktion.
Man kunne tilføje muligheden for også at nedjustere ens teoretiske Concurrent User Counter, hver gang en besøgssession udløber på denne måde, men det giver meget dårlige resultater.
Hvis 10 % af de 100 besøgende, der ankommer hvert minut, ikke gennemfører deres transaktion, vil de besøgende, der gennemfører transaktionen, være aktive i gennemsnitligt fem minutter, og de besøgende, der ikke gennemfører transaktionen, vil altid blive betragtet som aktive i mindst 20 minutter (faktisk er det mere sandsynligt, at sessionens timeout plus den gennemsnitlige varighed af sessionen er mere sandsynlig, når der tages højde for flere sessioner).
Det er 90 * 5 + 10 * 20 = 650, og serveren vil rapportere 650 samtidige brugere, selv om den faktisk har mindre travlt!
Desuden er der så mange som 10 * 20 = 200 af disse samtidige brugere, der ikke bruger webstedet og er i færd med at gå i stå, hvilket svarer til over 30 % af de rapporterede samtidige brugere, selv om det kun er 10 % af de besøgende, der ikke gennemfører transaktionen.
Lad os nu sige, at man ønsker at tilføje en kø til dette websted, som styres af vores Concurrent User Counter. Når webstedet er fyldt op, vil en person, der står forrest i køen, først blive sendt videre til webstedet, når tælleren er faldet. Dette kaldes en "en ud-en-ind-kø". Det vil ske, at 30 % af tiden vil en person, der står forrest i køen, vente på, at en person, der ikke vil fuldføre sin transaktion, bliver færdig med ikke at fuldføre sin transaktion.
Der er også det yderligere tekniske integrationsarbejde og belastning af webstedet i forbindelse med oprettelse og drift af tælleren og deling af disse oplysninger med køsystemet. Hvis dele- eller tælleordningen går ned eller går i stykker, går køen i stå. Endnu værre er det, hvis den enkelte server får så travlt, at den ikke kan opdatere køserveren for at fortælle køserveren, at den skal lukke den næste person ind, så går køen også i stå.
Alle disse problemer kan nemt og enkelt løses ved i stedet at sende de besøgende fra den forreste del af køen med en konstant, fast hastighed - i dette tilfælde 100 besøgende pr. minut.
På den måde er der ikke behov for at måle det faktiske antal samtidige brugere, og der er ikke behov for kompleks integration med billetwebstedet, og der er ingen risiko for, at køen går i stå.
Derfor opfandt og patenterede vi det takstbaserede virtuelle venteværelse til travle hjemmesider i 2004.
‘Fantastisk platform! Queue-Fair er virkelig let at bruge og har en fantastisk kundeservice - de svarer altid hurtigt og klart. Den fantastiske live-rapportering hjalp os med at overvåge trafikken under lanceringen af events præcist, og den var også let at integrere og branding. Queue-Fair sikrer, at alle får en fair chance for at deltage i vores arrangementer, hvilket vi virkelig sætter stor pris på.’
‘Queue-Fair er fantastisk til vores store online detailhandelsbegivenhed. Det virkede meget intuitivt at bruge og fungerede helt fint. Queue-Fair giver kontinuitet og øger tilliden til kundernes online-oplevelse. Vi har helt sikkert planer om at bruge Queue-Fair i fremtiden til events, hvor vi forventer en enorm strøm af trafik og deltagelse i større retail-events.’
‘Værdien for os har været meget høj. Hjælpen var professionel, supporten var overlegen, og de deltog endda i vores møde for at holde øje med os alle, da køen gik live. Det var fantastisk!’
‘Vidunderligt!!! Queue-Fair fungerede meget godt, og supporten er meget god. Queue-Fair løste problemet med mange menneskers adgang til projektet og undgik nedbrud på min server. Vi planlægger at fortsætte med at bruge Queue-Fair på fremtidige projekter. Tak til Queue-Fair!!!’
‘Fantastisk værktøj, der reddede vores butik. Kundeservicen er meget god. Queue-Fair løser servermætning for os på travle billetsalg. Opsætningen var nem, og jeg kunne godt lide værktøjets effektivitet.’
‘Da vi åbnede COVID-vaccinationer for 16-29-årige, henvendte vi os til Queue-Fair for at få hjælp, som hurtigt fik oprettet et fuldt branded Virtual Waiting Room. Den eftermiddag stillede QFXNNPQ 450.000 mennesker i kø for os. Queue-Fair betød, at vores system var i stand til at acceptere reservationer i en hastighed, som det kunne håndtere, uden at det blev overbelastet. Vi er meget taknemmelige for den ekstraordinære støtte fra Queue-Fair, og vi lancerede med stor succes. Køen fungerede perfekt og hjalp os med at overvinde et punktligt afdækket teknisk problem, som ellers ville have ødelagt kampagnen. Mange, mange tak Queue-Fair for jeres tilbud! Det er meget værdsat. Queue-Fair reddede os!’
‘Det er fantastisk! Queue-Fair rocker! Queue-Fair var utrolig nyttig til at kontrollere trafikmængden på vores websted, hvilket resulterede i en problemfri og behagelig brugeroplevelse. Systemet og servicen er førsteklasses. Mange tak Queue-Fair!’
‘Fantastisk produkt, fungerer fejlfrit. Nem installation og integration, fremragende rapportering, god kommunikation og support, værdi for pengene og 5-stjernet oplevelse. Vi er glade for at kunne sige, at vores billetsalg gik glat! Vi fik udsolgt på første dag ved hjælp af Queue-Fair's virtuelle venteværelsesløsning uden en eneste fejl eller kundeklager. Queue-Fair er vidunderlig, og vi er meget taknemmelige for al den støtte, vi har fået fra Queue-Fair-teamet - det var perfekt. Vi er en glad Queue-Fair-kunde!’
‘Efter en vellykket CrowdCube-kampagne blev vi oversvømmet med forespørgsler. Vi ville sikre os, at vi ikke mistede kontakten fra potentielle kunder. Vi var imponerede over hvor hurtigt Queue-Fair kunne få os op at køre - så nemt at installere med kun én kodelinje!’
‘Perfekt løsning til vores butik. Perfekt service, de besvarede min mail selv om natten! Den bedste service, jeg har oplevet i de seneste år. Imponerende fair priser! Vi er mere end tilfredse med tjenesten. Vi har normalt mange brugere fra tid til anden, og med Queue-Fair lykkedes det os endelig at få vores servere stabile igen, og salgsprocessen er bare perfekt.’
‘Fantastisk service med et fantastisk team! Nem ombordstigning, effektiv til at klare spidsbelastninger! Høj tilgængelighed af tjenesten!’
‘Fjerner al stress i forbindelse med lancering af meget efter spurgte events. Meget let at konfigurere og sætte op med et meget opmærksomt supportteam. Bortset fra ingen stress blev vi faktisk hurtigere udsolgt. Det gør præcis, hvad der står på dåsen. Løsningen fungerede perfekt.’
Hvis du ved, hvor mange samtidige brugere en webserver håndterer, og den gennemsnitlige transaktionstid eller besøgsvarighed fra den første side i dit transaktionsflow til siden med ordrebekræftelse, kan du konvertere dette til en køhastighed ved hjælp af Littles lov ved at dividere antallet af brugere med varigheden, som her:
Køhastighed = samtidige brugere / transaktionstid
Queue-Fair leverer besøgende til dit websted med den hastighed, du angiver - vi har langt den mest præcise Queue AI i branchen, der sikrer, at det antal besøgende, du ønsker hvert minut, er det antal besøgende, du får hvert minut, idet vi automatisk tager højde for folk, der ikke er til stede, når deres tur bliver kaldt, samt folk, der kommer for sent tilbage.
Hvordan kan dette oversættes til antallet af samtidige brugere? Det er naturligvis ikke alle besøgende, der besøger dit websted, der vil tage den nøjagtige gennemsnitlige transaktionstid for at gennemføre deres transaktion, men du vil få et meget stabilt antal samtidige brugere med Queue-Fair, på grund af loven om store tal.
Lad os f.eks. sige, at du har en kø på 100 besøgende i minuttet. Vi sender 100 besøgende til dit websted hvert eneste minut i en jævn strøm - det er det, vi gør, og vi er utroligt gode til det. Lad os også sige, at folk bruger dit websted i gennemsnit (gennemsnit) i fem minutter, og at 70 % af dem bruger mellem 4 og 6 minutter fra det øjeblik, de passerer køen, til det øjeblik, de foretager deres sidste sideanmodning (uanset om de gennemfører en transaktion eller ej). Det er en standardafvigelse på et minut på hver side af gennemsnittet. Statistisk set betyder det, at for hver besøgende, der tager fem og et halvt minut, vil der være en anden, der tager fire og et halvt minut, og disse variationer i de individuelle besøgsvarigheder på tværs af flere sessioner har derfor tendens til at ophæve hinanden, når man tæller mange af dem på en eller anden måde. Loven om store tal siger, at denne udligning bliver mere og mere præcis, jo større antallet af involverede personer er.
Hvor nøjagtigt, præcist? Det kan vi regne ud med lidt statistik. Der er en stikprøvestørrelse på 5 * 100 = 500, hvilket er det store tal, der er tale om her. Det er så mange mennesker, du tæller. Det betyder, at standardfejlen i gennemsnittet for transaktionstiden er 1 (standardafvigelsen, 1 minut) divideret med kvadratroden af stikprøvestørrelsen (altså kvadratroden af 500) i henhold til den statistiske formel for standardfejl i gennemsnittet, hvilket giver en standardfejl i gennemsnittet for transaktionstiden på 0,044 minutter, eller blot 2,7 sekunder, hvilket er mindre end én procent.
Det betyder, at med en køhastighed på 100 og en transaktionstid på 5 minutter plus/minus et minut for hver enkelt besøgende, kan du forvente mellem 495 og 505 samtidige brugere på dit websted omkring 70 % af tiden, så matematikken siger, at brugen af en kø baseret på hastighed vil give en meget stabil belastning på dine webservere som ønsket.
Men er matematikken korrekt? Der er nogle finesser her - f.eks. er den stikprøvestørrelse, som vi gladeligt kvadratrooterer, ikke altid præcis 500, hver gang Concurrent Users tælles (dvs. på et hvilket som helst tidspunkt), og en normal (Gaussisk) fordeling kan også give negative transaktionstider, som ikke forekommer i det virkelige liv. Så vi bruger en simulator, der simulerer besøgende for besøgende, sekund for sekund, til at foretage målinger for at kontrollere denne slags beregninger, og det fortæller os, at med ovenstående tal bør du forvente mellem 493 og 507 besøgende 70 % af tiden, så matematikken holder bemærkelsesværdigt godt! Målingerne fortæller os også, at dit websted vil have 500 ± 15 samtidige brugere mindst 95 % af tiden.
Det er sandsynligvis mere stabilt end den nøjagtighed, hvormed din webserver kan måle antallet af brugere af dit websted! Endnu bedre er det, at selv om du ikke aner, hvad den gennemsnitlige transaktionstid eller standardafvigelsen er for dine besøgende, findes disse matematiske størrelser, uanset om du kender dem eller ej, og du vil få en stabil belastning alligevel.
Resultatet er, at Queue-Fair vil levere det antal besøgende pr. minut, som du ønsker, med næsten perfekt nøjagtighed, hvilket resulterer i et meget stabilt antal samtidige brugere på dit websted og en stabil webserverbelastning, som du har fuld kontrol over.
Hurra!
Og nu en advarsel. Det er værd at bemærke, at stabiliteten af antallet af samtidige brugere på dit websted - og dermed stabiliteten af din serverbelastning - afhænger i høj grad af, hvor præcist din udbyder af et virtuelt venteværelse sender dig det antal besøgende, som du ønsker hvert minut, og dette er derfor en vigtig faktor, når du vælger en platform til et virtuelt venteværelse. Fordi vi leverer det mest præcise Virtual Waiting Room i verden, er der ingen der stopper dine servere bedre end Queue-Fair for oversvømmelser.
Hvad hvis du ikke ved, hvor mange samtidige brugere en server kan håndtere eller hvor lang transaktionstid en server kan håndtere? Du kan kigge på den side, der sandsynligvis er din flaskehals - normalt den side, der er resultatet af et klik på en "Køb nu"-knap. Brug Google Analytics til at finde de månedlige unikke besøgende på denne side eller tæl dine månedlige ordrer. Divider dette med 30 * 24 * 60 = 43.200, hvilket er antallet af minutter på en måned (cirka). Det er dine gennemsnitlige besøgende pr. minut i løbet af hele måneden. Multiplicer dette med tre. Det er dine gennemsnitlige besøgende pr. minut i åbningstiden (ca.). Fordobl dette. Det er sandsynligvis et sikkert tal, som du kan bruge til køhastigheden.
Lad os for eksempel sige, at du behandler 100.000 ordrer om måneden - det er 100.000 klik på "Køb nu"-knappen. Det er 100.000 / 43.200 = 2,31 ordrer pr. minut. Du vil forvente, at de fleste af disse ordrer sker i løbet af dagen, og at dine servere er mere stille om natten, så gang dette med 3, og det giver 7 ordrer pr. minut som et groft skøn over, hvor travlt din server har i åbningstiden. Hvis det resulterende tal er mindre end 50: Der vil være toppe og lavvande i efterspørgslen, så hvis din server ikke er mærkbart langsom i spidsbelastningstimerne, skal du gange dette med 2 for at få 14 aktive brugere pr. minut. Hvis tallet er mere end 50: Toppene og lavpunkterne fra minut til minut vil være mindre i sammenligning, og det er ikke sikkert at fordoble dette tal. Det tal, du ender med, er sandsynligvis et sikkert tal for Queue Rate til at starte med og svarer til, hvor mange forespørgsler pr. sekund du sikkert kan håndtere; du kan altid øge det, hvis du finder, at dine systemer stadig er lydhøre for slutbrugernes ydeevne ved denne hastighed.
Hvis dine ordrer er tidsstemplet, kan du også se på det maksimale antal ordrer, du har modtaget i et enkelt minut i den sidste måned - men brug det med forsigtighed, da du ikke ved, hvor mange ordrer du kan have droppet i løbet af dette minut, fordi dine servere er blevet langsommere, så reducer dette tal med 20 %.
Resten af denne artikel omhandler nogle andre måder at beregne køhastigheden på.
Det er værd at påpege, at der er mindst to definitioner af "Concurrent Users" i almindelig brug.
Vi bruger definitionen "antallet af personer, der er involveret i en transaktionsstrøm på et hvilket som helst tidspunkt". Det er det nøgletal, som du skal kende for at indstille køhastigheden. Det er, hvor mange brugere der ser dit websted lige nu. Antallet af samtidige sessioner er normalt noget større end antallet af samtidige forbindelser eller samtidige brugere, fordi nogle af sessionerne er i gang med at time ud, hvilket øger den gennemsnitlige varighed af sessionen.
Sammenlign dette med hvor mange samtidige forespørgsler, som er antallet af HTTP-forespørgsler, der behandles af din webserver på et hvilket som helst tidspunkt. Det er meget forvirrende, at mange teknikere mener hvor mange samtidige forespørgsler, når de siger hvor mange samtidige brugere.
Så er der Concurrent Connections (eller samtidige TCP-forbindelser til den samme serverport på dit netkort), som er antallet af TCP/IP-socket'er, der er åbne på din serverport eller backend-tjeneste på et hvilket som helst tidspunkt. Når der foretages sideanmodninger, lader browsere som standard forbindelsen stå åben, hvis der foretages yderligere anmodninger fra siden, eller hvis brugeren går til en anden side. Dette reducerer antallet af anmodninger pr. sekund om at åbne nye TCP/IP-forbindelser, hvilket gør serverprocessen mere effektiv. Timeouts for disse samtidige forbindelser varierer fra browser til browser, fra 60 sekunder til aldrig-lukke. Din server kan også lukke forbindelserne automatisk efter en periode uden aktivitet. På Linux-webservere kan du få en optælling af samtidige forbindelser til den samme serverport med denne kommando: netstat -aenp | grep ":80 \|:443 " | wc -l
som du kan prøve, hvis du er nysgerrig. Igen, nogle folk kalder også dette "Concurrent Users", når det i virkeligheden betyder samtidige forbindelser.
Hvis du beder din hostingudbyder om at oplyse dig om det maksimale antal samtidige brugere, som din webserver kan håndtere (hvor meget spidsbelastning), vil de sandsynligvis give dig et tal for samtidige sessioner, samtidige forespørgsler eller samtidige forbindelser, af den simple grund, at de ikke kender din gennemsnitlige transaktionstid, antallet af sider i dit transaktionsflow eller andre oplysninger, der ville gøre det muligt for dem at oplyse dig om, hvor mange samtidige brugere din webserver kan håndtere. Alle disse tal har forskellige værdier.
Hvis du beder din hostingudbyder eller dit tekniske team om oplysninger om maksimale trafikniveauer, er det supervigtigt, at du får afklaret, om de mener Concurrent Users, Concurrent Sessions, Concurrent Requests eller Concurrent Connections.
Her er grunden. Hver side er en enkelt HTTP-anmodning, men alle billeder, scripts og andre filer, der kommer fra dit webprogram, og som browseren bruger til at vise siden, er også HTTP-anmodninger.
Lad os forestille os, at dit tekniske team har fortalt dig, at serveren understøtter 500 samtidige brugere, men at de i virkeligheden mener 500 samtidige forespørgsler. Med din transaktionstid på 5 minutter bruger du ovenstående formel og antager, at dit websted kan understøtte 100 besøgende pr. minut.
Kan det? Nej.
Når folk går gennem transaktionsflowet, foretager de faktisk kun anmodninger fra dine servere, mens hver side indlæses. Dette påvirker, hvor meget trafik pr. sekund eller hvor mange aktive brugere din server kan håndtere. Ud af de fem minutters transaktionstid er det kun et par sekunder for en gennemsnitlig bruger. Du tror måske derfor, at 500 Concurrent Requests betyder, at du kan håndtere langt flere Concurrent Users, men du kan meget vel tage fejl. Kan du nu se, hvordan det er så kompliceret at forstå din hjemmesides kapacitet i form af hvor meget trafik eller det samlede antal aktive brugere?
For at beregne dit maksimale antal samtidige brugere ud fra dit maksimale samlede antal samtidige anmodninger skal du også vide følgende
Du kender sikkert allerede 1) og 2) - i vores eksempel er der tale om 6 sider og 5 minutter. Du kan nemt tælle de sider, du ser, mens du foretager en transaktion. Hvis du ikke kender den gennemsnitlige transaktionstid, kan Google Analytics måske fortælle dig det, eller du kan tjekke dine webserverlogfiler.
For 3) og 4) kan Firefox-browseren hjælpe. Højreklik på en side på dit websted, vælg Inspicer element og fanen Netværk. Tryk derefter på CTRL-SHIFT-R for at opdatere siden fuldstændigt. Du vil se netværksindlæsningstider for hvert element på siden på listen. Du skal sikre dig, at du kan se overførselsstørrelser i kolonnen Overført, da filer ellers kan blive serveret fra en cache, hvilket kan forkludre dine beregninger. Du kan se, at nogle scripts og andre ressourcer kommer fra andre servere end dit websted, så du kan skrive domænenavnet for dit websted i filterfeltet til venstre. Hvis du vil se kolonnen Varighed, skal du højreklikke på en kolonneoverskrift og vælge Timings -> Duration fra pop op-menuen. Din skærm bør se således ud:
Firefox' netværksfaneblad for denne side, der viser Varighed og antal Anmodninger fra queue-fair.com
Filer, der bruges til visning af dine sider, kan komme fra en række forskellige websteder, så du bør også bruge filteret øverst til venstre til kun at vise filerne fra dit websted - men kun hvis du er sikker på , at disse filer fra andre websteder ikke er årsagen til langsom sideindlæsning eller en del af flaskehalsen.
Firefox tæller anmodningerne for dig nederst til venstre i displayet og viser 36 HTTP-anmodninger for denne ene side.
Du skal gøre dette for hver side i dit transaktionsflow - tæl det samlede antal og divider det med antallet af sider for at finde det gennemsnitlige antal HTTP-forespørgsler for hver side, nummer 3) på vores liste. Du kan nu se, hvorfor antallet af børneanmodninger for hver HTML-side er en så vigtig faktor for, hvor meget trafik din webserver kan håndtere.
For nummer 4) skal du kigge på kolonnen Varighed og finde gennemsnittet for alle HTTP-forespørgsler for alle dine sider. Hvis du ikke er sikker, kan du antage et halvt sekund - der er alligevel en stor usikkerhed i dette tilfælde (se nedenfor).
Lad os give nogle taleksempler. Vi har allerede sagt, at der er seks dynamiske sider i eksempelets serverprocesflow, hvilket er 1), og at den gennemsnitlige transaktionstid er fem minutter, hvilket er 2). Lad os antage 36 HTTP-forespørgsler pr. side for 3) og et halvt sekund for serverens behandlingstid for hver HTTP-forespørgsel, hvilket er 4).
Med disse tal kan en server, der kan håndtere 500 samtidige forespørgsler, håndtere 500 / (0,5 sekunder) = 1000 HTTP-forespørgsler i sekundet, hvilket svarer til 60.000 HTTP-forespørgsler i minuttet, når den er fuldt ud udnyttet.
I løbet af de fem minutters transaktionstid kan den håndtere 5 * 60.000 = 300.000 HTTP-forespørgsler. Det virker som meget, ikke sandt?
Men for hver besøgende er der seks sider med et gennemsnit på 36 HTTP-forespørgsler hver, så det er 6 * 36 = 216 forespørgsler
Så kapaciteten på 300.000 HTTP-forespørgsler kan i teorien håndtere 300.000 / 216 = 1.389 samtidige brugere
Hej, det er fantastisk! Vi troede, at vi kun kunne have en køhastighed på 100, men 1.389 / 5 minutter = 278 besøgende pr. minut, så vi kan have en højere køhastighed!
Det er nok ikke tilfældet. For det første vil dine besøgende ikke sende forespørgsler med intervaller på nøjagtig et halvt sekund, som det antages i ovenstående beregning. Endnu vigtigere er det, at du har målt dine inputdata, når der ikke er travlt på webstedet. Skrald ind, skrald ud.
Når der er travlt på webstedet, tager det længere tid for serveren at behandle anmodninger - du har sikkert bemærket det på andre websteder, når der er travlt, at du venter længere tid på sider. Dette øger den gennemsnitlige tid, som din server tager for at behandle en enkelt HTTP-forespørgsel (4), hvilket mindsker det maksimale gennemløb. Så tag de 278 besøgende pr. minut og halver det. Halver den derefter igen. Du er nok realistisk set på omkring 70 nye besøgende pr. minut ved maksimal belastning.
Andre forvirrende faktorer omfatter caching, hvilket betyder, at dine besøgendes browsere måske ikke behøver at foretage hver enkelt forespørgsel for hver enkelt side - det betyder, at serveren har brug for færre ressourcer og kan øge antallet af nye besøgende pr. minut, som din server kan håndtere. Load balancers, der fordeler belastningen på flere servere, og servering af statisk indhold i stedet for dynamiske sider kan også fremskynde din serverproces, da hver server kræver færre ressourcer.
Du vil også opdage, at det ikke tager lige lang tid at udfylde alle siderne, da nogle af dem kræver færre ressourcer end andre at producere og servere. Databasesøgninger, søgeforespørgsler og opdateringer tager længst tid, så du vil have en flaskehals et eller andet sted i din proces, hvor folk hober sig op og venter på, at kreditkortoplysninger behandles og ordrer lagres, eller venter på, at tilgængeligheden kontrolleres. Enhver transaktionsstrøm har et langsomste trin, så der er altid en flaskehals et sted, og der er altid et svar på spørgsmålet om, hvor mange samtidige brugere en webserver kan håndtere - og der kan være flere grænser involveret. I så fald skal du indstille din Queue Rate lavt nok til at sikre, at din server har cpu-tidskapacitet til at behandle nok personer samtidig til det langsomste trin i din proces, så folk ikke hober sig op der. Ellers kan din webserver bogstaveligt talt gå i stå.
Vores erfaring er, at alle overvurderer deres serveres evne til at klare store trafikmængder, når de går ind i deres første salg.
Alle sammen.
Det er ikke for sarte sjæle at få et præcist billede af den gennemsnitlige varighed af sessionen og slutbrugernes ydeevne under langsom eller høj trafik. Det bedste er at køre en ordentlig belastningstest med "falske" kunder, der rent faktisk gennemgår ordreprocessen under belastningstestning, præcis som de ville gøre i det virkelige liv, idet de foretager de samme HTTP-forespørgsler i samme rækkefølge og med de samme ventetider mellem siderne under belastningstestning, som du ser i det virkelige liv, og hold øje med din processorbelastning, IO-gennemstrømning og svartider, efterhånden som du øger antallet af virtuelle besøgende. Du kan bruge Apache JMeter til dette (vi kan også godt lide K6 til lettere belastninger eller langsommere maskiner), men uanset hvilket værktøj du bruger, er det tidskrævende og vanskeligt at efterligne hver enkelt brugers adfærd på nøjagtig den rigtige måde (især med kompleksiteten ved caching). Selv da skal du tage dit max-tal og halvere det.
Hvis det ikke er tilfældet, skal du være forsigtig.
Du kan nemt ændre køhastigheden for enhver Queue-Fair-kø til enhver tid ved hjælp af Queue-Fair-portalen. Start med 10 besøgende i minuttet, eller din transaktionsrate på en mere normal dag, se hvordan det går et stykke tid efter, at dine billetter er sat til salg, og hvis alt ser godt ud, din processorbelastning er lav, din sql-database er fin, og (frem for alt) dine sider reagerer, når du trykker på CTRL-SHIFT-R, så hæv den med ikke mere end 20 procent, vent lidt, og gentag. Du vil snart finde den faktiske hastighed, du har brug for under denne "belastningsbalancering" (kan du se, hvad vi gjorde der?), og husk, at fra et kundeoplevelsessynspunkt er det fint at hæve køhastigheden, da dette får de estimerede ventetider, som dine kunder i køen ser, til at reducere, og alle er glade for at se en svartid, der leverer en kortere estimeret ventetid.
Du skal undgå at indstille køhastigheden for højt og derefter være nødt til at sænke den, da dette a) betyder, at folk, der bruger webstedet, oplever langsomme sideindlæsninger, og b) får de forventede ventetider til at stige. Alle folk i din kø vil sukke!
Husk, at du vil have en flaskehals et sted i din ordreproces - enhver transaktion har et langsomt trin - og du vil få flere sessioner, der hober sig op der. Det, du ikke ønsker at gøre, er at komme et minut ind i dit billetsalg, se, at din serverprocessorbelastning er langt under sit maksimale tal, og hæve hastigheden. Dine besøgende er sandsynligvis ikke nået så langt som til "Køb nu"-knappen. Du ønsker at vente, indtil din sql-database rapporterer nye ordrer med samme eller lignende hastighed som din Queue Rate og foretage dine målinger og responsivitetstests derefter. Husk, at hver gang du øger hastigheden, vil det tage den samme tid for de ekstra besøgende at nå din flaskehals, så du vil ikke kunne vurdere nøjagtigt, hvordan din server klarer sig med den nye hastighed, før der er gået den tid.
Vi har allerede diskuteret, hvordan det er bedst at øge køhastigheden gradvist, når køen er åbnet. Du er sikkert klar over, at dine servere har en grænse, der ikke kan overskrides, uden at systemet går ned, og du er måske endda klar over, hvad grænsen er - men hvad du måske ikke ved, er, at når belastningen nærmer sig denne grænse, er der normalt meget få tegn - ofte blot nogle få fejl eller advarsler eller en processorbelastning på over 80 %.
Når webtjenester fejler, har de en tendens til at "knække" eller gå i stå meget hurtigt. Det skyldes normalt, at når systemet ikke længere kan behandle anmodninger så hurtigt, som de kommer ind, opbygges der interne køer til behandling. Dit system skal så udføre arbejdet med at behandle, administrere og lagre sine interne køer samt forespørgslerne, og det er det, der får servere til at gå i stå. Meget hurtigt. Når det sker, kan dine servere måske i et stykke tid reagere med en fejlside, men det hjælper dig ikke, fordi de besøgende, der ser den, straks trykker på Opdater, hvilket øger belastningen.
Selv inden da, hvis det tager mere end et sekund for de besøgende at se dine sider, trykker de på Refresh. Når en besøgende trykker på refresh, ved din webserver ikke, at den besøgende ikke længere venter på svaret på den oprindelige anmodning. Hvis både den oprindelige og refresh-anmodningen modtages, vil din webserver behandle dem begge. Det betyder mere arbejde for din webserver, endnu langsommere svar til alle dine besøgende og flere, der trykker på refresh, hvilket resulterer i en ond cirkel, der knækker din webserver, før den overhovedet begynder at sende fejlsvar.
Så du skal ikke presse dine servere mere end nødvendigt. Det er normalt ikke risikoen værd at gå efter de sidste 20 % af cpu-tidskapaciteten. Hvis den køstørrelse, der vises i Queue-Fair-portalen (det gule tal og den gule linje i diagrammerne), falder eller endda bare stiger langsommere minut for minut, og den viste ventetid er 50 minutter eller mindre, så behandler du ordrer hurtigt nok, og køen vil til sidst blive tømt og holde op med at vise kø-sider automatisk, uden at du behøver at gøre noget, og uden at du behøver at fortælle din chef, at du har presset den for hårdt og ødelagt den. Du når dertil på et tidspunkt, så længe hastigheden på køens forside er højere end antallet af Joins hvert minut (som begge vises i Queue-Fair-portalen) - vendepunktet er normalt mindst et par minutter inde i hver begivenhed. Hvis du sælger et produkt i begrænset mængde, vil du sandsynligvis sælge ud, før vendepunktet er nået.
Den gode nyhed er, at hvis du ved et uheld indstiller køhastigheden for højt, og dine servere går i stå, kan Queue-Fair hjælpe dig med at komme hurtigt i gang igen - du skal blot sætte køen på Hold, indtil dine servere er klar til at håndtere besøgende igen. I Hold-tilstand ser folk i køen en særlig Hold-side, som du kan designe før din onlinebegivenhed. Ingen bliver lukket igennem fra den forreste del af køen, når den er på Hold, men nye internetbesøgende kan stadig slutte sig til køen bagerst i køen for at blive sat i kø på en rimelig måde, når blokaden er ryddet, hvilket vil ske meget hurtigt, fordi Queue-Fair beskytter dit websted mod efterspørgslen. Hold-siden er en overlegen brugeroplevelse i forhold til at indstille køhastigheden virkelig lavt, især hvis du opdaterer den for at fortælle de besøgende, hvornår du forventer, at køen åbner igen, hvilket er let at gøre med portalside-editoren, selv når hundredtusindvis af mennesker allerede er i køen - og i Hold-tilstand kan du endda lade dem komme igennem en ad gangen med Queue-Fair's unikke Admit One-knap, hvis du har brug for det, mens dit system kommer sig over sit snap.
Så hvis du oplever, at dine servere har brug for en pause under dit arrangement, er Hold-siden lige det, du har brug for, og den hjælper dine servere med at komme sig hurtigere igen.
I denne artikel har vi forklaret, hvorfor en hastighedsbaseret kø altid er vejen frem, og vi har givet to metoder til at beregne den hastighed, du har brug for, men medmindre du har foretaget en fuldstændig og præcis virtuel test af belastningen af besøgende på hele dit transaktionsflow, og er virkelig super ekstra mega sikker på det, er vores råd altid det samme:
Hvis du sælger et produkt i begrænset antal, behøver du heller ikke at være opmærksom på trin 7.
Det er for din første kø, når du ikke kender den faktiske maksimale køhastighed, som dit system kan understøtte. For efterfølgende køer kan du måske bruge det samme tal igen, når du har målt den køhastighed, som dit system faktisk kan håndtere, men kun hvis der ikke er sket ændringer på dit system. I praksis er dit system sandsynligvis under konstant udvikling og ændring, og du ved måske ikke, hvordan de seneste ændringer har påvirket din maksimale køhastighed - så hvorfor ikke starte med halvdelen af dit tidligere målte tal og gentage ovenstående proces?
Sådan bruger du Queue-Fair til at gøre dit on-sale sikkert og godt, og husk, at det altid er bedre at være på den sikre side end at være ked af det.
Queue-Fair blev opfundet og patenteret i 2004 og er det originale virtuelle venteværelse, som giver online køstyring til travle websteder og apps.
2024 The Fair Queue People Ltd. - Alle rettigheder forbeholdes.
En del af Orderly-familien af kø-løsninger - OrderlyQ - OrderlyStats - WeQ4U
