Overlevende en trafik spike: hvordan et venteværelse holder dit websted i live
Nogle gange overstiger efterspørgslen simpelthen, hvad dit websted kan håndtere - et produktdråbe, et viralt øjeblik, en billetudgivelse. Et venteværelse er forskellen mellem en kø og et nedbrud.
Et venteværelse er en virtuel kø, der sidder foran dit websted. Når der ankommer flere besøgende, end du sikkert kan betjene, optager det folk op til en kapacitetsgrænse og holder resten, viser deres position og en anslået ventetid. I stedet for at alle får et brudt websted, får folk indeni en, der fungerer, og køen bevæger sig støt. Den hårde del er ikke køen - det er at vælge kapacitetsnummeret.
Der er en fejltilstand, som caching ikke løser. Caching fungerer, fordi de fleste anmodninger er for det samme indhold; der er et venteværelse til den situation, hvor de ikke er - hvor tusindvis af mennesker samtidig har brug for de virkelig dynamiske dele af dit websted. Tilføjelse til en vogn. Tjekker inventaret. Betaler.
Du kan ikke cache din vej ud af det, fordi hver af disse anmodninger er legitimt anderledes og legitimt dyrt. På det tidspunkt har du præcis to muligheder, og kun en af dem ender med salg.
Med et venteværelse
- Besøgende indrømmet få en fuldt fungerende hjemmeside
- Alle andre ser en klar position og vurderer
- Din oprindelse holder sig inden for sine grænser
- Salget fortsætter hele tiden
Uden en
- Alle kommer på én gang
- Webstedet bremser, så gange ud
- Ingen gennemfører et køb, herunder de tidlige ankomster
- Gentagelser gør det værre
Fejltilstanden uden kø er værre end den først ser ud. Under overbelastning, anmodninger ikke fejler rent de kø inde i din ansøgning, time out efter tredive sekunder, og den besøgende straks opdateres, tilføje en anden anmodning til et system, der allerede er bagud. Et crash under load er selvforstærkende på en måde, som en kø ikke er.
Sådan fungerer køen
En besøgende ankommer og bliver tjekket
Kanten søger efter en gyldig session token. Hvis de allerede har en, passerer de lige igennem uden forsinkelse og ingen rundtur til noget.
Hvis der er plads, er de optaget
Under kapacitetsgrænsen er adgangen øjeblikkelig og usynlig. De fleste besøgende på de fleste dage ved aldrig, at venteværelset eksisterer.
Hvis ikke, går de ind i køen
De modtager en køside, der viser deres position og en anslået ventetid, som poller for opdateringer.
Slots fri og køen går videre
Når aktive sessioner slutter - gennem checkout, inaktivitet eller forlader - optages de næste personer i kø automatisk.
Hvordan køen ved, at nogen har forladt
Dette er den del, der afgør, om en kø flyttes eller stalls. Hvis optagelsen kun blev frigivet, når en session udløb på en timer, ville en kø gå videre med timeoutets hastighed, uanset hvad folk rent faktisk gjorde.
I praksis tre signaler gratis en slot. En indlagt besøgendes browser sender en periodisk hjerterytme, så systemet ved, at de stadig er der. Når de lukker fanen, sender browseren et afgangsfyr, der frigiver pladsen med det samme. Og hvis hjerteslag stopper uden et afgangssignal - en bærbar låg lukker, et telefon taber signal - frigives sessionen efter en inaktivitetstimeout. De første to er, hvad der gør en kø føles lydhør; den tredje er sikkerhedsnettet.
Valg af kapacitetsnummer
Dette er den virkelig hårde del, og at sætte det forkert i begge retninger er dyrt.
For højt og venteværelset gør intet - du indrømmer flere mennesker, end webstedet kan tjene, alle inde har en dårlig tid, og du har tilføjet en kø til et brudt websted. For lavt, og du står i kø unødigt, hvilket er en reel omkostning: en del af alle, der bliver bedt om at vente, forlader simpelthen.
Tallet skal komme fra en belastningstest, ikke fra intuition. Find den samtidighed, hvor dine responstider begynder at klatre, mens gennemstrømningen stopper med at forbedre, og sæt derefter kapaciteten lidt under det bøjningspunkt, så der er hovedrum. To yderligere overvejelser:
- Kapacitet betyder samtidige aktive sessioner, ikke anmodninger per sekund. En besøgende tomgang på en produktside forbruger et slot, mens det koster ingenting.
- Sessionens varighed er lige så vigtig som kapaciteten. Med 500 slots og 10-minutters sessioner, du indrømmer 3.000 mennesker i timen; halvere session længde og du fordobler gennemløb med risiko for at skubbe nogen midt-checkout.
- Omgå alt, hvad der ikke er en person shopping. Statiske aktiver, sundhedstjek, dit eget holds adresser, betalingsudbyder callbacks. En kø, der fanger din overvågning, er en kø, der blinder dig præcis, når du skal se.
Gør ventetiden tålelig
Kø psykologi er en reel og velundersøgt ting, og det kommer ned til en konstatering: usikre venter føler langt længere end kendte. En kø, der siger "du er nummer 1.240 af 4.100, omkring seks minutter" opleves som dramatisk kortere end den samme ventetid med en spinner.
Hvilket betyder, at køen side fortjener mere tanke end det normalt får. Vis positionen og opdater den synligt, så nummeret, der flyttes, er bevis på, at systemet fungerer. Giv et skøn og vær konservativ - et skøn, der vokser, er langt værre end et, der krymper. Forklar kort hvorfor køen eksisterer, da "høj efterspørgsel" er betryggende, hvor en uforklarlig ventetid er alarmerende. Og indrøm automatisk i stedet for at bede folk om at opdatere, fordi en person, der træder væk, ikke skal miste deres plads.
Tænd for venteværelset før Trafikken kommer, ikke undervejs. Aktivering af det, mens webstedet allerede fejler, betyder, at køen selv skal konfigureres under belastning, og det første en kø gør, er kortvarigt at øge anmodninger, da alles side genindlæses.
Ofte stillede spørgsmål
Hvad er et venteværelse på en hjemmeside?
Et venteværelse, eller virtuel kø, er et system, der sidder foran en hjemmeside og begrænser, hvor mange besøgende der er aktive på én gang. Besøgende, der ankommer, mens webstedet er under dets kapacitetsgrænse, passerer straks; dem, der ankommer, når det er fuldt, holdes på en køside, der viser deres position og anslåede ventetid, og optages automatisk som slots fri.
Hvornår skal jeg bruge et venteværelse?
Når efterspørgslen virkelig overstiger, hvad din infrastruktur kan tjene, og trafikken ikke kan cachelagres væk - produktfald, billetsalg, lanceringer med begrænset lager og virale øjeblikke. Det er ikke en erstatning for caching, som håndterer det langt mere almindelige tilfælde af mange mennesker, der anmoder om det samme indhold. Det er for når tusindvis af mennesker samtidig har brug for dynamiske, per person operationer såsom checkout.
Hvordan bestemmer jeg kapaciteten til et venteværelse?
Udled det fra en belastningstest snarere end intuition. Find det samtidige niveau, hvor svartiderne begynder at klatre, mens gennemstrømningen stopper med at forbedre, og sæt kapacitet under det punkt for at forlade hovedrum. Bemærk, at kapacitet betyder samtidige aktive sessioner i stedet for anmodninger pr. sekund, og at sessionens varighed betyder lige så meget som grænsen - kortere sessioner flytter flere mennesker igennem, med risiko for at skubbe nogen ud Midt i kassen.
Hvordan ved et venteværelse, hvornår nogen går?
Gennem tre signaler. Indrømmede besøgendes browsere sender periodiske hjerteslag, der bekræfter, at de stadig er til stede; lukning af en fane sender et afgangsfyr, der frigiver pladsen straks; og hvis hjerteslag stopper uden et afgangssignal, sessionen frigives efter en timeout for inaktivitet. De to første holder køen i bevægelse, mens timeout fanger lukkede bærbare computere og mistede forbindelser.
Mister venteværelset dine kunder?
En vis andel af de besøgende i kø vil forlade stedet, hvorfor kapaciteten ikke bør sættes unødigt lavt. Men alternativet under ægte overbelastning er ikke et hurtigt websted - det er et websted, hvor anmodninger om timeout, besøgende opdaterer og gør det værre, og ingen gennemfører et køb, herunder dem, der ankom først. En kø konverterer nogle besøgende; et overbelastet websted konverterer næsten ingen.
Reserver det for de øjeblikke, der garanterer det - dråber, på salg, den dag du uventet ender på forsiden af noget - og et venteværelse bliver "webstedet gik ned" i "Jeg ventede to minutter og fik min". Hvilket er en samtale dit support team ville meget gerne have.
Mads har arbejdet i IT - for det meste hosting - siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig, sikker infrastruktur enkel at bruge.
