Jak používání naší online fronty zabraňuje pádu webu a zhroucení webových stránek - kolik souběžných uživatelů zvládne webový server?

Proč používat virtuální čekárnu založenou na sazbě?

Na základě sazeb nebo na základě "one-out, one-in"? Zvažujeme výhody a nevýhody.

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.



Nejlépe hodnocená virtuální čekárna na G2

Co říkají naši klienti o Queue-Fair


testování zátěže http požadavky kolik požadavků webový server hanle bez dalších serverových zdrojů

Kolik souběžných uživatelů zvládne webový server?

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

Jak přesný je systém front založený na rychlosti?

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.

operační systém maximální počet prostředků webového serveru
výpočet průměrné hodnoty pro souběžné uživatele s intervalem spolehlivosti

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 495505 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á!


servers capacity can be exceeced with inaccurate queues 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.

Snadný způsob výpočtu rychlosti fronty

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ů.

výpočet maximální úrovně aktivních uživatelů pro vaši webovou aplikaci.

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.

nejasnosti ohledně souběžných uživatelů souběžných připojení souběžných relací a průměrné délky relace

Mám tě #1: Souběžní uživatelé vs. souběžné požadavky vs. souběžná připojení vs. souběžné relace

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í.

Pokud to uděláte špatně, může to způsobit zhroucení vašeho webu!

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?

při určování počtu požadavků, které mohou vaše webové stránky obdržet, abyste zajistili dobrý zážitek pro každého uživatele, dbejte především na bezpečnost zdrojů vašeho serveru.

Převod souběžných požadavků na souběžné uživatele

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.

  1. Počet stránek v toku transakcí
  2. Průměrná doba transakce návštěvníka od první stránky po poslední stránku ve vašem toku.
  3. Kolik požadavků v průměru tvoří každou stránku
  4. Průměrná doba, za kterou váš server zpracuje jeden požadavek HTTP.

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:

Google zpracovává správně nakonfigurovaný nginx s Google Analytics pro nahrávání obrázků

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).

výpočet, kolik relací současně, kolik uživatelů a kolik požadavků za sekundu na vaši webovou aplikaci, ať už se jedná o jeden server nebo statický obsah.

Matematické výpočty

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ů.

Mám tě #2: Webové servery jsou se zátěží pomalejší

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.

čím větší je zátěž z nárazového provozu, tím pomalejší jsou stroje.

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.

nejisté, jak odhadnout kapacitu serverů serverových zdrojů pro každého jednotlivého uživatele.

Co mám tedy dělat?

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 provádět 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ě tím správným způsobem (zejména s ohledem na složitost cachování). 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 vaší rychlosti transakcí v běžnějším dni, podívejte se, jak to půjde chvíli po zahájení prodeje vstupenek, a pokud vše vypadá dobře, zatížení procesoru je nízké, databáze sql je v pořádku a (především) vaše stránky reagují na stisknutí CTRL-SHIFT-R, zdvojnásobte ji, 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 přinášející 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!

Mám tě #3: Příliš rychlé zvýšení sazby po otevření fronty

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.

zpomalit rozhodování o spotřebě prostředků serveru
servery se při překročení kapacity serverů aktivují.

Mám tě #4: Snapping vašich serverů

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ýší.

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.

Závěr

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á:

  1. Začněte s rychlostí fronty nastavenou na 10 nebo s rychlostí transakcí v běžnějším dni.
  2. Sledujte zatížení procesoru a další ukazatele výkonu.
  3. Počkejte, dokud se nové objednávky nebudou zaznamenávat do databáze sql stejnou nebo podobnou rychlostí jako rychlost fronty.
  4. Stisknutím kláves CTRL-SHIFT-R na stránkách zkontrolujte odezvu.
  5. Zvyšte rychlost fronty maximálně o 20 %.
  6. Vraťte se ke kroku 2 a znovu počkejte.
  7. Jakmile se velikost fronty snižuje nebo se každou minutu postupně zvyšuje méně rychle a zobrazená čekací doba je kratší než 50 minut, není třeba zrychlovat.
  8. Pohodlně se usaďte a relaxujte! Queue-Fair se o vás postará.

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?

Pamatujte, že je vždy lepší být v bezpečí, než litovat.


Stovky předních organizací důvěřují našim
řešením pro fronty

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

Jednoduché řešení nárůstu internetového provozu

Začněte