We konden eigenlijk geen voordelen vinden voor one-out, one-in. In een notendop, het probleem met die aanpak is dat wanneer de gebruikers bezoekers zijn van e-commerce websites, de webserver niet weet hoeveel gelijktijdige gebruikers hij heeft op een bepaald moment in de tijd. Het is een showstopper. Hier is waarom.
Verderop in dit artikel vertellen wij u ook hoe u een op snelheid gebaseerde virtuele kamer kunt gebruiken om uw site te beschermen.
Traditioneel worden e-commerceservers uitgerust om een maximum aantal gelijktijdige gebruikers te ondersteunen, en de belasting wordt vaak op die manier gedefinieerd. Er is een probleem met het gebruik van deze aanpak om een wachtrij voor een website te beheren - een probleem dat wij oplossen met tarieven.
Het probleem ontstaat omdat bezoekers de webserver alleen gebruiken terwijl hun browser elke webpagina laadt.
Laten we bijvoorbeeld zeggen dat een e commerce site tickets verkoopt. Vanaf het begin van het bezoekerstraject tot het einde van het bezoekerstraject (de gebruikerssessie) zijn er zes pagina's als de bezoeker
Het hele transactieproces neemt gemiddeld vijf minuten in beslag.
Stel, weer als voorbeeld, dat er elke minuut 100 bezoekers binnenkomen om kaartjes te kopen, en dat de gemiddelde tijd om het proces te voltooien vijf minuten is. Op elk gegeven moment zijn er 500 mensen tegelijk in het transactieproces, en de server moet worden uitgerust om 500 gelijktijdige gebruikers te ondersteunen.
Je zou kunnen denken dat je een Concurrent User Counter kunt maken die telkens wordt opgehoogd als een nieuwe bezoeker op de home page komt, en telkens wordt verlaagd als een bezoeker de transactie voltooit, en dat dit je zou vertellen hoeveel gebruikers een enkele server op een bepaald moment verwerkt, maar dat werkt niet.
Het zal niet werken omdat niet elke bezoeker de transactie afrondt. Mensen veranderen van gedachten, of worden afgeleid, of gaan weg en komen later terug. Omdat de webserver alleen interactie heeft met de bezoekers wanneer hun browser pagina's laadt, kan de webserver niet weten wanneer dit is gebeurd, of met wie.
In plaats daarvan moet de enkele server, om te bepalen dat een bezoeker niet langer deel uitmaakt van het transactieproces, wachten om te zien of er geen pagina-aanvragen meer binnenkomen van die bezoeker en dan de sessie van die bezoeker time-out zetten. Time-outs moeten altijd worden ingesteld op een tijd die veel langer is dan de gemiddelde transactietijd (in dit voorbeeld bijvoorbeeld 20 minuten), omdat sommige bezoekers er veel langer over doen dan anderen om hun transactie te voltooien.
Men zou de faciliteit kunnen toevoegen om ook de fictieve Concurrent User Counter te verlagen telkens wanneer een bezoekerssessie op deze manier wordt beëindigd, maar dit geeft zeer slechte resultaten.
Als 10% van de 100 bezoekers die elke minuut aankomen hun transactie niet voltooien, zullen degenen die wel voltooien gemiddeld vijf minuten actief zijn en zullen degenen die niet voltooien altijd minstens 20 minuten als actief worden beschouwd (eigenlijk is de sessietime-out plus de gemiddelde sessietijd waarschijnlijker als meerdere sessies in aanmerking worden genomen).
Dat is 90 * 5 + 10 * 20 = 650, en de server zal 650 gelijktijdige gebruikers melden, ook al is het in werkelijkheid minder druk!
Bovendien gebruiken 10 * 20 = 200 van die gelijktijdige gebruikers de site niet echt en zijn ze bezig met een time-out, wat meer is dan 30% van de gerapporteerde gelijktijdige gebruikers, ook al is het maar 10% van de bezoekers die de transactie niet voltooien.
Laten we nu zeggen dat we een wachtrij willen toevoegen aan deze website, gecontroleerd door onze Concurrent User Counter. Als de site eenmaal op capaciteit is, dan zal een individu dat vooraan in de wachtrij staat, pas naar de site worden doorgelaten als de teller afneemt. Dit wordt een één-uit-één-in wachtrij genoemd. Wat er zal gebeuren is dat 30% van de tijd, een persoon aan de voorkant van de wachtrij zal wachten op iemand die niet van plan is om zijn transactie te voltooien om te eindigen niet het voltooien van hun transactie.
Er is ook het bijkomende technische integratiewerk en de belasting van de website om de teller aan te maken en te laten werken, en die informatie te delen met het wachtrijsysteem. Als het deel- of telmechanisme uitvalt of breekt, komt de wachtrij vast te zitten. Erger nog, als de enkele server het zo druk krijgt dat hij de wachtrijserver niet kan updaten om de wachtrijserver te vertellen dat hij de volgende persoon moet binnenlaten, loopt de wachtrij ook vast.
Al deze problemen kunnen gemakkelijk en eenvoudig worden opgelost door in plaats daarvan de bezoekers vooraan in de wachtrij te sturen met een constante, vaste snelheid - in dit geval 100 bezoekers per minuut.
Op die manier hoeft het werkelijke aantal gelijktijdige gebruikers niet te worden gemeten, is er geen complexe integratie met de ticketing-website nodig en loopt u niet het risico dat de wachtrij vastloopt.
Daarom hebben we in 2004 de op tarieven gebaseerde virtuele wachtruimte voor drukke websites uitgevonden en gepatenteerd.
Geweldig en gemakkelijk product! Queue-Fair is echt prachtig. Zo gemakkelijk om de parameters in real-time in te stellen, en het is ook zo gemakkelijk te integreren. De ondersteuning is reactief en vriendelijk. Ik kreeg een virtuele wachtkamer in 15 minuten, inclusief instellingen! Dus ik bescherm mijn infrastructuur tegen al die verkeerspieken met Queue-Fair.
Uw software zorgde ervoor dat iedereen in een wachtrij van onze server werd gehouden en liet een rustige stroom kopers door het systeem gaan. Het was geweldig! Elke online winkel met veel klanten zou dit echt nuttig vinden. Hartelijk dank en ga zo door!
Briljant! We zijn erg blij en tevreden met Queue-Fair, het is geweldig om dit niveau van ondersteuning te hebben. De service werkt perfect - we verkochten duizenden tickets in een mum van tijd, en Queue-Fair hielp ons het verkeer te managen tijdens hoge pieken! We bevelen Queue-Fair ook aan bij onze service partners. Ik ben echt blij!
De mensen van Queue-Fair deden meer dan hun best om ons te helpen hun wachtrijsysteem binnen één dag te implementeren. Met meer dan 25.000 mensen in de wachtrij hielpen ze ons het verkeer tijdens onze hoge pieken in goede banen te leiden. Queue-Fair doet waarvoor het bedoeld is; mensen in de wachtrij zetten tegen een concurrerende prijs. We zijn blij met het Queue-Fair systeem en zullen het blijven gebruiken tijdens toekomstige evenementen.
Queue-Fair was precies wat we nodig hadden om het verkeer te beheren en de ondersteuningsservice is geweldig! Het systeem heeft zeer goed gewerkt ! We hebben naar verschillende bedrijven gezocht en zonder twijfel hebben we de beste gevonden ! Hartelijk dank, Queue-Fair!
Hartelijk dank voor de snelle afhandeling van onze aanvraag. Gemaild om 21.00 uur woensdag, ontvangen een volledig gemerkte wachtrij pagina klaar voor gebruik om 11.00 uur donderdag. Gewoonweg briljant! Het dashboard en de functies zijn geweldig - echt intuïtief, echt schoon en gemakkelijk te gebruiken. We hebben meer dan 22.000 mensen in de wachtrij gezet voor onze productlancering tegen een zeer concurrerende prijs. Heel erg bedankt voor alles! Ik ben erg blij dat ik Queue-Fair een gloedvol getuigenis kan geven en zou hen aanbevelen aan elk bedrijf dat een wachtrijsysteem nodig heeft voor hun evenement of promotie.
Als u weet hoeveel gelijktijdige gebruikers een webserver verwerkt, en de gemiddelde transactietijd of bezoekduur, vanaf de eerste pagina in uw transactiestroom tot de orderbevestigingspagina, kunt u dit omzetten in een Queue Rate met behulp van de Wet van Little door het aantal gebruikers te delen door de duur, op deze manier:
Wachtrij snelheid = Concurrente gebruikers / Transactie tijd
Queue-Fair levert bezoekers aan uw website met de snelheid die u aangeeft - wij hebben veruit de meest nauwkeurige wachtrij AI in de industrie om ervoor te zorgen dat het aantal bezoekers dat u elke minuut wilt, ook het aantal bezoekers is dat u elke minuut krijgt, waarbij automatisch rekening wordt gehouden met mensen die niet aanwezig zijn wanneer hun beurt wordt afgeroepen, evenals mensen die te laat terugkomen.
Hoe vertaalt zich dit in het aantal gelijktijdige gebruikers? Natuurlijk zal niet elke bezoeker die uw site bereikt er exact de gemiddelde transactietijd over doen om zijn transactie te voltooien, maar u zult met Queue-Fair een zeer gestaag aantal gelijktijdige gebruikers krijgen, vanwege de Wet van de Grote Getallen.
Bijvoorbeeld, laten we zeggen dat je een Queue Rate hebt van 100 bezoekers per minuut. Dan sturen we elke minuut 100 bezoekers naar uw site in een gestage stroom - dat is wat we doen en daar zijn we verbluffend goed in. Laten we ook zeggen dat mensen uw website gemiddeld vijf minuten gebruiken, waarbij 70% van hen er tussen de 4 en 6 minuten over doet vanaf het moment dat ze door de wachtrij worden geleid tot het moment dat ze hun laatste pagina-aanvraag doen (ongeacht of ze een transactie voltooien of niet). Dat is een standaardafwijking van één minuut aan weerszijden van het gemiddelde. Statistisch gezien betekent dit dat voor elke bezoeker die er vijf en een halve minuut over doet, er een andere is die er viereneenhalve minuut over doet, en deze variaties in individuele bezoekduur over meerdere sessies hebben daarom de neiging elkaar op te heffen wanneer je er veel van telt op welke manier dan ook. De wet van de grote getallen zegt dat deze opheffing steeds exacter wordt naarmate het aantal betrokkenen toeneemt.
Hoe precies, precies? Dat kunnen we uitrekenen met wat statistiek. Er is een steekproefgrootte van 5 * 100 = 500, dat is het grote getal waar het hier om gaat. Dat is het aantal mensen dat je telt. Dit betekent dat de Standaardfout in het Gemiddelde voor de transactietijd 1 is (de standaardafwijking, 1 minuut) gedeeld door de vierkantswortel van de steekproefgrootte (dus de vierkantswortel van 500) volgens de statistische formule voor Standaardfout in het Gemiddelde, wat een Standaardfout in het Gemiddelde oplevert voor de transactietijd van 0,044 minuten, of slechts 2,7 seconden, dat is minder dan één procent.
Dit betekent dat met een Queue Rate van 100, en een transactietijd van 5 minuten plus of min een minuut voor elke individuele bezoeker, je tussen de 495 en 505 gelijktijdige gebruikers op je site zou moeten verwachten rond 70% van de tijd, dus de wiskunde zegt dat het gebruik van een rate-based queue een zeer constante belasting van je webservers zal opleveren zoals gewenst.
Maar is de wiskunde nauwkeurig? Er zijn hier wat subtiliteiten - bijvoorbeeld, de steekproefgrootte die we vrolijk kwadrateren is niet altijd precies 500 elke keer dat de Concurrent Users worden geteld (d.w.z. op elk gegeven moment in de tijd), en ook een normale (Gaussische) verdeling kan negatieve transactietijden geven die in het echt niet voorkomen. Dus gebruiken we een bezoeker-voor-bezoeker, seconde-voor-seconde simulator om metingen te doen om dit soort berekeningen te controleren, en die vertelt ons dat met de bovenstaande cijfers, je tussen de 493 en 507 bezoekers moet verwachten in 70% van de tijd, dus de wiskunde houdt opmerkelijk goed stand! Het meten van de gegevens vertelt ons ook dat uw site minstens 95% van de tijd 500 ± 15 gelijktijdige gebruikers zal hebben.
Dat is waarschijnlijk stabieler dan de nauwkeurigheid waarmee uw webserver het aantal mensen kan meten dat uw site gebruikt! Zelfs als u geen idee heeft wat de gemiddelde transactietijd of standaardafwijking van uw bezoekers is, bestaan deze wiskundige grootheden, of u ze nu kent of niet, en krijgt u toch een stabiele belasting.
Het resultaat is dat Queue-Fair met een vrijwel perfecte nauwkeurigheid het aantal bezoekers per minuut levert dat u wenst, wat resulteert in een zeer stabiel aantal gelijktijdige gebruikers op uw site, en een stabiele belasting van de webserver waarover u totale controle heeft.
Hoera!
En nu een waarschuwing. Het is vermeldenswaard dat de stabiliteit van het aantal gelijktijdige gebruikers op uw site - en dus de stabiliteit van uw server belasting - wel degelijk kritisch afhangt van hoe nauwkeurig uw Virtual Waiting Room provider u het aantal bezoekers stuurt dat u per minuut wenst, en dit is dan ook een belangrijke factor bij het kiezen van een Virtual Waiting Room platform. Omdat wij de meest accurate Virtual Waiting Room ter wereld leveren, houdt niemand uw servers beter tegen dan Queue-Fair.
Wat als je niet weet hoeveel gelijktijdige gebruikers een server aankan, of hoeveel transactietijd? U kunt kijken naar de pagina die waarschijnlijk uw knelpunt is - meestal de pagina die het resultaat is van het klikken op een "Nu kopen" knop. Gebruik Google Analytics om de maandelijkse unieke bezoekers op die pagina te vinden, of tel uw maandelijkse bestellingen. Deel dit door 30 * 24 * 60 = 43.200 dat is het aantal minuten in een maand (ongeveer). Dat is uw gemiddelde bezoekers per minuut over de hele maand. Vermenigvuldig dit met drie. Dat is uw gemiddelde bezoekers per minuut tijdens kantooruren (ongeveer). Verdubbel dit. Dat is waarschijnlijk een veilig cijfer voor de Queue Rate om te gebruiken.
Laten we bijvoorbeeld zeggen dat u 100.000 bestellingen per maand verwerkt - dat zijn 100.000 klikken op de knop "Nu kopen". Dat is 100.000 / 43.200 = 2,31 bestellingen per minuut. Je zou verwachten dat de meeste van deze bestellingen overdag worden gedaan, en dat je servers 's nachts rustiger zijn, dus vermenigvuldig dit met 3 en dat is 7 bestellingen per minuut als een ruwe schatting van hoe druk je server is tijdens kantooruren. Als het resultaat minder dan 50 is: er zijn pieken en dalen in de vraag, dus als je server niet merkbaar traag is tijdens piekuren, vermenigvuldig dit dan met 2 om 14 actieve gebruikers per minuut te krijgen. Als het getal meer dan 50 is: pieken en dalen van minuut tot minuut zullen in vergelijking kleiner zijn, en het is niet veilig om dit te verdubbelen. Het getal waarmee u eindigt is waarschijnlijk een veilig getal voor de Queue Rate om mee te beginnen en komt overeen met het aantal verzoeken per seconde dat u veilig kunt beheren; u kunt het altijd verhogen als u vindt dat uw systemen bij die snelheid nog steeds responsief zijn voor eindgebruikersprestaties.
Als je orders van een tijdstempel zijn voorzien, kun je ook kijken naar het maximum aantal orders dat je de afgelopen maand in één minuut hebt geplaatst - maar wees voorzichtig, want je weet niet hoeveel orders je in die minuut hebt laten vallen doordat je servers trager werden, dus verminder dit met 20%.
De rest van dit artikel bespreekt enkele andere manieren om de Queue Rate te berekenen.
Het is de moeite waard erop te wijzen dat er ten minste twee definities van "gelijktijdige gebruikers" in het gewone gebruik zijn.
Wij gebruiken de definitie: "het aantal mensen dat op een bepaald moment bij een transactiestroom betrokken is". Dat is het belangrijkste getal dat je moet weten om de Queue Rate in te stellen. Dat is het aantal gebruikers dat uw site op dat moment bekijkt. Het aantal gelijktijdige sessies is meestal iets groter dan het aantal gelijktijdige verbindingen of gelijktijdige gebruikers, omdat sommige sessies bezig zijn uit te timen, waardoor de gemiddelde sessieduur toeneemt.
Dit in tegenstelling tot het aantal Concurrent Requests, dat het aantal HTTP-verzoeken is dat door uw webserver op een bepaald moment wordt verwerkt. Heel verwarrend is dat veel technische mensen bedoelen hoeveel Concurrent Requests als ze zeggen hoeveel Concurrent Users.
Dan is er "Concurrent Connections" (of gelijktijdige TCP verbindingen naar dezelfde server poort op je netwerk interface kaart), wat het aantal TCP/IP Sockets is dat open staat op je server poort of backend service op een bepaald moment. Wanneer een browser een pagina opvraagt, laat hij standaard de verbinding open voor het geval de pagina nog meer opvraagt, of de gebruiker naar een andere pagina gaat. Dit vermindert het aantal verzoeken per seconde om nieuwe TCP/IP-verbindingen te openen, waardoor het serverproces efficiënter wordt. Time-outs voor deze gelijktijdige verbindingen variëren per browser, van 60 seconden tot "never-close". Je server kan ook automatisch verbindingen sluiten na een periode van geen activiteit. Op Linux webservers kun je met dit commando een telling krijgen van het aantal gelijktijdige verbindingen naar dezelfde serverpoort: netstat -aenp | grep ":80 \|:443 " | wc -l
die je kunt proberen als je nieuwsgierig bent. Nogmaals, sommige mensen noemen dit ook "Concurrent Users", terwijl het eigenlijk gelijktijdige verbindingen betekent.
Als u uw hostingprovider vraagt u het maximum aantal gelijktijdige gebruikers te vertellen dat uw webserver aankan (hoeveel piekverkeer), zullen ze u waarschijnlijk een cijfer geven voor gelijktijdige sessies, gelijktijdige verzoeken of gelijktijdige verbindingen, om de eenvoudige reden dat ze uw gemiddelde transactietijd, het aantal pagina's in uw transactiestroom of andere informatie niet kennen waarmee ze u zouden kunnen vertellen hoeveel gelijktijdige gebruikers uw webserver aankan. Al deze getallen hebben verschillende waarden.
Als u uw hostingprovider of technisch team om informatie vraagt over maximale verkeersniveaus, is het superbelangrijk dat u verduidelijkt of ze Concurrent Users, Concurrent Sessions, Concurrent Requests of Concurrent Connections bedoelen.
Dit is waarom. Elke pagina is een enkel HTTP-verzoek, maar alle afbeeldingen, scripts en andere bestanden die uit uw webapplicatie komen en die de browser gebruikt om de pagina weer te geven, zijn ook HTTP-verzoeken.
Stel dat uw technisch team u heeft verteld dat de server 500 gelijktijdige gebruikers ondersteunt, maar ze bedoelen eigenlijk 500 gelijktijdige verzoeken. Met uw 5 minuten transactietijd, gebruikt u de bovenstaande formule en neemt u aan dat uw site 100 bezoekers per minuut kan ondersteunen.
Kan het? Nee.
Terwijl mensen door de transactiestroom gaan, doen ze eigenlijk alleen maar verzoeken aan uw servers terwijl elke pagina wordt geladen. Dit beïnvloedt hoeveel verkeer per seconde of actieve gebruikers uw server aankan. Van de vijf minuten transactietijd, is dat slechts een paar seconden voor een gemiddelde gebruiker. Je zou dus kunnen denken dat 500 Concurrent Requests betekent dat je veel meer Concurrent Users aankunt, maar je zou het wel eens mis kunnen hebben. Ziet u nu hoe ingewikkeld het is om inzicht te krijgen in de capaciteit van uw website in termen van hoeveel verkeer of totaal aantal actieve gebruikers?
Om uw maximum aantal gelijktijdige gebruikers te berekenen uit uw maximum totaal aantal gelijktijdige aanvragen, moet u ook het volgende weten
U kent waarschijnlijk 1) en 2) al - in ons voorbeeld zijn het 6 pagina's en 5 minuten. U kunt gemakkelijk de pagina's tellen die u ziet terwijl u een transactie doet. Als u de gemiddelde transactietijd niet kent, kan Google Analytics het u vertellen, of u kunt de logs van uw webserver controleren.
Voor 3) en 4), kan de Firefox browser helpen. Klik met de rechtermuisknop op een pagina op uw site, kies Inspect Element, en het tabblad Netwerk. Druk vervolgens op CTRL-SHIFT-R om de pagina volledig te vernieuwen. U ziet dan de laadtijden van elk element van de pagina in de lijst. Je moet er zeker van zijn dat je de overdrachtsgrootte kunt zien in de kolom Overgebracht, omdat anders bestanden uit een cache kunnen komen, wat je berekeningen in de war kan sturen. Het kan zijn dat sommige scripts en andere bronnen van andere servers dan uw site komen, dus u kunt de domeinnaam van uw site in het filtervak aan de linkerkant typen. Om de kolom Duur te zien, klik met de rechtermuisknop op een kolomkop en selecteer Timings -> Duur in het pop-up menu. Uw scherm zou er dan zo uit moeten zien:
Het Firefox Netwerk tabblad voor deze pagina, toont Duur en aantal Verzoeken van queue-fair.com
Bestanden die gebruikt worden in de weergave van uw pagina's kunnen van verschillende sites komen, dus u kunt ook het filter linksboven gebruiken om alleen die van uw site te tonen - maar alleen als u zeker weet dat die bestanden van andere sites niet de reden zijn voor trage pagina-ladingen, of deel uitmaken van uw knelpunt.
Firefox telt de verzoeken voor u linksonder in het scherm, en toont 36 HTTP verzoeken voor alleen deze ene pagina.
Je moet dit doen voor elke pagina in je transactiestroom - tel het totaal en deel door het aantal pagina's om het gemiddelde aantal HTTP verzoeken voor elke pagina te vinden, nummer 3) in onze lijst. Je ziet nu waarom het aantal kindverzoeken voor elke HTML-pagina zo'n belangrijke factor is voor de hoeveelheid verkeer die je webserver aankan.
Voor nummer 4) moet je naar de kolom Duur kijken en het gemiddelde vinden voor alle HTTP-verzoeken voor al je pagina's. Als je het niet zeker weet, ga dan uit van een halve seconde - er zit sowieso veel onzekerheid in (zie hieronder).
Laten we enkele voorbeeldgetallen geven. We hebben al gezegd dat er zes dynamische pagina's zijn in de processtroom van de voorbeeldserver, wat 1) is, en dat de gemiddelde transactietijd vijf minuten is, wat 2) is. Laten we uitgaan van 36 HTTP-verzoeken per pagina voor 3), en een halve seconde voor de server verwerkingstijd voor elk HTTP-verzoek, dat is 4).
Met deze getallen kan een server die 500 Concurrent Requests kan verwerken, 500 / (0,5 seconde) = 1000 HTTP-verzoeken per seconde verwerken, wat neerkomt op 60.000 HTTP-verzoeken per minuut, wanneer hij volledig is opgebruikt.
Over de vijf minuten transactietijd, kan het 5 * 60.000 = 300.000 HTTP verzoeken afhandelen. Lijkt veel, toch?
Maar, voor elke bezoeker zijn er zes pagina's met een gemiddelde van 36 HTTP verzoeken elk, dus dat is 6 * 36 = 216 verzoeken
Dus, de 300.000 HTTP-verzoeken capaciteit kan in theorie 300.000 / 216 = 1.389 gelijktijdige gebruikers aan
Hé, dat is geweldig! We dachten dat we maar een wachtrij van 100 konden hebben, maar 1.389 / 5 minuten = 278 bezoekers per minuut, dus we kunnen een hogere wachtrij hebben!
Nou, waarschijnlijk niet. Ten eerste zullen uw bezoekers niet netjes verzoeken verzenden met tussenpozen van precies een halve seconde, zoals de bovenstaande berekening veronderstelt. Belangrijker is dat u uw invoergegevens hebt gemeten wanneer de site niet druk is. Vuilnis in, vuilnis uit.
Als het druk is op de site, doet de server er langer over om verzoeken te verwerken - je zult dit op andere sites wel gemerkt hebben als het druk is, dat je langer op pagina's moet wachten. Dit verhoogt de gemiddelde tijd die je server nodig heeft om een enkel HTTP-verzoek te verwerken (4), wat de maximale doorvoer verlaagt. Dus neem de 278 bezoekers per minuut en halveer het. Halveer het dan nog eens. Je kijkt waarschijnlijk realistisch naar ongeveer 70 nieuwe bezoekers per minuut bij maximale belasting.
Andere verstorende factoren zijn onder meer caching, waardoor de browsers van uw bezoekers niet elk verzoek voor elke afzonderlijke pagina hoeven te doen - dit betekent dat de server minder middelen nodig heeft en het aantal nieuwe bezoekers per minuut dat uw server aankan, kan verhogen. Load balancers die de belasting over meerdere servers verdelen, en het serveren van statische inhoud in plaats van dynamische pagina's kunnen uw serverproces ook versnellen, aangezien elke server minder resources nodig heeft.
U zult ook merken dat het niet voor alle pagina's even lang duurt om ze te voltooien, omdat sommige minder middelen vergen dan andere om ze te produceren en te serveren. Zoeken in databases, zoekopdrachten en updates duren het langst, dus er zal ergens in uw proces een bottleneck zijn waar mensen zich opstapelen, wachtend tot creditcardgegevens zijn verwerkt en bestellingen zijn opgeslagen, of wachtend tot de beschikbaarheid is gecontroleerd. Elke transactiestroom heeft een traagste stap, dus er is altijd wel ergens een knelpunt, en er is altijd een antwoord met een maximumwaarde op de vraag hoeveel gelijktijdige gebruikers een webserver aankan - en er kunnen meerdere limieten mee gemoeid zijn. In dat geval wil je je Queue Rate laag genoeg instellen om er zeker van te zijn dat je server genoeg cpu-tijd heeft om genoeg mensen gelijktijdig te verwerken voor de traagste stap in je proces, zodat mensen zich daar niet opstapelen. Anders kan je webserver letterlijk tot stilstand komen.
Onze ervaring is dat iedereen bij de eerste verkoop de capaciteit van zijn server om grote hoeveelheden verkeer aan te kunnen, overschat.
Iedereen.
Het nauwkeurig vaststellen van de gemiddelde sessieduur en eindgebruikersprestaties tijdens traag of piekverkeer is niet voor doetjes. Het beste is om een echte belastingstest uit te voeren, met 'nepklanten' die het bestelproces doorlopen tijdens de belastingstest, precies zoals ze in het echt zouden doen, met dezelfde HTTP-verzoeken in dezelfde volgorde, met dezelfde wachttijden tussen pagina's tijdens de belastingstest als in het echt, en houd uw processorbelasting, IO-doorvoer en responstijden in de gaten terwijl u het aantal virtuele bezoekers opvoert. U kunt hiervoor Apache JMeter gebruiken (wij houden ook van K6 voor lichtere belastingen of tragere machines), maar welke tool u ook gebruikt, het is tijdrovend en lastig om het gedrag van elke afzonderlijke gebruiker precies goed na te bootsen (vooral met de complexiteit van caching). Zelfs dan, neem je maximum aantal en halveer het.
Als dat niet zo is, ga dan voorzichtig te werk.
U kunt de wachtrijsnelheid voor elke Queue-Fair wachtrij op elk moment eenvoudig wijzigen via de Queue-Fair portal. Begin met 10 bezoekers per minuut, of uw transactiesnelheid op een meer normale dag, kijk hoe dat gaat voor een tijdje nadat uw tickets in de verkoop gaan, en als alles er goed uitziet, uw processorbelasting laag is, uw sql database in orde is en (bovenal) uw pagina's reageren wanneer u op CTRL-SHIFT-R drukt, verhoog het dan met niet meer dan 20 procent, wacht even, en herhaal. Je zult al snel de werkelijke snelheid vinden die je nodig hebt tijdens deze 'load balancing' (zie je wat we daar deden?), en onthoud, vanuit het oogpunt van klantervaring is het prima om de wachtrijsnelheid te verhogen omdat dit ervoor zorgt dat de geschatte wachttijden die je klanten in de wachtrij zien, afnemen, en iedereen is blij om een responstijd te zien die een kortere geschatte wachttijd oplevert.
Wat je moet vermijden is dat je de Queue Rate te hoog instelt en hem dan moet verlagen, omdat dit a) betekent dat mensen die de site gebruiken trage pagina's te zien krijgen, en b) ervoor zorgt dat de geschatte wachttijden toenemen. Alle mensen in je wachtrij zullen zuchten!
Vergeet niet dat je ergens in je bestelproces een knelpunt zult hebben - elke transactie heeft een traagste stap - en dat je daar meerdere sessies zult krijgen die zich opstapelen. Wat je niet wilt doen is een minuut in je ticketverkoop komen, zien dat je server processorbelasting ver onder het maximum aantal zit, en de snelheid verhogen. Je bezoekers zijn waarschijnlijk nog niet verder gekomen dan de "Koop nu" knop. Je wilt wachten tot je sql database nieuwe orders rapporteert met dezelfde of vergelijkbare snelheid als je Queue Rate en dan je metingen en responsiviteitstesten doen. Vergeet niet dat elke keer dat je de snelheid verhoogt, het dezelfde hoeveelheid tijd zal nemen voor de extra bezoekers om je knelpunt te bereiken, dus je zult niet in staat zijn om nauwkeurig te beoordelen hoe je server presteert bij de nieuwe snelheid totdat die tijd is verstreken.
We hebben al besproken hoe u de Queue Rate het beste geleidelijk kunt verhogen zodra uw wachtrij is geopend. U weet waarschijnlijk dat uw servers een limiet hebben die niet kan worden overschreden zonder dat het systeem crasht en misschien weet u zelfs wat de limiet is - maar wat u misschien niet weet is dat als de belasting deze limiet nadert, er meestal weinig signalen zijn - vaak alleen een paar fouten of waarschuwingen, of een processorbelasting van meer dan 80%.
Wanneer webdiensten falen, hebben zij de neiging zeer snel te "knappen" of vast te lopen. Dit komt meestal doordat, zodra uw systeem de verzoeken niet meer zo snel kan verwerken als ze binnenkomen, zich interne wachtrijen opbouwen. Uw systeem moet dan het werk doen van het verwerken, beheren en opslaan van de interne wachtrijen en de verzoeken, en dat is wat servers over de rand doet slaan. Heel snel. Zodra dat gebeurt, kunnen uw servers misschien een tijdje reageren met een foutpagina, maar dit helpt u niet omdat de bezoekers die het zien onmiddellijk op Refresh zullen klikken, waardoor de belasting nog groter wordt.
Zelfs voor die tijd, als het langer dan ongeveer een seconde duurt voordat bezoekers je pagina's zien, drukken ze op Vernieuwen. Wanneer een bezoeker op refresh drukt, weet je webserver niet dat de bezoeker niet langer wacht op het antwoord op het oorspronkelijke verzoek. Als zowel het oorspronkelijke als het refresh-verzoek worden ontvangen, zal je webserver ze allebei verwerken. Dat betekent meer werk voor uw webserver, nog tragere antwoorden voor al uw bezoekers en meer mensen die op refresh klikken, wat resulteert in een vicieuze cirkel die uw webserver afbreekt nog voor hij foutreacties begint te sturen.
Dus, push je servers niet harder dan nodig is. Gaan voor die laatste 20% van de cpu-tijd capaciteit is meestal niet het risico waard. Als de wachtrijgrootte die in de Queue-Fair Portal wordt getoond (het gele wachtrijcijfer en de gele lijn in de grafieken) afneemt of zelfs maar langzaam toeneemt, minuut voor minuut, en de getoonde wachttijd 50 minuten of minder is, dan verwerk je orders snel genoeg en zal de wachtrij uiteindelijk automatisch leeglopen en stoppen met het tonen van wachtrijpagina's, zonder dat je iets hoeft te doen, en zonder dat je je baas hoeft te vertellen dat je te hard hebt gepusht en het kapot hebt gemaakt. Je komt er uiteindelijk wel zolang de snelheid van de voorkant van de wachtrij hoger is dan het aantal joins per minuut (die beide worden getoond in de Queue-Fair Portal) - het omslagpunt ligt meestal op zijn minst een paar minuten na elk evenement. Als u een product in beperkte hoeveelheden verkoopt, zult u waarschijnlijk uitverkocht zijn voordat het omslagpunt is bereikt.
Het goede nieuws is dat als u per ongeluk de Queue Rate te hoog instelt en uw servers het begeven, Queue-Fair u kan helpen snel weer aan de slag te gaan - zet de wachtrij gewoon op Hold totdat uw servers weer klaar zijn om bezoekers te verwerken. In Hold-modus zien mensen in de wachtrij een speciale Hold-pagina die u kunt ontwerpen voor uw online evenement. Niemand wordt doorgelaten vanaf de voorkant van de wachtrij wanneer deze in de wachtstand staat, maar nieuwe internetbezoekers kunnen zich nog steeds achteraan aansluiten in de wachtrij, om eerlijk te worden geplaatst zodra de blokkade is opgeheven, wat zeer snel zal gebeuren omdat Queue-Fair uw site beschermt tegen de vraag. De Hold Page is een superieure gebruikerservaring dan wanneer u de Queue Rate echt laag zet, vooral als u deze update om de bezoekers te vertellen hoe laat u verwacht dat de Queue weer open gaat, wat eenvoudig te doen is met de Portal page editor, zelfs wanneer er al honderdduizenden mensen in de wachtrij staan - en in Hold mode kunt u ze zelfs één voor één doorlaten met Queue-Fair's unieke Admit One knop als dat nodig is terwijl uw systeem herstelt van de knak.
Dus, als u merkt dat uw servers een pauze moeten nemen tijdens uw evenement, is de Hold-pagina precies wat u daarvoor nodig hebt, en het zal uw servers ook helpen sneller te herstellen.
In dit artikel hebben we uitgelegd waarom een wachtrij op basis van snelheid altijd de beste oplossing is, en hebben we twee methodes gegeven om de snelheid te berekenen die u nodig hebt, maar tenzij u uw hele transactiestroom volledig en nauwkeurig hebt getest op virtuele bezoekersbelasting, en daar echt super extra mega zeker van bent, is ons advies altijd hetzelfde:
Als u een product in beperkte hoeveelheden verkoopt, hoeft u ook geen aandacht te besteden aan stap 7.
Dat is voor uw eerste wachtrij, wanneer u de werkelijke maximum Queue Rate die uw systeem kan ondersteunen, niet kent. Voor latere wachtrijen, wanneer u de werkelijke Queue Rate gemeten hebt, kunt u misschien hetzelfde cijfer gebruiken - maar alleen als er niets veranderd is aan uw systeem. In de praktijk wordt uw systeem waarschijnlijk voortdurend verder ontwikkeld en aangepast, en weet u misschien niet hoe recente wijzigingen uw maximum Queue Rate hebben beïnvloed - waarom begint u dan niet bij de helft van het vorige gemeten cijfer en herhaalt u het bovenstaande proces?
Dus zo gebruik je Queue-Fair om je onsale mooi en veilig te maken, en onthoud, het is altijd beter om het zekere voor het onzekere te nemen.
2024 The Fair Queue People Ltd. - Alle rechten voorbehouden.
Maakt deel uit van de Orderly-familie van wachtrijoplossingen - OrderlyQ - OrderlyStats - WeQ4U
