Hur du med hjälp av vår onlinekö förhindrar att webbplatsen kraschar och att den kraschar - hur många samtidiga användare kan en webbserver hantera?

Varför använda ett prisbaserat virtuellt väntrum?

Prisbaserad eller "en ut, en in"? Vi väger för- och nackdelarna mot varandra.

Vi kunde faktiskt inte hitta några fördelar med one-out, one-in. Problemet med detta tillvägagångssätt är kort sagt att när användarna är besökare på webbplatser för e-handel vet inte webbservern hur många samtidiga användare den har vid varje tidpunkt. Det är ett problem. Här är skälet till detta.

Längre fram i artikeln berättar vi också hur du kan använda ett prisbaserat virtuellt rum för att skydda din webbplats.



Det högst rankade virtuella väntrummet på G2

Vad våra kunder säger om Queue-Fair


belastningstestning av http-förfrågningar hur många förfrågningar en webbserver klarar utan extra serverresurser

Hur många samtidiga användare kan en webbserver hantera?

Om du vet hur många samtidiga användare en webbserver hanterar och den genomsnittliga transaktionstiden eller besökstiden från den första sidan i transaktionsflödet till sidan för orderbekräftelse, kan du omvandla detta till en köhastighet med hjälp av Littles lag genom att dividera antalet användare med besökstiden, på följande sätt:

Köhastighet = samtidiga användare / transaktionstid

Hur exakt är ett hastighetsbaserat kösystem?

Queue-Fair kommer att leverera besökare till din webbplats i den takt du anger - vi har den överlägset mest exakta AI-kön i branschen för att se till att det antal besökare du vill ha varje minut är det antal besökare du får varje minut, med automatisk redovisning av personer som inte är närvarande när det är deras tur, samt personer som kommer tillbaka sent.

Hur översätts detta till antalet samtidiga användare? Naturligtvis kommer inte alla besökare som besöker din webbplats att ta exakt den genomsnittliga transaktionstiden för att slutföra sin transaktion, men du kommer att få ett mycket stabilt antal samtidiga användare med Queue-Fair, på grund av lagen om stora tal.

Låt oss till exempel säga att du har en köhastighet på 100 besökare per minut. Vi skickar 100 besökare till din webbplats varje minut i en jämn ström - det är vad vi gör och vi är otroligt duktiga på det. Låt oss också säga att människor använder din webbplats i genomsnitt (medelvärde) i fem minuter, där 70 % av dem tar mellan 4 och 6 minuter från det ögonblick då de passerar kön till det ögonblick då de gör sin sista sidförfrågan (oavsett om de genomför en transaktion eller inte). Det är en standardavvikelse på en minut på vardera sidan om medelvärdet. Statistiskt sett betyder det att för varje besökare som tar fem och en halv minut kommer det att finnas en annan som tar fyra och en halv, och dessa variationer i enskilda besökens varaktighet över flera sessioner tenderar därför att upphäva varandra när man räknar många av dem på något sätt. Lagen om stora tal säger att denna utjämning blir mer och mer exakt ju större antalet inblandade personer är.

operativsystem maximalt antal webbserverresurser
beräkning av genomsnittssiffran för samtidiga användare med konfidensintervall

Hur exakt, exakt? Det kan vi reda ut med hjälp av lite statistik. Det finns ett urval på 5 * 100 = 500, vilket är det stora talet här. Det är så många personer som du räknar. Detta innebär att standardfelet i medelvärdet för transaktionstiden är 1 (standardavvikelsen, 1 minut) dividerat med kvadratroten av urvalsstorleken (alltså kvadratroten av 500) enligt den statistiska formeln för standardfel i medelvärdet, vilket ger ett standardfel i medelvärdet för transaktionstiden på 0,044 minuter, eller bara 2,7 sekunder, vilket är mindre än en procent.

Detta innebär att med en köhastighet på 100 och en transaktionstid på 5 minuter för varje enskild besökare kan du förvänta dig mellan 495 och 505 samtidiga användare på din webbplats cirka 70 % av tiden, så matematiken säger att en köhastighetsbaserad kö kommer att ge en mycket jämn belastning på dina webbservrar som önskat.

