V podstatě jsme nenašli žádné klady hry one-out, one-in. Stručně řečeno, problém tohoto přístupu spočívá v tom, že pokud jsou uživatelé návštěvníky webových stránek elektronického obchodování, webový server neví, kolik má v daném okamžiku souběžných uživatelů. To je překážka. Zde je důvod.
Dále v tomto článku vám také poradíme, jak používat virtuální místnost založenou na sazbě také k ochraně vašeho webu.
Tradičně se servery pro elektronické obchodování zajišťují tak, aby podporovaly maximální počet souběžně pracujících uživatelů, a často se takto definuje i zatížení. Při použití tohoto přístupu pro spuštění fronty webových stránek je problém - problém, který řešíme pomocí sazeb.
Problém vzniká proto, že návštěvníci ve skutečnosti používají webový server pouze v době, kdy jejich prohlížeč načítá jednotlivé webové stránky.
Řekněme například, že web elektronického obchodu prodává vstupenky. Od začátku cesty návštěvníka až do konce cesty návštěvníka (relace uživatele) existuje šest stránek, jak návštěvník
Celý proces transakce trvá v průměru pět minut.
Řekněme, že každou minutu přijde například 100 návštěvníků, kteří si chtějí koupit vstupenky, a průměrná doba dokončení procesu je pět minut. V daném časovém okamžiku je v procesu transakce současně 500 lidí a server musí být připraven na podporu 500 souběžných uživatelů.
Mohlo by se zdát, že lze vytvořit počítadlo souběžných uživatelů, které se inkrementuje pokaždé, když na domovskou stránku přijde nový návštěvník, a dekrementuje pokaždé, když návštěvník dokončí transakci, a které by vám řeklo, kolik uživatelů v daném okamžiku zpracovává jeden server, ale to nebude fungovat.
Nebude to fungovat, protože ne každý návštěvník transakci dokončí. Lidé si to rozmyslí, rozptýlí se nebo odejdou a vrátí se později. Protože webový server komunikuje s návštěvníky pouze v okamžiku, kdy jejich prohlížeče načítají stránky, nemá webový server možnost zjistit, kdy se tak stalo a komu.
Aby bylo možné určit, že návštěvník již není součástí transakčního procesu, musí jediný server počkat, zda od něj nepřijdou další požadavky na stránku, a poté relaci návštěvníka ukončit. Časový limit musí být vždy nastaven na mnohem delší dobu, než je průměrná doba transakce (v tomto příkladu například 20 minut), protože některým návštěvníkům trvá dokončení transakce mnohem déle než jiným.
Tímto způsobem by bylo možné přidat možnost snižovat pomyslný čítač souběžně pracujících uživatelů pokaždé, když relace návštěvníka skončí, ale to dává velmi špatné výsledky.
Pokud 10 % ze 100 návštěvníků, kteří přijdou každou minutu, nedokončí transakci, ti, kteří ji dokončí, budou aktivní v průměru pět minut a ti, kteří ji nedokončí, budou považováni za aktivní vždy alespoň 20 minut (ve skutečnosti je pravděpodobnější, že při zohlednění více relací bude časový limit relace plus průměrná doba trvání relace).
To je 90 * 5 + 10 * 20 = 650 a server bude hlásit 650 souběžných uživatelů, i když je ve skutečnosti méně vytížený!
Navíc až 10 * 20 = 200 z těchto souběžných uživatelů ve skutečnosti web nepoužívá a je v procesu časování, což je více než 30 % nahlášených souběžných uživatelů, i když je to pouze 10 % návštěvníků, kteří nedokončí transakci.
Nyní řekněme, že si někdo přeje přidat na tuto webovou stránku frontu řízenou naším počítadlem současných uživatelů. Jakmile je kapacita webu naplněna, bude jednotlivec, který je v čele fronty, na web předán až po snížení hodnoty počítadla. Tomuto postupu se říká fronta "jeden ven - jeden dovnitř". Stane se, že ve 30 % případů bude osoba v čele fronty čekat, až někdo, kdo se nechystá dokončit svou transakci, dokončí nedokončenou transakci.
S vytvořením a spuštěním počítadla a sdílením těchto informací se systémem front je spojena další technická integrace a zatížení webových stránek. Pokud dojde k výpadku nebo poruše mechanismu sdílení nebo počítání, fronta se zasekne. Ještě horší je, že pokud je jediný server natolik vytížen, že nemůže aktualizovat server fronty, aby mu sdělil, že má pustit další osobu, fronta se zasekne také.
Všechny tyto problémy lze snadno a jednoduše vyřešit tím, že místo toho se návštěvníci z čela fronty odesílají konstantní, pevnou rychlostí - v tomto případě 100 návštěvníků za minutu.
Tímto způsobem není nutné měřit skutečný počet současně pracujících uživatelů, není nutná složitá integrace s webovou stránkou pro prodej vstupenek a nehrozí, že by se fronta zasekla.
Proto jsme v roce 2004 vynalezli a patentovali virtuální čekárnu pro vytížené webové stránky založenou na sazbách.
‘Naše webové stránky a služby nemohly uspokojit špičkovou poptávku po našich nabídkách. Queue-Fair nás zachránil! Jednoduché na pochopení a snadné na implementaci, se skvělou podporou v průběhu celého procesu. Nyní můžeme spolehlivě spouštět naše kampaně s jistotou, že to naše webové stránky zvládnou.’
‘Queue-Fair je upřímně řečeno úžasný produkt - vřele doporučujeme. Kéž bychom přešli dříve! Celý proces až po implementaci byl jedním z nejhladších procesů, které jsem kdy zažil. Queue-Fair má další funkce, kterých náš předchozí dodavatel nemohl dosáhnout, takže přechod byl snadný. Každý, kdo hledá produkt pro fronty, by neměl hledat dál. My ho milujeme!’
‘Skvělý nástroj zachránil náš obchod. Zákaznický servis je velmi dobrý. Queue-Fair pro nás řeší nasycení serveru při náročném prodeji vstupenek. Nastavení bylo snadné a líbila se mi efektivita nástroje.’
‘Po úspěšné Kampaň CrowdCube jsme byli zaplaveni dotazy. Chtěli jsme se ujistit, že neztrácíme kontakt s potenciálními zákazníky. Byli jsme ohromeni tím, jak rychle nás společnost Queue-Fair dokázala zprovoznit - instalace byla tak jednoduchá a stačil k ní jediný řádek kódu!’
‘Úžasná podpora a skvělý nástroj. Líbila se mi jednoduchost nastavení a používání. Queue-Fair nám umožnil řídit provoz během spuštění. V loňském roce nám web spadl a měli jsme s tím problémy! Letos se problém vyřešil jednoduchým přidáním skriptu Queue-Fair.’
‘Vynikající služby. Queue-Fair používáme každý měsíc a funguje skvěle. V neděli večer jsme zavolali Queue-Fair, protože jsme dělali kapku. Okamžitě nám odpověděli a problém vyřešili během pěti minut! Zachránili náš drop a vše vyřídili velmi rychle!’
‘Mimořádně skvělý produkt pro řízení dopravy. Potřebovali jsme hladký uživatelský zážitek v prvních dnech spuštění, čehož bylo možné dosáhnout pouze přidáním Queue-Fair. Líbilo se nám, jak snadné bylo nastavení služby Queue Fair v několika jazycích. Možnosti přizpůsobení kódu byly skvělé a čekárnu jsme sladili s naším designovým systémem. Také podpora nám byla po celou dobu nesmírně nápomocná. Vřele doporučujeme. Queue-Fair odvedl svou práci skvěle.’
‘Vynikající! Uživatelsky přívětivé, snadné nastavení a spuštění - a vynikající obchodní komunikace! Queue-Fair funguje skvěle, když se věci rozhoří, a pomáhá snižovat zatížení webu pro prodej letenek. Tím, že byl Queue-Fair vytvořen s ohledem na snadné použití, umožnil jeho používání týmu podpory - není potřeba žádných vývojářů!’
‘Perfektní služba, která nám pomohla s naším nejrušnějším obdobím roku. Bylo s nimi radost spolupracovat, poskytovali nám flexibilitu tam, kde jsme ji potřebovali, a vynikající podporu s rychlou odezvou. Služba přesně odpovídala našim potřebám.’
‘Perfektní řešení pro vydání naší limitované edice figurek! Queue-Fair se velmi snadno implementuje a při nastavování parametrů jsme byli dobře podporováni a vedeni. Reportování v reálném čase je skvělé a umožňuje nám upravovat parametry během akce, aniž by došlo k pádu našeho serveru. Jsme velmi spokojeni a plánujeme používat Queue-Fair pro naše budoucí vydání.’
‘Vynikající produkt podpořený vynikajícím zákaznickým servisem. Queue-Fair je dokonalým řešením pro zvládnutí nárůstu poptávky po vstupenkách prostřednictvím našich webových stránek. Queue-Fair zvládá prudké nárůsty webového provozu, pomáhá předcházet přetížení serveru a umožňuje našim zákazníkům snadno zjistit, že jsou spravedlivě řazeni do fronty. Naši zákazníci mohou sledovat průběh fronty v reálném čase. Produkt a služby společnosti Queue-Fair předčily naše očekávání.’
‘Skvělé! Jsme velmi spokojeni a spokojeni s Queue-Fair, je úžasné mít takovou úroveň podpory. Služba funguje perfektně - prodali jsme tisíce vstupenek během chvilky a Queue-Fair nám pomohla zvládnout provoz během špiček! Queue-Fair doporučujeme i našim servisním partnerům. Jsem opravdu spokojený!’
Pokud víte, kolik souběžných uživatelů webový server zpracovává, a průměrnou dobu trvání transakce nebo návštěvy od první stránky v transakčním toku po stránku s potvrzením objednávky, můžete ji převést na rychlost fronty pomocí Littleova zákona vydělením počtu uživatelů dobou trvání, například takto:
Rychlost fronty = počet souběžně pracujících uživatelů / doba transakce
Queue-Fair bude dodávat návštěvníky na vaše webové stránky rychlostí, kterou určíte - máme zdaleka nejpřesnější umělou inteligenci fronty v oboru, která zajistí, že počet návštěvníků, který chcete každou minutu, je počet návštěvníků, které každou minutu dostanete, a automaticky zohlední lidi, kteří nejsou přítomni, když na ně přijde řada, stejně jako lidi, kteří se vrátí pozdě.
Jak se to promítne do počtu souběžných uživatelů? Samozřejmě, že ne každý návštěvník, který se dostane na vaše stránky, potřebuje k dokončení své transakce přesně průměrnou dobu, ale díky zákonu velkých čísel získáte s Queue-Fair velmi stabilní počet souběžných uživatelů.
Řekněme, že máte například rychlost fronty 100 návštěvníků za minutu. Každou minutu pošleme na váš web 100 návštěvníků v plynulém proudu - to je to, co děláme, a jsme v tom ohromně dobří. Řekněme také, že lidé používají váš web v průměru (průměrně) pět minut, přičemž 70 % z nich trvá od okamžiku, kdy projdou frontou, do okamžiku, kdy provedou poslední požadavek na stránku (ať už dokončí transakci, nebo ne), 4 až 6 minut. To je směrodatná odchylka jedné minuty na obě strany od průměru. Statisticky to znamená, že na každého návštěvníka, kterému to trvá pět a půl minuty, připadne jiný, kterému to trvá čtyři a půl minuty, a tyto rozdíly v délce trvání jednotlivých návštěv v rámci více relací se proto mají tendenci vzájemně rušit, pokud jich počítáte hodně jakýmkoli způsobem. Zákon velkých čísel říká, že toto rušení je tím přesnější, čím větší je počet zúčastněných osob.
Jak přesně? To můžeme zjistit pomocí malé statistiky. Velikost vzorku je 5 * 100 = 500, což je velké číslo. Tolik lidí počítáte. To znamená, že směrodatná chyba průměru pro dobu transakce je 1 (směrodatná odchylka, 1 minuta) vydělená druhou odmocninou velikosti vzorku (tedy druhou odmocninou z 500) podle statistického vzorce pro směrodatnou chybu průměru, což dává směrodatnou chybu průměru pro dobu transakce 0,044 minuty, tedy jen 2,7 sekundy, což je méně než jedno procento.
To znamená, že při rychlosti fronty 100 a době transakce 5 minut plus minus minuta pro každého jednotlivého návštěvníka byste měli očekávat 495 až 505 souběžných uživatelů na vašem webu přibližně 70 % času, takže matematika říká, že použití fronty založené na rychlosti zajistí velmi stabilní zatížení vašich webových serverů podle potřeby.
Je však matematika přesná? Jsou zde určité jemnosti - například velikost vzorku, kterou vesele odmocňujeme, není vždy přesně 500 při každém počítání souběžných uživatelů (tj. v každém časovém okamžiku) a také normální (Gaussovo) rozdělení může dávat záporné časy transakcí, které se v reálném životě nevyskytují. Proto používáme simulátor návštěvník po návštěvníkovi, vteřinu po vteřině, abychom provedli měření pro kontrolu těchto druhů výpočtů, a ten nám říká, že s výše uvedenými čísly byste měli očekávat 493 až 507 návštěvníků v 70 % případů, takže matematika drží pozoruhodně dobře! Měření nám také říká, že váš web bude mít 500 ± 15 souběžných uživatelů nejméně v 95 % případů.
To je pravděpodobně stabilnější než přesnost, s jakou váš webový server dokáže změřit počet lidí, kteří používají vaše stránky! Ještě lepší je, že i když netušíte, jaká je průměrná doba transakce nebo směrodatná odchylka vašich návštěvníků, tyto matematické veličiny existují, ať už je znáte, nebo ne, a vy stejně získáte stabilní zatížení.
Výsledkem je, že Queue-Fair vám s téměř dokonalou přesností zajistí požadovaný počet návštěvníků za minutu, což má za následek velmi stabilní počet souběžných uživatelů na vašich stránkách a stabilní zatížení webového serveru, nad kterým máte plnou kontrolu.
Hurá!
A nyní varování. Je třeba poznamenat, že stabilita počtu souběžných uživatelů na vašich stránkách - a tedy stabilita zatížení vašeho serveru - závisí v rozhodující míře na tom, jak přesně vám poskytovatel virtuální čekárny posílá každou minutu požadovaný počet návštěvníků, a to je proto klíčový faktor při výběru platformy virtuální čekárny. Protože poskytujeme nejpřesnější Virtuální čekárnu na světě, nikdo nezastaví zahlcení vašich serverů lépe než společnost Queue-Fair.
Co když nevíte, kolik souběžných uživatelů server zvládne, nebo jak dlouho trvá transakce? Můžete se podívat na stránku, která bude pravděpodobně vaším úzkým hrdlem - obvykle ta, která je výsledkem kliknutí na tlačítko "Koupit nyní". Pomocí nástroje Google Analytics zjistěte měsíční počet unikátních návštěvníků této stránky nebo spočítejte měsíční objednávky. Vydělte to 30 * 24 * 60 = 43 200, což je počet minut za měsíc (přibližně). To je váš průměrný počet návštěvníků za minutu za celý měsíc. Tuto hodnotu vynásobte třemi. To je váš průměrný počet návštěvníků za minutu během pracovní doby (přibližně). Zdvojnásobte tuto hodnotu. To je pravděpodobně bezpečný údaj, který lze použít pro rychlost fronty.
Řekněme například, že zpracujete 100 000 objednávek měsíčně - to je 100 000 kliknutí na tlačítko "Koupit nyní". To je 100 000 / 43 200 = 2,31 objednávky za minutu. Dá se očekávat, že většina těchto objednávek bude během dne a vaše servery budou v noci klidnější, takže vynásobte tuto hodnotu třemi a získáte 7 objednávek za minutu jako hrubý odhad vytíženosti vašeho serveru během pracovní doby. Pokud je výsledné číslo menší než 50: v poptávce budou špičky a poklesy, takže pokud váš server není ve špičkách výrazně pomalý, vynásobte toto číslo 2 a získáte 14 aktivních uživatelů za minutu. Pokud je číslo větší než 50: minutové špičky a poklesy budou v porovnání s tím menší a není bezpečné toto číslo zdvojnásobovat. Číslo, které vám nakonec vyjde, je pravděpodobně bezpečným údajem pro Queue Rate na začátek a odpovídá tomu, kolik požadavků za sekundu můžete bezpečně zvládnout; vždy jej můžete zvýšit, pokud zjistíte, že vaše systémy při této rychlosti stále reagují na výkon koncových uživatelů.
Pokud jsou vaše objednávky označeny časovou značkou, můžete se také podívat na maximální počet objednávek, které jste přijali v jedné minutě za poslední měsíc - ale používejte s opatrností, protože nebudete vědět, kolik objednávek mohlo během této minuty vypadnout kvůli zpomalení serverů, takže tuto hodnotu snižte o 20 %.
Ve zbytku tohoto článku jsou popsány další způsoby, jak zjistit rychlost fronty.
Stojí za to upozornit, že v běžném použití existují přinejmenším dvě definice "souběžných uživatelů".
Používáme definici "počet osob zapojených do transakčního toku v jednom okamžiku". To je klíčové číslo, které potřebujete znát pro nastavení rychlosti fronty. To je počet uživatelů, kteří si právě prohlížejí váš web. Počet souběžných relací je obvykle o něco vyšší než počet souběžných připojení nebo souběžných uživatelů, protože některé z relací jsou v procesu časování, což zvyšuje průměrnou dobu trvání relace.
Srovnejte to s počtem souběžných požadavků, což je počet požadavků HTTP zpracovávaných webovým serverem v jednom okamžiku. Je velmi matoucí, že řada techniků má na mysli počet souběžných požadavků, když říkají kolik souběžných uživatelů.
Pak je tu Concurrent Connections (neboli souběžná připojení TCP ke stejnému portu serveru na vaší síťové kartě), což je počet soketů TCP/IP otevřených na portu vašeho serveru nebo backendové služby v jednom okamžiku. Při požadavcích na stránku prohlížeče ve výchozím nastavení ponechávají připojení otevřené pro případ, že by stránka provedla další požadavky nebo uživatel přešel na jinou stránku. Tím se sníží počet požadavků na otevření nových připojení TCP/IP za sekundu, což zefektivní proces serveru. Časové limity pro tato souběžná připojení se liší podle prohlížeče, od 60 sekund až po nikdy neuzavřít. Váš server může také automaticky uzavírat spojení po určité době bez aktivity. Na linuxových webových serverech můžete získat počet souběžných připojení na stejný port serveru pomocí tohoto příkazu: netstat -aenp | grep ":80 \|:443 " | wc -l
který můžete vyzkoušet, pokud jste zvědaví. Někteří lidé tomu také říkají "souběžní uživatelé", i když to ve skutečnosti znamená souběžná připojení.
Pokud totiž požádáte poskytovatele hostingu, aby vám sdělil maximální počet souběžných uživatelů, které váš webový server zpracovává (jak velký je provoz ve špičce), pravděpodobně vám skutečně sdělí údaj o souběžných relacích, souběžných požadavcích nebo souběžných připojeních, a to z toho prostého důvodu, že nezná vaši průměrnou dobu transakce, počet stránek v transakčním toku ani žádné další informace, které by mu umožnily zjistit, kolik uživatelů váš webový server zpracovává současně. Všechna tato čísla mají různé hodnoty.
Pokud žádáte poskytovatele hostingu nebo technický tým o informace o maximální úrovni provozu, je velmi důležité, abyste si ujasnili, zda se tím myslí souběžní uživatelé, souběžné relace, souběžné požadavky nebo souběžná připojení.
Zde je důvod. Každá stránka je jeden požadavek HTTP, ale všechny obrázky, skripty a další soubory pocházející z vaší webové aplikace, které prohlížeč používá k zobrazení stránky, jsou také požadavky HTTP.
Představme si, že vám technický tým řekl, že server podporuje 500 souběžných uživatelů, ale ve skutečnosti tím myslel 500 souběžných požadavků. S vaší pětiminutovou transakční dobou použijete výše uvedený vzorec a předpokládáte, že váš web může podporovat 100 návštěvníků za minutu.
Je to možné? Ne.
Když lidé procházejí transakčním tokem, zadávají na vašich serverech požadavky pouze během načítání jednotlivých stránek. To má vliv na to, kolik provozu za sekundu nebo aktivních uživatelů váš server zvládne. Z pětiminutové transakční doby je to pro průměrného uživatele jen několik sekund. Možná si tedy myslíte, že 500 souběžných požadavků znamená, že zvládnete mnohem více souběžných uživatelů, ale můžete se mýlit. Už chápete, jak je pochopení kapacity vašeho webu z hlediska toho, jak velký je provoz nebo celkový počet aktivních uživatelů, tak složitá záležitost?
Chcete-li zjistit maximální počet souběžných uživatelů z maximálního celkového počtu souběžných požadavků, musíte také vědět.
Pravděpodobně již znáte body 1) a 2) - v našem příkladu je to 6 stran a 5 minut. Stránky, které vidíte při provádění transakce, si můžete snadno spočítat. Pokud průměrnou dobu transakce neznáte, může vám ji prozradit služba Google Analytics nebo se můžete podívat do protokolů webového serveru.
V případě bodů 3) a 4) vám může pomoci prohlížeč Firefox. Klikněte pravým tlačítkem myši na stránku na webu, vyberte možnost Inspect Element a kartu Network. Poté stiskněte klávesy CTRL-SHIFT-R, čímž stránku zcela obnovíte. V seznamu se zobrazí časy načítání sítě pro každý prvek stránky. Chtěli byste se ujistit, že ve sloupci Přeneseno vidíte velikosti přenosu, protože jinak by se soubory mohly obsluhovat z mezipaměti, což by mohlo zkreslit vaše výpočty. Možná uvidíte, že některé skripty a další zdroje pocházejí z jiných serverů, než je váš web, proto můžete do pole filtru vlevo zadat název domény svého webu. Chcete-li zobrazit sloupec Doba trvání, klikněte pravým tlačítkem myši na záhlaví libovolného sloupce a z kontextové nabídky vyberte možnost Časové údaje -> Doba trvání. Vaše obrazovka by měla vypadat takto:
Záložka Síť Firefoxu pro tuto stránku zobrazující dobu trvání a počet požadavků z queue-fair.com
Soubory používané při zobrazování stránek mohou pocházet z různých webů, proto je vhodné použít filtr v levém horním rohu a zobrazit pouze soubory z vašeho webu - ale pouze v případě, že jste si jisti, že tyto soubory z jiných webů nejsou příčinou pomalého načítání stránek nebo součástí překážky.
Firefox počítá požadavky v levém dolním rohu displeje a ukazuje 36 požadavků HTTP pouzepro tuto stránku.
Tento postup je třeba provést pro každou stránku v transakčním toku - spočítejte celkový počet a vydělte jej počtem stránek, abyste zjistili průměrný počet požadavků HTTP pro každou stránku (číslo 3) v našem seznamu. Nyní vidíte, proč je počet podřízených požadavků pro každou stránku HTML tak klíčovým faktorem pro to, jak velký provoz váš webový server zvládne.
Pro číslo 4) se musíte podívat do sloupce Doba trvání a zjistit průměr všech požadavků HTTP pro všechny vaše stránky. Pokud si nejste jisti, předpokládejte půl sekundy - i tak je v tomto případě velká nejistota (viz níže).
Uveďme si několik příkladů. Již jsme si řekli, že v příkladovém toku procesů serveru je šest dynamických stránek, což je 1), a že průměrná doba transakce je pět minut, což je 2). Předpokládejme 36 požadavků HTTP na stránku, což je 3), a půl sekundy pro dobu zpracování každého požadavku HTTP serverem, což je 4).
S těmito čísly může server, který zvládne 500 souběžných požadavků, zvládnout 500 / (0,5 sekundy) = 1000 požadavků HTTP za sekundu, což je 60 000 požadavků HTTP za minutu, když je zcela vytížen.
Během pětiminutové transakce zvládne 5 * 60 000 = 300 000 požadavků HTTP. Zdá se to hodně, že?
Na každého návštěvníka však připadá šest stránek s průměrně 36 požadavky HTTP na každou z nich, což je 6 * 36 = 216 požadavků.
Kapacita 300 000 požadavků HTTP tedy teoreticky zvládne 300 000 / 216 = 1 389 souběžných uživatelů.
Hej, to je skvělé! Mysleli jsme si, že můžeme mít pouze 100 návštěvníků ve frontě, ale 1 389 / 5 minut = 278 návštěvníků za minutu, takže můžeme mít vyšší počet návštěvníků ve frontě!
Pravděpodobně ne. Za prvé, návštěvníci nebudou posílat požadavky přesně v půlsekundových intervalech, jak předpokládá výše uvedený výpočet. A co je důležitější, vstupní data budete měřit v době, kdy web není vytížen. Garbage in, garbage out.
Když je web zaneprázdněn, serveru trvá zpracování požadavků déle - určitě jste si toho všimli na jiných webech, když je na nich rušno, že na stránky čekáte déle. Tím se prodlužuje průměrná doba, kterou server potřebuje ke zpracování jednoho požadavku HTTP (4), což snižuje maximální propustnost. Vezměte tedy hodnotu 278 návštěvníků za minutu a snižte ji na polovinu. Pak ji opět snižte na polovinu. Při maximálním zatížení se pravděpodobně reálně dostanete na 70 nových návštěvníků za minutu.
Mezi další matoucí faktory patří ukládání do mezipaměti, což znamená, že prohlížeče návštěvníků nemusí provádět každý jednotlivý požadavek na každou stránku - to obvykle znamená, že server potřebuje méně prostředků a může zvýšit počet nových návštěvníků za minutu, které může server zpracovat. Vyrovnávače zátěže, které rozdělují zátěž mezi několik serverů, a servírování statického obsahu namísto dynamických stránek mohou také urychlit proces vašeho serveru, protože každý server potřebuje méně zdrojů.
Zjistíte také, že ne všechny stránky zaberou stejný čas, protože některé vyžadují méně zdrojů než jiné. Vyhledávání v databázi, dotazy a aktualizace trvají nejdéle, takže někde v procesu budete mít úzké místo, kde se budou hromadit lidé čekající na zpracování údajů o kreditní kartě a uložení objednávky nebo čekající na ověření dostupnosti. Každý transakční tok má nejpomalejší krok, takže někde vždy existuje úzké místo, a na otázku, kolik souběžných uživatelů může webový server zvládnout, vždy existuje odpověď s maximální hodnotou - a může jít o několik limitů. V takovém případě chcete nastavit rychlost fronty dostatečně nízko, abyste zajistili, že váš server bude mít kapacitu procesorového času pro zpracování dostatečného počtu lidí současně pro nejpomalejší krok procesu, aby se tam lidé nehromadili. Jinak se váš webový server může doslova zastavit.
Naše zkušenost je taková, že při prvním prodeji všichni přeceňují schopnost svých serverů zvládnout velký objem provozu.
Všichni.
Přesné určení průměrné délky relace a výkonu koncového uživatele během pomalého nebo špičkového provozu není pro slabé povahy. Nejlepší je provést řádný zátěžový test s "falešnými" zákazníky, kteří při zátěžovém testu skutečně procházejí procesem objednávání přesně tak, jak by to dělali v reálném životě, a při zátěžovém testu zadávat stejné požadavky HTTP ve stejném pořadí, se stejným čekáním mezi stránkami, jaké vidíte v reálném životě, a sledovat zatížení procesoru, propustnost IO a dobu odezvy při zvyšování počtu virtuálních návštěvníků. Můžete k tomu použít Apache JMeter (my máme rádi také K6 pro menší zátěž nebo pomalejší stroje), ale ať už použijete jakýkoli nástroj, je časově náročné a složité napodobit chování každého jednotlivého uživatele přesně správným způsobem (zejména s ohledem na složitost ukládání do mezipaměti). I v takovém případě vezměte své maximální číslo a snižte ho na polovinu.
Pokud to není možné, buďte raději opatrní.
Pomocí portálu Queue-Fair můžete kdykoli snadno změnit rychlost fronty pro jakoukoli frontu Queue-Fair. Začněte na 10 návštěvnících za minutu nebo na své rychlosti transakcí v běžnějším dni, chvíli po zahájení prodeje vstupenek sledujte, jak to jde, a pokud vše vypadá dobře, zatížení procesoru je nízké, databáze sql je v pořádku a (především) stránky reagují na stisknutí klávesy CTRL-SHIFT-R, zvyšte ji maximálně o 20 procent, chvíli počkejte a opakujte. Během tohoto "vyrovnávání zátěže" (vidíte, co jsme udělali?) brzy zjistíte skutečnou rychlost, kterou potřebujete, a nezapomeňte, že z hlediska zákaznické zkušenosti je v pořádku zvýšit rychlost fronty, protože to způsobí, že se zkrátí odhadované čekání, které vidí vaši zákazníci ve frontě, a všichni jsou rádi, že vidí dobu odezvy, která přináší kratší odhadované čekání.
Chcete se vyhnout tomu, aby ste nastavili příliš vysokou rychlost fronty a pak ji museli snížit, protože to a) znamená, že lidé používající web budou mít pomalé načítání stránek, a b) způsobí zvýšení odhadovaných čekacích dob. Všichni lidé ve frontě si povzdechnou!
Nezapomeňte, že někde v procesu objednávání bude úzké místo - každá transakce má nejpomalejší krok - a tam se vám bude hromadit více relací. Určitě nechcete, aby ste se po minutě prodeje letenek dostali do situace, kdy zjistíte, že zatížení procesoru vašeho serveru je hluboko pod maximálním číslem, a zvýšíte rychlost. Vaši návštěvníci se pravděpodobně nedostali ani k tlačítku "Koupit nyní". Chcete počkat, až vaše databáze sql bude hlásit nové objednávky stejnou nebo podobnou rychlostí jako vaše rychlost fronty, a pak provést měření a testy odezvy. Nezapomeňte, že pokaždé, když zvýšíte rychlost, bude trvat stejnou dobu, než se další návštěvníci dostanou k úzkému místu, takže nebudete moci přesně vyhodnotit, jak váš server funguje při nové rychlosti , dokud tato doba neuplyne.
Již jsme si řekli, že po otevření fronty je nejlepší zvyšovat rychlost fronty postupně. Pravděpodobně víte, že vaše servery mají limit, který nelze překročit, aniž by se systém zhroutil, a možná dokonce víte, jaký je to limit - ale možná nevíte, že když se zatížení blíží k tomuto limitu, obvykle se to projeví jen velmi málo - často jen několika chybami nebo varováními nebo zatížením procesoru nad 80 %.
Při selhání webových služeb dochází k jejich rychlému "prasknutí" nebo výpadku. Obvykle je to proto, že jakmile systém již nedokáže zpracovávat požadavky tak rychle, jak přicházejí, vytvoří se interní fronty zpracování. Váš systém pak musí kromě požadavků zpracovávat, spravovat a ukládat i své interní fronty, a to je to, co servery překlopí přes okraj. Velmi rychle. Jakmile k tomu dojde, vaše servery mohou na nějakou dobu reagovat chybovou stránkou, ale to vám nepomůže, protože návštěvníci, kteří ji uvidí, okamžitě stisknou tlačítko Obnovit, čímž se zátěž ještě zvýší.
Pokud návštěvníkům trvá zobrazení stránek déle než jednu sekundu, stisknou tlačítko Obnovit. Když návštěvník stiskne tlačítko Obnovit, váš webový server neví, že návštěvník již nečeká na odpověď na původní požadavek. Pokud je přijat původní požadavek i požadavek na obnovení, váš webový server je zpracuje oba. To znamená více práce pro váš webový server, ještě pomalejší odpovědi pro všechny návštěvníky a více lidí, kteří stisknou tlačítko refresh, což vede k začarovanému kruhu, který váš webový server zasekne ještě předtím, než začne odesílat chybové odpovědi.
Netlačte proto na své servery více, než je nutné. Jít na posledních 20 % kapacity procesoru se obvykle nevyplatí riskovat. Pokud se velikost fronty zobrazená na portálu Queue-Fair (žlutý obrázek a čára Waiting v grafech) snižuje nebo dokonce jen pomaleji roste, minutu po minutě, a zobrazená čekací doba je 50 minut nebo méně, pak zpracováváte objednávky dostatečně rychle a fronta se nakonec vyprázdní a přestane zobrazovat stránky fronty automaticky, aniž byste museli cokoli dělat a aniž byste museli svému šéfovi říkat, že jste na ni příliš tlačili a rozbili ji. Nakonec se vám to podaří, pokud je rychlost fronty vyšší než počet Připojení každou minutu (obojí se zobrazuje na portálu Queue-Fair) - bod zlomu je obvykle alespoň několik minut po každé akci. Pokud prodáváte produkt s omezeným množstvím, pravděpodobně se vyprodá dříve, než je dosaženo bodu zvratu.
Dobrou zprávou je, že pokud omylem nastavíte příliš vysokou rychlost fronty a vaše servery se zaseknou, Queue-Fair vám pomůže rychle obnovit provoz - stačí frontu podržet, dokud nebudou servery opět připraveny přijímat návštěvníky. V režimu Podržení se lidem ve frontě zobrazí speciální stránka Podržení, kterou můžete navrhnout před online akcí. Když je fronta v režimu Podržení, není nikdo z přední části fronty propuštěn, ale noví návštěvníci internetu se stále mohou připojit do fronty vzadu, aby byli spravedlivě zařazeni do fronty, jakmile bude zablokování odstraněno, což se stane velmi rychle, protože Queue-Fair chrání vaše stránky před poptávkou. Stránka Podržení je lepší uživatelský zážitek než nastavení opravdu nízké rychlosti fronty, zejména pokud ji aktualizujete tak, abyste návštěvníkům sdělili, v kolik hodin očekáváte opětovné otevření fronty, což lze snadno provést pomocí editoru stránky portálu, i když jsou ve frontě již statisíce lidí - a v režimu Podržení je dokonce můžete pouštět po jednom pomocí jedinečného tlačítka Queue-Fair Přijmout jednoho, pokud potřebujete, zatímco se váš systém vzpamatovává z jeho záseku.
Pokud tedy zjistíte, že vaše servery potřebují během akce přestávku, stránka Hold je přesně to, co potřebujete, a navíc pomůže vašim serverům rychleji se zotavit.
V tomto článku jsme vysvětlili, proč je fronta založená na rychlosti vždy správnou cestou, a uvedli jsme dvě metody výpočtu potřebné rychlosti, ale pokud jste neprovedli úplné a přesné testování zátěže virtuálních návštěvníků na celém toku transakcí a nejste si tím opravdu extra mega jistí, naše rada je vždy stejná:
Pokud prodáváte výrobek v omezeném množství, nemusíte věnovat pozornost ani kroku 7.
To platí pro první frontu, když neznáte skutečnou maximální rychlost fronty, kterou může váš systém podporovat. Pro další fronty, jakmile změříte rychlost fronty, kterou váš systém skutečně zvládne, můžete opět použít stejný údaj - ale pouze v případě, že se v systému nic nezměnilo. V praxi se váš systém pravděpodobně neustále vyvíjí a upravuje a možná nevíte, jak nedávné změny ovlivnily maximální rychlost fronty - proč tedy nezačít od poloviny předchozího naměřeného údaje a výše uvedený postup nezopakovat?
To je návod, jak používat Queue-Fair, aby byl váš prodej pěkný a bezpečný, a nezapomeňte, že je vždy lepší být v bezpečí než litovat.
Queue-Fair, vynalezená a patentovaná v roce 2004, je původní virtuální čekárna, která poskytuje online správu front pro vytížené webové stránky a aplikace.
2024 The Fair Queue People Ltd. - Všechna práva vyhrazena.
Součást rodiny řešení pro fronty Orderly - OrderlyQ - OrderlyStats - WeQ4U
