Hvordan du ved hjælp af vores online kø forhindrer et nedstyrtet websted og nedbrud af websteder - hvor mange samtidige brugere kan en webserver håndtere?

Hvorfor bruge et virtuelt venteværelse baseret på hastighed?

Hastighed-baseret eller "en ud, en ind"? Vi afvejer fordele og ulemper.

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.



Det højest bedømte virtuelle venteværelse på G2
G2 er verdens mest besøgte SaaS-anmeldelseswebsted, hvor vi har den perfekte score på 5,0 / 5 stjerner.

Hvad vores kunder siger om Queue-Fair


belastningstest af http-forespørgsler hvor mange forespørgsler en webserver kan klare uden ekstra serverressourcer

Hvor mange samtidige brugere kan en webserver håndtere?

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

Hvor nøjagtigt er et kø-system baseret på hastigheder?

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.

operativsystemets maksimale antal webserverressourcer
beregning af gennemsnitstal for samtidige brugere med konfidensinterval

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!


servers capacity can be exceeced with inaccurate queues 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.

En nem måde at beregne køhastigheden på

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.

beregning af det maksimale antal aktive brugere for din webapplikation

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å.

forvirring om samtidige brugere samtidige forbindelser samtidige forbindelser samtidige sessioner og gennemsnitlig varighed af sessioner

Jeg har dig #1: Samtidige brugere vs. samtidige forespørgsler vs. samtidige forbindelser vs. samtidige sessioner

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.

Hvis du gør det forkert, kan det få dit websted til at gå ned!

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?

først og fremmest at tage hensyn til dine serverressourcer, når du beregner, hvor mange forespørgsler dine websider kan få for at sikre en god oplevelse for hver enkelt bruger

Konvertering af samtidige anmodninger til samtidige brugere

For at beregne dit maksimale antal samtidige brugere ud fra dit maksimale samlede antal samtidige anmodninger skal du også vide følgende

  1. Antallet af sider i dit transaktionsflow
  2. Den gennemsnitlige transaktionstid for besøgende fra den første til den sidste side i dit flow
  3. Hvor mange forespørgsler udgør hver side i gennemsnit
  4. Den gennemsnitlige tid, det tager din server at behandle en enkelt HTTP-anmodning

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:

google behandler en korrekt konfigureret nginx med google analytics til upload af billeder

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).

at regne på hvor mange sessioner på samme tid, hvor mange brugere og hvor mange forespørgsler pr. sekund på din webapplikation, uanset om det er en enkelt server eller statisk indhold

At regne på det hele

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

Jeg har dig #2: Webservere bliver langsommere med belastningen

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.

jo større belastning fra din trafik, jo langsommere bliver maskinerne

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å.

usikker på, hvordan man anslår servernes kapacitet serverressourcer for hver enkelt bruger

Hvad gør jeg så?

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!

Jeg har dig #3: For hurtig forøgelse af hastigheden efter åbning af en kø

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.

bremse beslutningen om at forbruge serverressourcer
servere snap, når servernes kapacitet er overskredet

Jeg har dig #4: Snapping af dine servere

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.

Konklusion

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:

  1. Start med en køhastighed på 10 eller din transaktionshastighed på en mere normal dag.
  2. Hold øje med din processorbelastning og andre indikatorer for ydeevne.
  3. Vent, indtil nye ordrer registreres i din SQL-database med samme eller lignende hastighed som din køhastighed.
  4. Tryk på CTRL-SHIFT-R på dine sider for at kontrollere responsiviteten.
  5. Forøg køhastigheden med højst 20 %.
  6. Gå tilbage til trin 2, og vent igen.
  7. Når køens størrelse er faldende eller stiger mindre hurtigt hvert minut, og den viste ventetid er mindre end 50 minutter, behøver den ikke længere at gå hurtigere.
  8. Læn dig tilbage og slap af! Queue-Fair har styr på dig.

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.


Hundredvis af førende organisationer stoler på vores
kø-løsninger

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

Den enkle løsning på dine trafikforøgelser på internettet

Kom i gang