Men är matematiken korrekt? Det finns en del finesser här - till exempel är urvalsstorleken som vi glatt kvadrerar inte alltid exakt 500 varje gång samtidiga användare räknas (dvs. vid varje given tidpunkt), och en normal (Gaussisk) fördelning kan ge negativa transaktionstider som inte förekommer i verkligheten. Därför använder vi en simulator som simulerar besökare för besökare, sekund för sekund, för att göra mätningar för att kontrollera den här typen av beräkningar, och det visar att med ovanstående siffror bör du förvänta dig mellan 493 och 507 besökare 70 % av tiden, så matematiken håller anmärkningsvärt bra! Mätningarna visar också att din webbplats kommer att ha 500 ± 15 samtidiga användare minst 95 % av tiden.

Det är förmodligen mer stabilt än den noggrannhet med vilken din webbserver kan mäta antalet personer som använder din webbplats! Ännu bättre är att även om du inte har någon aning om vad den genomsnittliga transaktionstiden eller standardavvikelsen är för dina besökare, så finns dessa matematiska storheter oavsett om du känner till dem eller inte, och du kommer att få en stabil belastning i alla fall.

Resultatet är att Queue-Fair kommer att leverera det antal besökare per minut som du vill ha med nästan perfekt noggrannhet, vilket resulterar i ett mycket stabilt antal samtidiga användare på din webbplats och en stabil belastning på webbservern som du har total kontroll över.

Hurra!


servers capacity can be exceeced with inaccurate queues Och nu en varning. Det är värt att notera att stabiliteten i antalet samtidiga användare på din webbplats - och därmed stabiliteten i din serverbelastning - är kritiskt beroende av hur exakt din leverantör av virtuella väntrum skickar dig det antal besökare som du vill ha varje minut, och detta är därför en viktig faktor när du väljer en plattform för virtuella väntrum. Eftersom vi tillhandahåller det mest exakta virtuella väntrummet i världen är det ingen som hindrar dina servrar från att svämma över bättre än Queue-Fair.

Ett enkelt sätt att beräkna köhastigheten

Vad händer om du inte vet hur många samtidiga användare en server kan hantera eller hur lång transaktionstid den har? Du kan titta på den sida som sannolikt är flaskhalsen - vanligtvis den sida som är resultatet av att du klickar på en "Köp nu"-knapp. Använd Google Analytics för att ta reda på antalet unika besökare per månad på den sidan, eller räkna dina månatliga beställningar. Dela detta med 30 * 24 * 60 = 43 200, vilket är antalet minuter i en månad (ungefär). Det är dina genomsnittliga besökare per minut under hela månaden. Multiplicera detta med tre. Det är dina genomsnittliga besökare per minut under kontorstid (ungefär). Fördubbla detta. Det är förmodligen en säker siffra för köhastigheten att använda.

Låt oss till exempel säga att du bearbetar 100 000 beställningar per månad - det är 100 000 klick på "Köp nu"-knappen. Det är 100 000 / 43 200 = 2,31 beställningar per minut. Du förväntar dig att de flesta av dessa beställningar sker under dagen och att dina servrar är lugnare på natten, så multiplicera detta med 3 och det blir 7 beställningar per minut som en grov uppskattning av hur upptagen din server är under kontorstid. Om den resulterande siffran är mindre än 50: det kommer att finnas toppar och dalar i efterfrågan, så om din server inte är märkbart långsam under topptimmarna, multiplicera detta med 2 för att få 14 aktiva användare per minut. Om siffran är mer än 50: toppar och dalar från minut till minut kommer att vara mindre i jämförelse, och det är inte säkert att fördubbla denna siffra. Den siffra du får är förmodligen en säker siffra för köhastigheten att börja med och motsvarar hur många förfrågningar per sekund du kan hantera på ett säkert sätt; du kan alltid öka den om du upptäcker att dina system fortfarande är mottagliga för slutanvändarprestanda vid den hastigheten.

