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.
Traditionellt sett är e-handelsservrar utrustade för att stödja ett maximalt antal samtidiga användare, och belastningen definieras ofta på detta sätt. Det finns ett problem med att använda detta tillvägagångssätt för att köra en kö för en webbplats - ett problem som vi löser med priser.
Problemet uppstår eftersom besökarna endast använder webbservern medan deras webbläsare laddar varje webbsida.
Låt oss till exempel säga att en e-handelswebbplats säljer biljetter. Från början av besökarens resa till slutet av besökarens resa (användarsessionen) finns det sex sidor som besökaren
Hela transaktionsprocessen tar i genomsnitt fem minuter.
Låt oss säga att 100 besökare kommer för att köpa biljetter varje minut och att den genomsnittliga tiden för att slutföra processen är fem minuter. Vid varje given tidpunkt befinner sig 500 personer samtidigt i transaktionsprocessen, och servern måste vara utrustad för att stödja 500 samtidiga användare.
Man skulle kunna tro att man kan skapa en räknare för samtidiga användare som ökas varje gång en ny besökare kommer till hemsidan och minskas varje gång en besökare slutför transaktionen, och att detta skulle berätta hur många användare en enskild server hanterar vid varje tillfälle, men det fungerar inte.
Det kommer inte att fungera eftersom alla besökare inte slutför transaktionen. Folk ändrar sig, blir distraherade eller går iväg och kommer tillbaka senare. Eftersom webbservern endast interagerar med besökarna när deras webbläsare laddar sidor, har webbservern inget sätt att veta när detta har hänt, eller till vem.
För att avgöra att en besökare inte längre är en del av transaktionsprocessen måste den enskilda servern vänta på att inga fler sidförfrågningar kommer från besökaren och sedan tidsbegränsa besökarens session. Timeouttiden måste alltid vara mycket längre än den genomsnittliga transaktionstiden (säg 20 minuter i det här exemplet) eftersom vissa besökare tar mycket längre tid än andra att slutföra sin transaktion.
Man skulle kunna lägga till möjligheten att också minska sin teoretiska Concurrent User Counter varje gång en besökarsession tar slut på detta sätt, men detta ger mycket dåliga resultat.
Om 10 % av de 100 besökare som anländer varje minut inte fullföljer sin transaktion, kommer de som fullföljer sin transaktion att vara aktiva i genomsnitt i fem minuter och de som inte fullföljer sin transaktion kommer att betraktas som aktiva i minst 20 minuter alltid (i själva verket är det troligare att sessionens timeout plus den genomsnittliga sessionens varaktighet används när man beaktar flera sessioner).
Det är 90 * 5 + 10 * 20 = 650, och servern kommer att rapportera 650 samtidiga användare, trots att den i själva verket är mindre upptagen!
Dessutom är det så många som 10 * 20 = 200 av dessa samtidiga användare som faktiskt inte använder webbplatsen utan håller på att avbryta, vilket är över 30 % av de rapporterade samtidiga användarna, trots att det bara är 10 % av besökarna som inte slutför transaktionen.
Låt oss nu säga att någon vill lägga till en kö till denna webbplats, kontrollerad av vår Concurrent User Counter. När webbplatsen har kapacitet kommer en person som står längst fram i kön att få tillträde till webbplatsen först när räknaren minskar. Detta kallas för en "en ut- en in-kö". Vad som kommer att hända är att 30 % av tiden kommer en person som står längst fram i kön att vänta på att någon som inte kommer att slutföra sin transaktion ska sluta med att inte slutföra sin transaktion.
Det finns också ytterligare tekniskt integrationsarbete och belastning på webbplatsen när det gäller att skapa och driva räknaren och dela denna information med kösystemet. Om mekanismen för delning eller räkning går ner eller går sönder, fastnar kön. Ännu värre är det om den enskilda servern blir så upptagen att den inte kan uppdatera köservern för att tala om för köservern att släppa in nästa person, då fastnar också kön.
Alla dessa problem kan enkelt och enkelt lösas genom att i stället skicka besökarna längst fram i kön med en konstant, fast hastighet - i det här fallet 100 besökare per minut.
På så sätt behöver du inte mäta det faktiska antalet samtidiga användare, inte heller behöver du ha en komplicerad integration med biljettwebbplatsen eller riskera att kön fastnar.
Därför uppfann och patenterade vi 2004 det prisbaserade virtuella väntrummet för hektiska webbplatser.
Fantastisk och enkel produkt! Queue-Fair är verkligen vacker. Det är så enkelt att ställa in parametrarna i realtid och det är också så enkelt att integrera. Supporten är reaktiv och vänlig. Jag fick igång ett virtuellt väntrum på 15 minuter inklusive inställningar! Så jag skyddar min infrastruktur från alla dessa trafiktoppar med Queue-Fair.
Er programvara innebar att alla hölls i en kö bort från vår server och att köparna kunde passera genom systemet på ett lugnt sätt. Det var fantastiskt! Alla nätbutiker som har en rusning av kunder skulle tycka att detta är mycket användbart. Tack så mycket och fortsätt med det goda arbetet!
Lysande! Vi är mycket glada och nöjda med Queue-Fair, det är underbart att ha den här nivån av support. Tjänsten fungerar perfekt - vi sålde tusentals biljetter på nolltid och Queue-Fair hjälpte oss att hantera trafiken under toppar! Vi rekommenderar Queue-Fair även till våra servicepartners. Jag är verkligen nöjd!
Personalen på Queue-Fair gjorde allt för att hjälpa oss att implementera deras kösystem inom en dag. Med över 25 000 personer i kön hjälpte de oss att hantera trafiken under våra toppar. Queue-Fair gör det som det är tänkt att göra; ställa människor i kö till ett konkurrenskraftigt pris. Vi är nöjda med Queue-Fair-systemet och kommer att fortsätta att använda det vid framtida evenemang.
Queue-Fair var precis vad vi behövde för att hantera trafiken och supporttjänsten är fantastisk!. Systemet har fungerat mycket bra! Vi letade efter flera företag och utan tvekan har vi hittat det bästa! Tack så mycket Queue-Fair!
Ett stort tack för att du besvarade vår förfrågan så snabbt. Vi skickade ett e-postmeddelande kl. 21.00 på onsdagen och fick en kö-sida med fullt varumärke som var redo att användas kl. 11.00 på torsdagen. Helt enkelt lysande! Instrumentpanelen och funktionerna är fantastiska - riktigt intuitiva, rena och enkla att använda. Vi ställde oss i kö för över 22 000 personer till vår produktlansering till en kostnad som var extremt konkurrenskraftig. Tack så mycket för allt! Jag är verkligen glad över att kunna ge Queue-Fair ett lysande vittnesmål och skulle rekommendera dem till alla företag som behöver ett kösystem för sina evenemang eller kampanjer.
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
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.
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!
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.
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.
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.
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.
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?
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
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:
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).
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.
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.
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.
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 även 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 alla Queue-Fair-köer när som helst med hjälp av Queue-Fair-portalen. Börja med 10 besökare per minut, eller din transaktionshastighet på en mer normal dag, se hur det går en liten stund efter att dina biljetter har börjat säljas, och om allt ser bra ut, din processorbelastning är låg, din sql-databas är bra och (framför allt) dina sidor svarar när du trycker på CTRL-SHIFT-R, höj den med högst 20 procent, vänta lite och upprepa. Du kommer snart att hitta den faktiska hastighet du behöver under denna "lastbalansering" (ser du vad vi gjorde där?), och kom ihåg, ur en kundupplevelse synvinkel är det bra att höja köhastigheten eftersom detta gör att de beräknade väntetiderna som dina kunder i kön ser minskar, och alla är glada att se en svarstid som ger en kortare beräknad 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!
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.
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.
Även innan dess, om det tar mer än en sekund för besökarna att se dina sidor, trycker de på Uppdatera. När en besökare trycker på Uppdatera vet inte webbservern att besökaren inte längre väntar på svar på den ursprungliga begäran. Om både den ursprungliga och den uppdaterade begäran tas emot kommer webbservern att behandla dem båda. Det innebär mer arbete för din webbserver, ännu långsammare svar för alla dina besökare och fler som trycker på uppdatera, vilket resulterar i en ond cirkel som knäcker din webbserver innan den ens börjar skicka felsvar.
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.
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:
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?
Så det är så du använder Queue-Fair för att göra din onsale trevlig och säker, och kom ihåg att det alltid är bättre att vara säker än ledsen.
2024 The Fair Queue People Ltd. - Alla rättigheter förbehållna.
En del av Orderly-familjen av kölösningar - OrderlyQ - OrderlyStats - WeQ4U
