← Cloudflare Waiting Room / waiting-room

Časté dotazy

Níže najdete odpovědi na nejčastější otázky týkající se Waiting Room.

• Konfigurace
• Funkce a produkty
• User behavior
• Sledujte svou čekárnu

Ano. Podrobnosti najdete v Přizpůsobení čekárny.

Pokud máte přizpůsobili šablonu čekárny:

1. Před nasazením šablony do produkčního prostředí si zobrazte její náhled.
2. Pokud narazíte na potíže, zkontrolujte správnou syntaxi a uzavírací lomítko (/).

Můžete aktualizovat šablona čekárny a tyto změny budou uživatelům viditelné téměř v reálném čase. Tyto aktualizace doporučujeme jako způsob, jak s uživateli komunikovat a poskytovat jim aktuální informace nebo očekávání.

Můžete také aktualizovat nastavení konfigurace čekárny, ale tyto změny provádějte pouze v nezbytných případech. Mohou ovlivnit odhadovanou dobu čekání zobrazovanou koncovým uživatelům a způsobit zbytečné zmatky.

Přehled funkcí dostupných pro jednotlivé typy plánů najdete v Plány.

Některé produkty Cloudflare se na provoz uplatní ještě před tím, než na něj zareaguje waiting room:

• Zmírňování DDoS útoků
• Web Application Firewall (WAF)
• Bot Management
• Page Rules

Ostatní produkty Cloudflare se spouštějí až po tom, co čekárna zasáhne do provozu:

• Workers

Ruční obnovení karty prohlížeče nemá na pozici uživatele ve vaší čekárně žádný vliv.

Pokud však zavřou kartu prohlížeče a poté se během aktivního čekání pokusí znovu přistoupit k aplikaci, ztratí své místo a budou muset znovu na konec fronty.

Když se uživatel zařadí do fronty, je umístěn do skupiny (bucketu), která určuje jeho přibližnou pozici ve frontě. Když uživatel frontu opustí (zavře prohlížeč nebo kartu), jeho místo ve frontě zůstává vyhrazené po dobu pěti minut od posledního obnovení. Tato ochranná doba umožňuje uživatelům zachovat si pozici ve frontě i při krátkém výpadku připojení. Po pěti minutách ochranná doba vyprší a uživatel se již nepočítá jako čekající ve frontě.

Kvůli architektuře řešení se může stát, že jsou někteří uživatelé zařazeni do fronty ještě předtím, než waiting room dosáhne svého limitu. Podrobnosti o tomto chování a jeho řešení najdete v Aktivace řazení do fronty.

Pokud si všimnete, že uživatelé nejsou zařazováni do fronty vaší čekárny, ujistěte se, že vámi definovaná cesta přesně odpovídá cestě vašeho webu.

Cesta rozlišuje velká a malá písmena, takže pokud máte waiting room nastavený pro /Black-Friday-Sale a uživatelé přejdou na /black-friday-sale, obejdou vaši čekárnu.

Podrobnosti uvádí Osvědčené postupy.

Pokud používáte Rate Limiting, zkontrolujte své pravidla rate limitingu.

Stránka fronty Waiting Room se obnovuje každých 20 sekund pomocí naplnění hlavičky refresh. Pokud máte nastavené pravidlo, které blokuje požadavky z konkrétní IP adresy během 20 sekund, bude uživatel ve waiting roomu zablokován. Ujistěte se, že vaše pravidla povolují alespoň jeden požadavek každých 20 sekund.

Váš uživatel také nemusí mít soubory cookie povolené. Pokud cookies nepovolí a vaše čekárna aktivně řadí provoz do fronty, na váš koncový bod se nedostanou, dokud řazení do fronty neskončí.

Pokud se sníží rychlost, jakou uživatelé opouštějí váš web, odhadovaná doba čekání se může prodloužit. Tato doba se aktualizuje při každém obnovení stránky na základě nejnovějších dostupných informací o rychlosti uvolňování míst na vašem webu a o počtu uživatelů před daným uživatelem ve frontě. Abyste toto prodloužení omezili, můžete zkrátit dobu, po kterou mohou uživatelé na webu zůstat, tím, že vypnete obnovování relace. Mějte na paměti, že při změně nastavení provozu se odhadovaná doba čekání také změní.