beräkna maximala nivåer av aktiva användare för din webbapplikation

Om dina beställningar är tidsstämplade kan du också titta på det högsta antalet beställningar som du tog emot under en enda minut den senaste månaden - men var försiktig eftersom du inte vet hur många beställningar du kan ha tappat under denna minut på grund av att dina servrar blev långsammare, så minska detta med 20 %.

I resten av artikeln diskuteras några andra sätt att räkna ut köhastigheten.

Förvirring om samtidiga användare, samtidiga anslutningar, samtidiga sessioner och genomsnittlig sessionslängd.

Jag fick dig #1: Samtidiga användare vs Samtidiga förfrågningar vs Samtidiga anslutningar vs Samtidiga sessioner

Det är värt att påpeka att det finns minst två definitioner av "samtidiga användare" i allmänt bruk.

Vi använder definitionen "antalet personer som deltar i ett transaktionsflöde vid en viss tidpunkt". Det är det nyckeltalet som du behöver känna till för att ställa in köhastigheten. Det är hur många användare som tittar på din webbplats just nu. Antalet samtidiga sessioner är vanligtvis något större än antalet samtidiga anslutningar eller samtidiga användare, eftersom en del av sessionerna håller på att ta slut, vilket ökar den genomsnittliga sessionslängden.

Detta kan jämföras med hur många samtidiga begäranden som är antalet HTTP-förfrågningar som behandlas av webbservern samtidigt. Det är mycket förvirrande att många tekniker menar hur många samtidiga förfrågningar när de säger hur många samtidiga användare.

Sedan har vi Concurrent Connections (eller samtidiga TCP-anslutningar till samma serverport på ditt nätverksgränssnittskort), vilket är antalet TCP/IP-uttag som är öppna på din serverport eller backend-tjänst vid varje tidpunkt. När sidförfrågningar görs lämnar webbläsarna som standard anslutningen öppen om ytterligare förfrågningar görs av sidan eller om användaren går till en annan sida. Detta minskar antalet förfrågningar per sekund för att öppna nya TCP/IP-anslutningar, vilket gör serverprocessen effektivare. Tidsgränserna för dessa samtidiga anslutningar varierar beroende på webbläsare, från 60 sekunder till att aldrig stänga. Din server kan också stänga anslutningar automatiskt efter en period utan aktivitet. På Linux-webservrar kan du få fram ett antal samtidiga anslutningar till samma serverport med det här kommandot:

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

som du kan prova om du är nyfiken. Återigen, vissa kallar detta för "Concurrent Users" (samtidiga användare) när det egentligen betyder samtidiga anslutningar.

Om du ber din webbhotellleverantör att tala om hur många samtidiga användare din webbserver maximalt kan hantera (hur mycket topptrafik), kommer de förmodligen att ge dig en siffra för samtidiga sessioner, samtidiga förfrågningar eller samtidiga anslutningar, av den enkla anledningen att de inte känner till den genomsnittliga transaktionstiden, antalet sidor i transaktionsflödet eller någon annan information som skulle göra det möjligt för dem att tala om hur många samtidiga användare som din webbserver kan hantera. Alla dessa siffror har olika värden.

Om du frågar din webbhotellleverantör eller ditt tekniska team om information om maximala trafiknivåer är det mycket viktigt att du klargör om de menar samtidiga användare, samtidiga sessioner, samtidiga förfrågningar eller samtidiga anslutningar.

Om du gör fel kan din webbplats krascha!

Här är anledningen till detta. Varje sida är en enskild HTTP-förfrågan, men alla bilder, skript och andra filer som kommer från din webbapplikation och som webbläsaren använder för att visa sidan är också HTTP-förfrågningar.

Låt oss tänka oss att ditt tekniska team har sagt till dig att servern stöder 500 samtidiga användare, men att de i själva verket menar 500 samtidiga begäranden. Med en transaktionstid på 5 minuter använder du ovanstående formel och antar att din webbplats kan ta emot 100 besökare per minut.

Kan det? Nej.

När människor går igenom transaktionsflödet gör de egentligen bara förfrågningar från dina servrar medan varje sida laddas. Detta påverkar hur mycket trafik per sekund eller aktiva användare din server kan hantera. Av den fem minuter långa transaktionstiden är det bara några sekunder för en genomsnittlig användare. Du kanske därför tror att 500 samtidiga begäranden innebär att du kan hantera mycket fler samtidiga användare, men du kan mycket väl ha fel. Kan du nu se hur det är så komplicerat att förstå din webbplats kapacitet i termer av hur mycket trafik eller totalt antal aktiva användare?

Säkerställ först och främst dina serverresurser när du beräknar hur många förfrågningar dina webbsidor kan få för att ge en bra upplevelse för varje enskild användare.

Konvertera samtidiga begäranden till samtidiga användare

För att räkna ut det maximala antalet samtidiga användare från det maximala totala antalet samtidiga begäranden måste du också veta följande

  1. Antalet sidor i ditt transaktionsflöde
  2. Den genomsnittliga transaktionstiden för besökare från första till sista sidan i ditt flöde.
  3. Hur många förfrågningar varje sida i genomsnitt innehåller
  4. Den genomsnittliga tiden som din server tar för att bearbeta en enskild HTTP-begäran.

Du känner säkert redan till 1) och 2) - i vårt exempel är det 6 sidor och 5 minuter. Du kan lätt räkna de sidor du ser när du gör en transaktion. Om du inte känner till den genomsnittliga transaktionstiden kan Google Analytics berätta det, eller så kan du kontrollera dina webbserverloggar.

För 3) och 4) kan webbläsaren Firefox hjälpa till. Högerklicka på en sida på din webbplats, välj Inspektera element och fliken Nätverk. Tryck sedan på CTRL-SHIFT-R för att uppdatera sidan helt och hållet. Du kommer att se nätverksladdningstiderna för varje element på sidan i listan. Du vill försäkra dig om att du kan se överföringsstorlekar i kolumnen Överförd, eftersom filer annars kan serveras från en cache, vilket kan ställa till det för dina beräkningar. Du kanske ser att vissa skript och andra resurser kommer från andra servrar än din webbplats, så du kan skriva domännamnet för din webbplats i filterrutan till vänster. Om du vill se kolumnen Varaktighet högerklickar du på en kolumnrubrik och väljer Timings -> Duration i snabbmenyn. Skärmen bör se ut så här:

google bearbetar en korrekt konfigurerad nginx med google analytics för bilduppladdning

Firefox nätverksflik för den här sidan, som visar varaktighet och antal förfrågningar från queue-fair.com

Filer som används för att visa dina sidor kan komma från flera olika webbplatser, så du bör också använda filtret uppe till vänster för att bara visa filerna från din webbplats - men bara om du är säker på att filerna från andra webbplatser inte är orsaken till långsam sidladdning eller en del av flaskhalsen.

Firefox räknar förfrågningarna för dig längst ner till vänster på skärmen och visar 36 HTTP-förfrågningar för bara den här sidan.

Du måste göra detta för varje sida i transaktionsflödet - räkna summan och dela den med antalet sidor för att få fram det genomsnittliga antalet HTTP-begäranden för varje sida, nummer 3) i vår lista. Du kan nu se varför antalet barnförfrågningar för varje HTML-sida är en så viktig faktor för hur mycket trafik din webbserver kan hantera.

För nummer 4) måste du titta på kolumnen Varaktighet och hitta genomsnittet för alla HTTP-begäranden för alla dina sidor. Om du är osäker kan du anta en halv sekund - det finns en hel del osäkerhet i detta ändå (se nedan).

räkna ut hur många sessioner som pågår samtidigt, hur många användare och hur många förfrågningar per sekund på din webbapplikation, oavsett om det är en enda server eller statiskt innehåll.

Att räkna på det hela

Låt oss ge några exempel på siffror. Vi har redan sagt att det finns sex dynamiska sidor i processflödet på exempelservern, vilket är 1), och att den genomsnittliga transaktionstiden är fem minuter, vilket är 2). Låt oss anta 36 HTTP-förfrågningar per sida för 3), och en halv sekund för serverns behandlingstid för varje HTTP-förfrågan, vilket är 4).