new users per minute metrika sleduje, kolik uživatelů bylo za poslední minutu propuštěno na origin server. Zvyšuje se pouze tehdy, když uživatel ve frontě obnoví stránku a je propuštěn na origin server. Pokud je metoda řazení do fronty v čekárně nastavena na fifo, počkáme, dokud nebudou přijati všichni uživatelé zařazení do fronty v daném minutovém intervalu, než přejdeme k dalšímu intervalu. Pokud mnoho uživatelů v daném intervalu frontu opustí, musí čekárna počkat, dokud jejich místo ve frontě nevyprší, než přejde k dalšímu intervalu. To může způsobit new users per minute nízká, když ve frontě skutečně stále čeká jen malé procento uživatelů.

Toto si často všimnete, pokud dochází k velkému množství automatizovaného provozu, který nesprávně zpracovává soubory cookie. Jelikož si roboti obvykle neuchovávají soubory cookie mezi jednotlivými požadavky, jsou ve frontě počítáni jako více neaktivních uživatelů, což brání plnému využití dostupných míst. Z tohoto důvodu doporučujeme využít Bots Management produkty, abyste udrželi boty mimo frontu. Zákazníci s Waiting Room Advanced mohou vyzkoušet naši Turnstile integrace, která brání botům ucpat frontu tím, že je zařadí do nekonečné fronty.

Waiting Room počítá a sleduje aktivní uživatele pomocí session cookie. Doba, po kterou je uživatel považován za aktivního, závisí na konfiguraci čekárny. Klíčovým nastavením pro tento výpočet je doba trvání relace. Ve výchozím nastavení Waiting Room považuje uživatele za aktivního od okamžiku jeho posledního požadavku odeslaného se session cookie až do vypršení nastavené doby trvání relace. Zákazníci s pokročilým nastavením Waiting Room mohou toto chování upravit vypnutí obnovování relace a/nebo explicitně odvolávání relací pomocí příkazu origin serveru.

Pokud je doba trvání relace nastavena na vyšší hodnotu, uživatel, který provede pouze jeden požadavek, bude považován za aktivního déle, než ve skutečnosti byl. To může způsobit Total Active Users metrika je vyšší než metrika aktivních uživatelů hlášená nástrojem Google Analytics za stejné období, protože Google Analytics počítá pouze uživatele, kteří v daném období odeslali požadavek.

Pokud je například doba trvání relace nastavena na 30 minut a v Google Analytics se podíváte na posledních 10 minut aktivních uživatelů, počet aktivních uživatelů hlášený nástrojem Waiting Room bude vyšší, protože zahrnuje uživatele za posledních 30 minut.

Další zásadní rozdíl spočívá v tom, že Waiting Room pracuje s požadavky odeslanými na origin server, zatímco Google Analytics vyžaduje, aby user-agent spustil JavaScript (prostřednictvím Google Tag). Waiting Room vytváří nové relace a sleduje metriky uživatelů na základě cesty HTTP požadavku, aniž by user-agent musel spouštět další JavaScript. Google Analytics naproti tomu vyžaduje, aby user-agent spustil JavaScript a odeslal druhý požadavek s podrobnostmi Google Analytics. Pokud je velká část provozu automatizovaná, nemusí ji Google Analytics zaznamenat vůbec. Analytika Waiting Room však takový provoz započítá jako nové uživatele a po dobu nastavené relace je bude považovat za aktivní.

Waiting Room je distribuovaný systém, a proto je dosažení dokonale přesného globálního počítání v reálném čase náročné kvůli času potřebnému k šíření stavu mezi datovými centry po celém světě. Logika rozpočtování je založena jak na rozpočtech specifických pro jednotlivá datová centra, tak na globálních rozpočtech. Rozpočty jednotlivých datových center se přidělují na základě historického provozu, který dané datové centrum zaznamenalo, zatímco globální rozpočty (část z celkového dostupného rozpočtu) slouží k tomu, aby noví uživatelé mohli vstupovat z libovolného datového centra na světě.

V případě prudkého nárůstu, kdy počet uživatelů vzroste na několik tisíc během jedné minuty, trvá proces globálního šíření stavu přibližně dvě minuty, což vede ke zpoždění, než se o nárůstu dozvědí všechna datacentra. Pokud se tato informace nerozšíří do ostatních lokalit dostatečně rychle, může dojít k dočasnému překročení limitu, zejména při nastavení nižších limitů.

K tomu dochází proto, že část rozpočtu vyhrazená pro vstup nových uživatelů do datacentra je rovnoměrně dostupná všem datacentrům. Dokud není využití tohoto rozpočtu synchronizováno napříč všemi datacentry, může každé datacentrum spotřebovat část, která dohromady přesáhne 100% celkového rozpočtu vyhrazeného pro nové uživatele.