Med dessa siffror kan en server som kan hantera 500 samtidiga begäranden hantera 500 / (0,5 sekunder) = 1 000 HTTP-förfrågningar per sekund, vilket motsvarar 60 000 HTTP-förfrågningar per minut när den är fullt utnyttjad.

Under den fem minuter långa transaktionstiden kan den hantera 5 * 60 000 = 300 000 HTTP-förfrågningar. Det verkar vara mycket, eller hur?

Men för varje besökare finns det sex sidor med i genomsnitt 36 HTTP-förfrågningar vardera, så det blir 6 * 36 = 216 förfrågningar.

Så kapaciteten för 300 000 HTTP-förfrågningar kan i teorin hantera 300 000 / 216 = 1 389 samtidiga användare.

Jag fick dig #2: Webbserverna blir långsammare med belastningen

Det är ju jättebra! Vi trodde att vi bara kunde ha en köhastighet på 100, men 1 389 / 5 minuter = 278 besökare per minut, så vi kan ha en högre köhastighet!

Troligen inte. För det första kommer dina besökare inte att skicka förfrågningar med intervaller på exakt en halv sekund, vilket beräkningen ovan förutsätter. Ännu viktigare är att du har mätt dina inmatningsdata när webbplatsen inte är upptagen. Skräp in, skräp ut.

När webbplatsen är upptagen tar servern längre tid på sig att behandla förfrågningar - du har säkert märkt det på andra webbplatser när det är upptaget, att du väntar längre på sidor. Detta ökar den genomsnittliga tiden som din server tar för att behandla en enskild HTTP-förfrågan (4), vilket minskar den maximala genomströmningen. Så ta 278 besökare per minut och halvera det. Sedan halverar du det igen. Du har förmodligen realistiskt sett cirka 70 nya besökare per minut vid maximal belastning.

Ju större belastning från trafikstötarna, desto långsammare blir maskinerna.

Andra förvirrande faktorer är caching, vilket innebär att dina besökares webbläsare kanske inte behöver göra varje enskild begäran för varje enskild sida - detta innebär att servern behöver mindre resurser och kan öka antalet nya besökare per minut som din server kan hantera. Lastutjämnare som fördelar belastningen på flera servrar och servering av statiskt innehåll i stället för dynamiska sidor kan också påskynda din serverprocess, eftersom varje server kräver färre resurser.

Du kommer också att märka att det inte tar lika lång tid att fylla i alla sidor, eftersom vissa kräver mindre resurser än andra för att produceras och serveras. Databassökningar, sökfrågor och uppdateringar tar längst tid, så du kommer att ha en flaskhals någonstans i din process där folk samlas på hög och väntar på att kreditkortsuppgifter ska behandlas och beställningar lagras, eller väntar på att tillgängligheten ska kontrolleras. Varje transaktionsflöde har ett långsammaste steg, så det finns alltid en flaskhals någonstans, och det finns alltid ett svar på frågan om hur många samtidiga användare en webbserver kan hantera - och det kan finnas flera gränser inblandade. I det fallet vill du ställa in din Queue Rate tillräckligt lågt för att se till att din server har cpu-tidskapacitet för att behandla tillräckligt många människor samtidigt för det långsammaste steget i din process så att människor inte samlas där. Annars kan din webbserver bokstavligen stanna upp.

osäker på hur man uppskattar serverkapaciteten serverresurser för varje enskild användare

Vad gör jag då?

Vår erfarenhet är att alla överskattar sina servrar när de börjar sälja för första gången och tror att de klarar av att hantera stora trafikvolymer.

Alla.

Att exakt fastställa den genomsnittliga sessionslängden och slutanvändarens prestanda vid långsam eller hög trafik är inget för den som är svaghjärtad. Det bästa är att köra ett ordentligt belastningstest, med "falska" kunder som faktiskt går igenom beställningsprocessen under belastningstestet precis som de skulle göra i verkligheten, och som gör samma HTTP-förfrågningar i samma ordning, med samma väntetider mellan sidorna under belastningstestet som i verkligheten, och hålla ett öga på processorbelastningen, IO-genomströmningen och svarstiderna när du ökar antalet virtuella besökare. Du kan använda Apache JMeter för detta (vi gillar också K6 för lättare belastningar eller långsammare maskiner), men oavsett vilket verktyg du använder är det tidskrävande och svårt att efterlikna varje enskild användares beteende på exakt rätt sätt (särskilt med komplexiteten i caching). Även då bör du ta ditt maxantal och halvera det.

Om det inte finns något sådant, bör du vara försiktig.

Du kan enkelt ändra köhastigheten för en Queue-Fair-kö när som helst via Queue-Fair-portalen. Börja med 10 besökare per minut, eller din transaktionshastighet en mer normal dag, se hur det går en stund efter att biljetterna börjar säljas, och om allt ser bra ut, din processorbelastning är låg, din sql-databas är bra och (framför allt) dina sidor reagerar när du trycker på CTRL-SHIFT-R, fördubbla den, vänta lite och upprepa. Du kommer snart att hitta den faktiska hastigheten som du behöver under denna "lastbalansering" (ser du vad vi gjorde där?), och kom ihåg att ur kundupplevelsens synvinkel är det okej att höja köhastigheten eftersom detta leder till att de uppskattade väntetiderna som dina kunder i kön ser minskar, och alla är glada att se en svarstid som ger en kortare uppskattad väntetid.

Det du vill undvika är att ställa in köhastigheten för högt och sedan tvingas sänka den, eftersom detta a) innebär att de som använder webbplatsen får långsamma sidladdningar och b) leder till att de uppskattade väntetiderna ökar. Alla personer i din kö kommer att sucka!

Jag fick dig #3: Öka hastigheten för snabbt efter att en kö har öppnats.

Kom ihåg att du kommer att ha en flaskhals någonstans i din beställningsprocess - varje transaktion har ett långsammaste steg - och du kommer att få flera sessioner som samlas där. Vad du inte vill göra är att komma en minut in i biljettförsäljningen, se att serverens processorbelastning ligger långt under maxantalet och höja hastigheten. Dina besökare har förmodligen inte kommit så långt som till knappen "Köp nu". Du vill vänta tills din sql-databas rapporterar nya beställningar i samma eller liknande takt som din köhastighet och göra dina mätningar och responsivitetstester då. Kom ihåg att varje gång du ökar hastigheten kommer det att ta lika lång tid för de extra besökarna att nå din flaskhals, så du kommer inte att kunna bedöma exakt hur din server presterar med den nya hastigheten förrän efter att den tiden har gått.

Fördröja beslutet att använda serverresurser.
servrar snapsar när servrarnas kapacitet överskrids

Jag fick dig #4: Att ta tag i dina servrar

Vi har redan diskuterat hur det är bäst att öka köhastigheten gradvis när kön har öppnats. Du är förmodligen medveten om att dina servrar har en gräns som inte kan överskridas utan att systemet kraschar, och du kanske till och med är medveten om vad gränsen är - men vad du kanske inte vet är att när belastningen närmar sig denna gräns finns det vanligtvis väldigt få tecken - ofta bara några få fel eller varningar, eller en processorbelastning över 80 %.

När webbtjänster misslyckas tenderar de att "knäppa" eller stanna upp mycket snabbt. Detta beror normalt på att när systemet inte längre kan behandla förfrågningar lika snabbt som de kommer in, byggs interna köer upp. Systemet måste då göra arbetet med att bearbeta, hantera och lagra sina interna köer samt förfrågningarna, och det är det som gör att servrarna hamnar på gränsen. Mycket snabbt. När detta sker kan dina servrar under en tid reagera med en felsida, men det hjälper dig inte eftersom de besökare som ser den omedelbart trycker på Uppdatera, vilket förvärrar belastningen.

Pressa inte dina servrar hårdare än nödvändigt. Det är oftast inte värt risken att försöka utnyttja de sista 20 procenten av CPU-kapaciteten. Om den köstorlek som visas i Queue-Fair-portalen (den gula siffran och linjen för väntetid i diagrammen) minskar eller till och med ökar långsammare minut för minut, och den väntetid som visas är 50 minuter eller mindre, då bearbetar du beställningar tillräckligt snabbt och kön kommer så småningom att tömmas och sluta visa kö-sidor automatiskt, utan att du behöver göra något och utan att du behöver berätta för din chef att du pressade den för hårt och förstörde den. Du kommer att nå dit så småningom så länge hastigheten på köens framsida är högre än antalet Joins varje minut (båda visas i Queue-Fair-portalen) - vändpunkten är vanligtvis minst några minuter efter varje händelse. Om du säljer en produkt i begränsad mängd kommer du förmodligen att sälja slut innan vändpunkten nås.

Den goda nyheten är att om du råkar ställa in köhastigheten för högt och servrarna går sönder kan Queue-Fair hjälpa dig att snabbt komma igång igen - du sätter bara kön på vänteläge tills dina servrar är redo att hantera besökare igen. I Hold-läget ser de som står i kön en särskild Hold-sida som du kan utforma före ditt online-evenemang. Ingen släpps igenom från början av kön när den är på Hold, men nya Internetbesökare kan fortfarande ansluta sig till kön längst bak för att köas in på ett rättvist sätt när blockeringen är över, vilket kommer att ske mycket snabbt eftersom Queue-Fair skyddar din webbplats från efterfrågan. Hold-sidan är en överlägsen användarupplevelse jämfört med att ställa in köhastigheten riktigt lågt, särskilt om du uppdaterar den för att tala om för besökarna vilken tid du förväntar dig att kön ska öppnas igen, vilket är lätt att göra med portalens sidredigerare, även när hundratusentals människor redan står i kö - och i Hold-läget kan du till och med släppa igenom dem en i taget med Queue-Fair:s unika Admit One-knapp om du behöver det medan ditt system återhämtar sig från sin spänning.

Så om du upptäcker att dina servrar behöver ta en paus under evenemanget är sidan Hold precis vad du behöver för det, och den hjälper dina servrar att återhämta sig snabbare.

Slutsats

I den här artikeln har vi förklarat varför en hastighetsbaserad kö alltid är rätt väg att gå, och vi har gett dig två metoder för att beräkna den hastighet du behöver, men om du inte har gjort fullständiga och exakta virtuella belastningstester för hela ditt transaktionsflöde och är riktigt super extra mega säker på det, är vårt råd alltid detsamma:

  1. Börja med en köhastighet på 10, eller din transaktionshastighet under en normal dag.
  2. Håll koll på processorbelastningen och andra prestandaindikatorer.
  3. Vänta tills nya beställningar registreras i din sql-databas i samma eller liknande takt som din köhastighet.
  4. Tryck CTRL-SHIFT-R på dina sidor för att kontrollera responsiviteten.
  5. Öka köhastigheten med högst 20 %.
  6. Gå tillbaka till steg 2 och vänta igen.
  7. När köstorleken minskar eller ökar stadigt mindre snabbt varje minut och väntetiden är mindre än 50 minuter behöver det inte gå snabbare.
  8. Luta dig tillbaka och slappna av! Queue-Fair har allt för dig.

Om du säljer en produkt i begränsad mängd behöver du inte heller ta hänsyn till steg 7.

Detta gäller för din första kö, när du inte vet vilken maximal köhastighet som systemet kan stödja. När du har mätt den köhastighet som ditt system faktiskt klarar av för efterföljande köer kan du kanske använda samma siffra igen - men bara om inget har ändrats i ditt system. I praktiken utvecklas och ändras ditt system förmodligen ständigt och du kanske inte vet hur de senaste förändringarna har påverkat din maximala köhastighet - så varför inte börja med halva den tidigare uppmätta siffran och upprepa ovanstående process?

Kom ihåg att det alltid är bättre att vara säker än att vara ledsen.


Hundratals ledande organisationer litar på våra
kölösningar

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

Den enkla lösningen på din trafikökning på internet

Kom igång