V skutočnosti sme nenašli žiadne klady hry one-out, one-in. V skratke, problém tohto prístupu spočíva v tom, že ak sú používatelia návštevníkmi webových stránok elektronického obchodu, webový server nevie, koľko má v danom okamihu súbežných používateľov. Je to prekážka. Tu je dôvod.
Ďalej v tomto článku vám tiež povieme, ako používať virtuálnu miestnosť založenú na sadzbe aj na ochranu vašej stránky.
Tradične sa servery elektronického obchodu zabezpečujú tak, aby podporovali maximálny počet súbežných používateľov, a často sa takto definuje zaťaženie. Pri použití tohto prístupu na spustenie fronty pre webové stránky je problém - problém, ktorý riešime pomocou sadzieb.
Problém vzniká preto, že návštevníci v skutočnosti používajú webový server len počas načítavania jednotlivých webových stránok v ich prehliadači.
Povedzme napríklad, že stránka elektronického obchodu predáva vstupenky. Od začiatku cesty návštevníka po koniec cesty návštevníka (relácie používateľa) existuje šesť stránok, pretože návštevník
Celý proces transakcie trvá v priemere päť minút.
Povedzme, že každú minútu príde napríklad 100 návštevníkov, ktorí si chcú kúpiť vstupenky, a priemerný čas potrebný na dokončenie procesu je päť minút. V danom okamihu je v procese transakcie súčasne 500 ľudí a server musí byť zabezpečený tak, aby podporoval 500 súbežných používateľov.
Mohli by sme si myslieť, že by sme mohli vytvoriť počítadlo súbežných používateľov, ktoré by sa inkrementovalo vždy, keď na domovskú stránku príde nový návštevník, a dekrementovalo by sa vždy, keď návštevník dokončí transakciu, a že by sme tak zistili, koľko používateľov v danom okamihu spracúva jeden server, ale to nebude fungovať.
Nebude to fungovať, pretože nie každý návštevník dokončí transakciu. Ľudia si to rozmyslia, rozptýlia sa alebo odídu a vrátia sa neskôr. Keďže webový server komunikuje s návštevníkmi len vtedy, keď ich prehliadače načítavajú stránky, webový server nemá možnosť zistiť, kedy sa to stalo a komu.
Namiesto toho, aby sa určilo, že návštevník už nie je súčasťou procesu transakcie, musí jediný server počkať, či od tohto návštevníka neprídu ďalšie požiadavky na stránku, a potom ukončiť reláciu tohto návštevníka. Časový limit musí byť vždy nastavený na oveľa dlhší čas, ako je priemerný čas transakcie (v tomto príklade napríklad 20 minút), pretože niektorým návštevníkom trvá dokončenie transakcie oveľa dlhšie ako iným.
Mohli by sme pridať možnosť znížiť aj fiktívny počítadlo súčasných používateľov zakaždým, keď relácia návštevníka skončí, ale to by prinieslo veľmi zlé výsledky.
Ak 10 % zo 100 návštevníkov, ktorí prídu každú minútu, nedokončí transakciu, tí, ktorí ju dokončia, budú aktívni v priemere päť minút a tí, ktorí ju nedokončia, budú považovaní za aktívnych vždy aspoň 20 minút (v skutočnosti je pravdepodobnejšie, že časový limit relácie plus priemerná dĺžka trvania relácie je pri zohľadnení viacerých relácií).
To je 90 * 5 + 10 * 20 = 650 a server bude hlásiť 650 súbežných používateľov, aj keď je v skutočnosti menej vyťažený!
Okrem toho až 10 * 20 = 200 z týchto súbežných používateľov v skutočnosti nepoužíva stránku a je v procese časovania, čo je viac ako 30 % nahlásených súbežných používateľov, hoci je to len 10 % návštevníkov, ktorí nedokončia transakciu.
Teraz povedzme, že si niekto želá pridať na túto webovú lokalitu frontu riadenú naším počítadlom súčasných používateľov. Keď je kapacita webu naplnená, potom osoba, ktorá je na čele fronty, bude na web prepustená až po znížení hodnoty počítadla. Tento postup sa nazýva fronta jeden-od-jeden-v. Stane sa to, že 30 % času bude osoba na čele frontu čakať, kým niekto, kto sa nechystá dokončiť svoju transakciu, dokončí nedokončenie svojej transakcie.
S vytvorením a spustením počítadla a zdieľaním týchto informácií so systémom fronty súvisí aj ďalšia technická integrácia a zaťaženie webovej stránky. Ak mechanizmus zdieľania alebo počítania vypadne alebo sa pokazí, fronta sa zasekne. A čo je ešte horšie, ak je jediný server natoľko zaneprázdnený, že nedokáže aktualizovať server fronty, aby oznámil serveru fronty, že má pustiť ďalšiu osobu, zasekne sa aj fronta.
Všetky tieto problémy sa dajú ľahko a jednoducho vyriešiť tak, že namiesto toho sa návštevníci z čela frontu posielajú konštantnou, pevnou rýchlosťou - v tomto prípade 100 návštevníkov za minútu.
Týmto spôsobom nie je potrebné merať skutočný počet súbežných používateľov, nie je potrebná zložitá integrácia s webovou stránkou na predaj vstupeniek a nehrozí, že by sa fronta zasekla.
Preto sme v roku 2004 vynašli a patentovali virtuálnu čakáreň pre vyťažené webové stránky založenú na sadzbách.
Úžasný a jednoduchý produkt! Queue-Fair je naozaj krásny. Tak ľahko sa nastavujú parametre v reálnom čase a je tiež tak jednoduché ho integrovať. Podpora je reaktívna a priateľská. Virtuálnu čakáreň som nastavil za 15 minút vrátane nastavení! S Queue-Fair tak chránim svoju infraštruktúru pred všetkými tými špičkami prevádzky.
Váš softvér znamenal, že všetci boli zaradení do fronty mimo nášho servera a umožnil jemný tok kupujúcich cez systém. Bolo to skvelé! Pre každý internetový obchod, ktorý má nával zákazníkov, by to bolo naozaj užitočné. Ďakujeme miliónkrát a pokračujte v dobrej práci!
Brilantné! Sme veľmi šťastní a spokojní s Queue-Fair, je úžasné mať takúto úroveň podpory. Služba funguje perfektne - predali sme tisíce vstupeniek za krátky čas a Queue-Fair nám pomohla zvládnuť návštevnosť počas špičiek! Odporúčame Queue-Fair aj našim partnerom v oblasti služieb. Som naozaj spokojný!
Ľudia zo spoločnosti Queue-Fair nám pomohli implementovať ich systém radenia v priebehu jedného dňa . S viac ako 25 000 ľuďmi v rade nám pomohli riadiť prevádzku počas našich špičiek. Queue-Fair robí to, na čo je určený: radí ľudí do frontu za konkurencieschopnú cenu. So systémom Queue-Fair sme spokojní a budeme ho používať aj počas budúcich podujatí.
Queue-Fair bol presne to, čo sme potrebovali na riadenie prevádzky a podporné služby sú skvelé!. Systém funguje veľmi dobre! Hľadali sme niekoľko spoločností a bezpochyby sme našli to najlepšie! Veľmi vám ďakujeme, Queue-Fair!
Veľké ďakujem za to, že ste tak rýchlo otočili našu požiadavku. V stredu o 21:00 sme dostali e-mail a vo štvrtok o 11:00 sme dostali plne označenú stránku fronty pripravenú na použitie. Jednoducho skvelé! Ovládací panel a funkcie sú skvelé - naozaj intuitívne, naozaj prehľadné a jednoduché na používanie. Na našu udalosť uvedenia produktu na trh sme zaradili do fronty viac ako 22 000 ľudí za cenu, ktorá bola mimoriadne konkurencieschopná. Za všetko veľmi pekne ďakujeme! Som naozaj rád, že môžem dať spoločnosti Queue-Fair žiarivé svedectvo a odporúčam ju všetkým podnikom, ktoré potrebujú systém fronty na svoju udalosť alebo propagáciu.
Ak viete, koľko súbežných používateľov webový server spracúva, a priemerný čas transakcie alebo trvania návštevy od prvej stránky v toku transakcií po stránku s potvrdením objednávky, môžete to previesť na rýchlosť fronty pomocou Littleovho zákona vydelením počtu používateľov dĺžkou trvania, takto:
Rýchlosť fronty = počet súbežných používateľov / čas transakcie
Queue-Fair bude doručovať návštevníkov na vaše webové stránky rýchlosťou, ktorú určíte - máme zďaleka najpresnejšiu umelú inteligenciu fronty v tejto oblasti, ktorá zabezpečuje, že počet návštevníkov, ktorý chcete každú minútu, je počet návštevníkov, ktorý dostanete každú minútu, pričom sa automaticky zohľadňujú ľudia, ktorí nie sú prítomní, keď na nich príde rad, ako aj ľudia, ktorí sa vrátia neskôr.
Ako sa to premietne do počtu súbežných používateľov? Samozrejme, nie každý návštevník, ktorý sa dostane na vašu stránku, potrebuje na dokončenie svojej transakcie presne priemerný čas, ale vďaka zákonu veľkých čísel získate veľmi stabilný počet súbežných používateľov s Queue-Fair.
Povedzme napríklad, že máte rýchlosť fronty 100 návštevníkov za minútu. Každú minútu pošleme na vašu stránku 100 návštevníkov v stabilnom prúde - to je to, čo robíme, a sme v tom úžasne dobrí. Povedzme tiež, že ľudia používajú vašu webovú stránku v priemere (priemerne) päť minút, pričom 70 % z nich trvá od okamihu, keď prejdú frontom, do okamihu, keď vykonajú poslednú požiadavku na stránku (bez ohľadu na to, či dokončia transakciu alebo nie), 4 až 6 minút. To predstavuje štandardnú odchýlku jednej minúty na každej strane priemeru. Štatisticky to znamená, že na každého návštevníka, ktorému to trvá päť a pol minúty, pripadne iný, ktorému to trvá štyri a pol minúty, a tieto rozdiely v trvaní jednotlivých návštev v rámci viacerých relácií majú preto tendenciu sa navzájom vyrušiť, ak ich počítate veľa akýmkoľvek spôsobom. Zákon veľkých čísel hovorí, že toto rušenie je tým presnejšie, čím väčší je počet zúčastnených osôb.
Ako presne? Môžeme to zistiť pomocou malej štatistiky. Veľkosť vzorky je 5 * 100 = 500, čo je veľké číslo. Toľko ľudí počítate. To znamená, že štandardná chyba priemeru pre čas transakcie je 1 (štandardná odchýlka, 1 minúta) vydelená druhou odmocninou veľkosti vzorky (teda druhou odmocninou z 500) podľa štatistického vzorca pre štandardnú chybu priemeru, čo dáva štandardnú chybu priemeru pre čas transakcie 0,044 minúty alebo len 2,7 sekundy, čo je menej ako jedno percento.
To znamená, že pri rýchlosti frontu 100 a čase transakcie 5 minút plus mínus minúta pre každého jednotlivého návštevníka by ste mali očakávať 495 až 505 súbežných používateľov na vašom webe približne 70 % času, takže matematika hovorí, že použitie frontu založeného na rýchlosti zabezpečí veľmi stabilné zaťaženie vašich webových serverov podľa potreby.
Je však matematika presná? Sú tu isté jemnosti - napríklad veľkosť vzorky, ktorú veselo odmocňujeme, nie je vždy presne 500 pri každom počítaní súbežných používateľov (t. j. v danom časovom okamihu) a tiež normálne (Gaussovo) rozdelenie môže dať záporné časy transakcií, ktoré sa v reálnom živote nevyskytujú. Preto používame simulátor návštevník po návštevníkovi, sekundu po sekunde, aby sme vykonali merania na kontrolu týchto druhov výpočtov, a ten nám hovorí, že s uvedenými číslami by ste mali očakávať 493 až 507 návštevníkov v 70 % prípadov, takže matematika drží pozoruhodne dobre! Meranie údajov nám tiež hovorí, že vaša stránka bude mať 500 ± 15 súbežných používateľov najmenej 95 % času.
To je pravdepodobne stabilnejšie ako presnosť, s akou váš webový server dokáže zmerať počet ľudí používajúcich vašu stránku! A čo je ešte lepšie, naozaj šikovné je, že aj keď nemáte predstavu o tom, aký je priemerný čas transakcie alebo štandardná odchýlka vašich návštevníkov, tieto matematické veličiny existujú bez ohľadu na to, či ich poznáte alebo nie, a aj tak získate stabilné zaťaženie.
Výsledkom je, že Queue-Fair vám s takmer dokonalou presnosťou zabezpečí požadovaný počet návštevníkov za minútu, čo má za následok veľmi stabilný počet súbežných používateľov na vašej stránke a stabilné zaťaženie webového servera, nad ktorým máte úplnú kontrolu.
Hurá!
A teraz varovanie. Je potrebné poznamenať, že stabilita počtu súbežných používateľov na vašej stránke - a teda stabilita zaťaženia vášho servera - závisí v rozhodujúcej miere od toho, ako presne vám poskytovateľ virtuálnej čakárne posiela počet návštevníkov, ktorý chcete každú minútu, a preto je to kľúčový faktor pri výbere platformy virtuálnej čakárne. Keďže poskytujeme najpresnejšiu Virtuálnu čakáreň na svete, nikto nezastaví zaplavovanie vašich serverov lepšie ako spoločnosť Queue-Fair.
Čo ak neviete, koľko súbežných používateľov server zvládne, alebo čas transakcie? Môžete sa pozrieť na stránku, ktorá bude pravdepodobne vaším úzkym miestom - zvyčajne tá, ktorá je výsledkom kliknutia na tlačidlo "Kúpiť teraz". Pomocou služby Google Analytics zistite mesačný počet jedinečných návštevníkov tejto stránky alebo spočítajte mesačné objednávky. Vydelte to 30 * 24 * 60 = 43 200, čo je počet minút za mesiac (približne). To je váš priemerný počet návštevníkov za minútu počas celého mesiaca. Vynásobte to tromi. To je váš priemerný počet návštevníkov za minútu počas pracovnej doby (približne). Zdvojnásobte túto hodnotu. To je pravdepodobne bezpečný údaj, ktorý sa má použiť pri hodnote Queue Rate.
Povedzme napríklad, že spracujete 100 000 objednávok mesačne - to je 100 000 kliknutí na tlačidlo "Kúpiť teraz". To je 100 000 / 43 200 = 2,31 objednávky za minútu. Očakávate, že väčšina týchto objednávok bude počas dňa a vaše servery budú v noci tichšie, takže to vynásobte 3 a dostanete 7 objednávok za minútu ako hrubý odhad toho, ako je váš server počas pracovných hodín vyťažený. Ak je výsledné číslo menšie ako 50: v dopyte budú špičky a poklesy, takže ak váš server nie je v špičke výrazne pomalý, vynásobte ho 2 a dostanete 14 aktívnych používateľov za minútu. Ak je toto číslo väčšie ako 50: minútové špičky a poklesy budú v porovnaní s tým menšie a nie je bezpečné toto číslo zdvojnásobiť. Číslo, ktoré vám nakoniec vyjde, je pravdepodobne bezpečný údaj pre rýchlosť fronty na začiatok a zodpovedá tomu, koľko požiadaviek za sekundu môžete bezpečne zvládnuť; vždy ho môžete zvýšiť, ak zistíte, že vaše systémy pri tejto rýchlosti stále reagujú na výkon koncových používateľov.
Ak sú vaše objednávky označené časovou pečiatkou, môžete sa pozrieť aj na maximálny počet objednávok, ktoré ste prijali za jednu minútu v poslednom mesiaci - používajte však s opatrnosťou, pretože nebudete vedieť, koľko objednávok ste mohli počas tejto minúty vyradiť z dôvodu spomalenia vašich serverov, preto túto hodnotu znížte o 20 %.
V ďalšej časti tohto článku sú opísané ďalšie spôsoby, ako zistiť rýchlosť fronty.
Stojí za to upozorniť, že v bežnom používaní existujú minimálne dve definície pojmu "súbežní používatelia".
Používame definíciu "počet ľudí zapojených do transakčného toku v každom okamihu". To je kľúčové číslo, ktoré potrebujete poznať na nastavenie rýchlosti fronty. To je počet používateľov, ktorí si práve prezerajú vašu stránku. Počet súbežných relácií je zvyčajne o niečo väčší ako počet súbežných pripojení alebo súbežných používateľov, pretože niektoré relácie sú v procese časovania, čím sa zvyšuje priemerné trvanie relácie.
Porovnajte to s počtom súbežných požiadaviek, čo je počet požiadaviek HTTP spracúvaných webovým serverom v jednom okamihu. Je veľmi mätúce, že mnohí technici majú na mysli koľko súbežných požiadaviek, keď hovoria koľko súbežných používateľov.
Potom sú tu súbežné spojenia (alebo súbežné spojenia TCP na ten istý port servera na karte sieťového rozhrania), čo je počet soketov TCP/IP otvorených na porte vášho servera alebo backendovej služby v každom okamihu. Pri požiadavkách na stránku ponechávajú prehliadače v predvolenom nastavení pripojenie otvorené pre prípad, že by stránka vykonala ďalšie požiadavky alebo by používateľ prešiel na inú stránku. Tým sa znižuje počet požiadaviek na otvorenie nových spojení TCP/IP za sekundu, čím sa proces servera stáva efektívnejším. Časové limity pre tieto súbežné spojenia sa líšia v závislosti od prehliadača, od 60 sekúnd až po nikdy neuzavreté spojenie. Váš server môže po určitom čase bez aktivity tiež automaticky ukončiť spojenia. Na linuxových webových serveroch môžete získať počet súbežných spojení na rovnaký port servera pomocou tohto príkazu: netstat -aenp | grep ":80 \|:443 " | wc -l
ktoré môžete vyskúšať, ak ste zvedaví. Niektorí ľudia to nazývajú aj "súbežní používatelia", hoci v skutočnosti ide o súbežné pripojenia.
Ak totiž požiadate poskytovateľa hostingu, aby vám povedal maximálny počet súbežných používateľov, ktorý váš webový server spracúva (koľko je špičková prevádzka), pravdepodobne vám v skutočnosti poskytne údaj o súbežných reláciách, súbežných požiadavkách alebo súbežných pripojeniach, a to z jednoduchého dôvodu, že nepozná váš priemerný čas transakcie, počet stránok v toku transakcií ani žiadne iné informácie, ktoré by mu umožnili povedať, koľko používateľov súčasne spracúva váš webový server. Všetky tieto čísla majú rôzne hodnoty.
Ak žiadate svojho poskytovateľa hostingu alebo technický tím o informácie o maximálnej úrovni prevádzky, je mimoriadne dôležité, aby ste si ujasnili, či majú na mysli súbežných používateľov, súbežné relácie, súbežné požiadavky alebo súbežné pripojenia.
Tu je dôvod. Každá stránka je jedna požiadavka HTTP, ale všetky obrázky, skripty a iné súbory, ktoré pochádzajú z vašej webovej aplikácie a ktoré prehliadač používa na zobrazenie stránky, sú tiež požiadavky HTTP.
Predstavme si, že vám technický tím povedal, že server podporuje 500 súbežných používateľov, ale v skutočnosti myslel 500 súbežných požiadaviek. Pri 5-minútovom čase transakcie použijete vyššie uvedený vzorec a predpokladáte, že vaša stránka môže podporovať 100 návštevníkov za minútu.
Môže? Nie.
Keď ľudia prechádzajú transakčným tokom, počas načítavania každej stránky v skutočnosti len odosielajú požiadavky z vašich serverov. To má vplyv na to, koľko prevádzky za sekundu alebo aktívnych používateľov dokáže váš server spracovať. Z päťminútového času transakcie je to pre priemerného používateľa len niekoľko sekúnd. Možno si preto myslíte, že 500 súbežných požiadaviek znamená, že zvládnete oveľa viac súbežných používateľov, ale môžete sa mýliť. Už chápete, ako je pochopenie kapacity vašej webovej lokality z hľadiska toho, aká je návštevnosť alebo celkový počet aktívnych používateľov, taká komplikovaná záležitosť?
Ak chcete zistiť maximálny počet súbežných používateľov z maximálneho celkového počtu súbežných požiadaviek, musíte tiež vedieť
Pravdepodobne už poznáte body 1) a 2) - v našom príklade je to 6 strán a 5 minút. Stránky, ktoré sa vám zobrazia pri vykonávaní transakcie, si môžete ľahko spočítať. Ak nepoznáte priemerný čas transakcie, môže vám to povedať služba Google Analytics alebo môžete skontrolovať protokoly webového servera.
V prípade bodov 3) a 4) vám môže pomôcť prehliadač Firefox. Kliknite pravým tlačidlom myši na stránku na vašom webe, vyberte položku Inšpektovať prvok a kartu Sieť. Potom stlačte CTRL-SHIFT-R, čím stránku úplne obnovíte. V zozname uvidíte časy načítania siete pre každý prvok stránky. Chcete sa uistiť, že v stĺpci Prenesené vidíte veľkosti prenosu, pretože v opačnom prípade by sa súbory mohli obsluhovať z vyrovnávacej pamäte, čo by mohlo narušiť vaše výpočty. Možno uvidíte, že niektoré skripty a iné zdroje pochádzajú z iných serverov ako z vašej stránky, preto môžete do poľa filtra na ľavej strane zadať názov domény vašej stránky. Ak chcete zobraziť stĺpec Trvanie, kliknite pravým tlačidlom myši na záhlavie ľubovoľného stĺpca a z kontextového menu vyberte položku Čas -> Trvanie. Vaša obrazovka by mala vyzerať takto:
Sieťová karta Firefoxu pre túto stránku, zobrazujúca trvanie a počet požiadaviek z queue-fair.com
Súbory použité pri zobrazovaní vašich stránok môžu pochádzať z viacerých rôznych lokalít, preto chcete použiť aj filter v ľavom hornom rohu, aby sa zobrazovali len súbory z vašej lokality - ale len vtedy, ak ste si istí, že tieto súbory z iných lokalít nie sú príčinou pomalého načítavania stránok alebo súčasťou úzkych miest.
Firefox pre vás počíta požiadavky v ľavej dolnej časti displeja a zobrazuje 36 požiadaviek HTTP lenpre túto jednu stránku.
Musíte to urobiť pre každú stránku v toku transakcií - spočítajte celkový počet a vydeľte ho počtom stránok, aby ste zistili priemerný počet požiadaviek HTTP pre každú stránku, číslo 3) v našom zozname. Teraz vidíte, prečo je počet detských požiadaviek pre každú stránku HTML takým kľúčovým faktorom pre to, akú veľkú prevádzku dokáže váš webový server zvládnuť.
V prípade čísla 4) sa musíte pozrieť na stĺpec Trvanie a zistiť priemer všetkých požiadaviek HTTP pre všetky vaše stránky. Ak si nie ste istí, predpokladajte pol sekundy - aj tak je v tom veľa neistoty (pozri nižšie).
Uveďme niekoľko príkladov. Už sme povedali, že v príklade toku procesov servera je šesť dynamických stránok, čo je 1), a že priemerný čas transakcie je päť minút, čo je 2). Predpokladajme 36 požiadaviek HTTP na stránku pre 3) a pol sekundy pre čas spracovania každej požiadavky HTTP serverom, čo je 4).
Pri týchto číslach môže server, ktorý dokáže spracovať 500 súbežných požiadaviek, spracovať 500 / (0,5 sekundy) = 1000 požiadaviek HTTP za sekundu, čo je 60 000 požiadaviek HTTP za minútu, keď je úplne vyťažený.
Počas piatich minút transakcie dokáže spracovať 5 * 60 000 = 300 000 požiadaviek HTTP. Zdá sa to veľa, však?
Na každého návštevníka však pripadá šesť stránok s priemerom 36 požiadaviek HTTP na každú z nich, takže to je 6 * 36 = 216 požiadaviek.
Takže kapacita 300 000 požiadaviek HTTP teoreticky zvládne 300 000 / 216 = 1 389 súbežných používateľov
Hej, to je skvelé! Mysleli sme si, že môžeme mať rýchlosť fronty len 100, ale 1 389 / 5 minút = 278 návštevníkov za minútu, takže môžeme mať vyššiu rýchlosť fronty!
Pravdepodobne nie. Po prvé, vaši návštevníci nebudú posielať požiadavky presne v polsekundových intervaloch, ako predpokladá vyššie uvedený výpočet. Čo je však dôležitejšie, vstupné údaje budete merať v čase, keď stránka nie je vyťažená. Garbage in, garbage out.
Keď je stránka zaneprázdnená, serveru trvá dlhšie, kým spracuje požiadavky - určite ste si to všimli aj na iných stránkach, keď je veľa práce a na stránky čakáte dlhšie. Tým sa predlžuje priemerný čas, ktorý server potrebuje na spracovanie jednej požiadavky HTTP (4), čo znižuje maximálnu priepustnosť. Vezmite teda číslo 278 návštevníkov za minútu a znížte ho na polovicu. Potom ho opäť znížte na polovicu. Pravdepodobne sa reálne pozeráte na približne 70 nových návštevníkov za minútu pri maximálnom zaťažení.
Medzi ďalšie mätúce faktory patrí ukladanie do vyrovnávacej pamäte, čo znamená, že prehliadače vašich návštevníkov nemusia vykonať každú požiadavku na každú stránku - to znamená, že server potrebuje menej zdrojov a môže zvýšiť počet nových návštevníkov za minútu, ktoré dokáže server spracovať. Vyvažovače záťaže, ktoré rozdeľujú záťaž medzi niekoľko serverov, a servírovanie statického obsahu namiesto dynamických stránok môžu tiež urýchliť proces vášho servera, pretože každý server potrebuje menej zdrojov.
Zistíte tiež, že nie všetky stránky zaberú rovnaký čas, pretože na výrobu a obsluhu niektorých je potrebných menej zdrojov ako na iné. Vyhľadávanie v databáze, vyhľadávacie dotazy a aktualizácie trvajú najdlhšie, takže niekde v procese budete mať úzke miesto, kde sa budú hromadiť ľudia čakajúci na spracovanie údajov kreditnej karty a uloženie objednávok alebo čakajúci na overenie dostupnosti. Každý tok transakcií má najpomalší krok, takže vždy niekde existuje úzke miesto a vždy existuje odpoveď na otázku, koľko súbežných používateľov dokáže webový server zvládnuť - a môže ísť o niekoľko limitov. V takom prípade chcete nastaviť rýchlosť fronty dostatočne nízko, aby ste zabezpečili, že váš server má kapacitu procesorového času na súbežné spracovanie dostatočného počtu ľudí pre najpomalší krok v procese, aby sa tam ľudia nehromadili. Inak sa váš webový server môže doslova zastaviť.
Podľa našich skúseností pri prvom predaji každý preceňuje schopnosť svojich serverov zvládnuť veľký objem prevádzky.
Všetci.
Presné určenie priemerného trvania relácie a výkonu koncového používateľa počas pomalej alebo špičkovej prevádzky nie je pre slabé povahy. Najlepšie je spustiť riadny test záťaže, pričom "falošní" zákazníci budú počas testovania záťaže skutočne prechádzať procesom objednávania presne tak, ako by to robili v reálnom živote, pričom budú zadávať rovnaké požiadavky HTTP v rovnakom poradí, s rovnakým čakaním medzi stránkami pri testovaní záťaže ako v reálnom živote, a sledovať zaťaženie procesora, priepustnosť IO a časy odozvy pri zvyšovaní počtu virtuálnych návštevníkov. Môžete na to použiť Apache JMeter (my máme radi aj K6 pre menšie záťaže alebo pomalšie stroje), ale nech použijete akýkoľvek nástroj, je časovo náročné a zložité napodobniť správanie každého jedného používateľa presne správnym spôsobom (najmä pri zložitosti ukladania do vyrovnávacej pamäte). Aj v takom prípade vezmite svoje maximálne číslo a znížte ho na polovicu.
Ak to nie je možné, buďte opatrní.
Pomocou portálu Queue-Fair môžete kedykoľvek jednoducho zmeniť rýchlosť frontu pre ktorúkoľvek frontu Queue-Fair. Začnite na 10 návštevníkoch za minútu alebo na vašej rýchlosti transakcií v bežnejší deň, chvíľu po spustení predaja lístkov sledujte, ako to pôjde, a ak všetko vyzerá dobre, zaťaženie procesora je nízke, databáza sql je v poriadku a (predovšetkým) vaše stránky reagujú po stlačení CTRL-SHIFT-R, zvýšte ju maximálne o 20 percent, chvíľu počkajte a zopakujte. Počas tohto "vyrovnávania záťaže" (vidíte, čo sme urobili?) čoskoro zistíte skutočnú rýchlosť, ktorú potrebujete, a nezabudnite, že z hľadiska zákazníckej skúsenosti je v poriadku zvýšiť rýchlosť fronty, pretože to spôsobí skrátenie odhadovaného čakania, ktoré vidia vaši zákazníci vo fronte, a každý je rád, že vidí čas odozvy prinášajúci kratšie odhadované čakanie.
Chcete sa vyhnúť tomu, aby ste nastavili príliš vysokú rýchlosť fronty a potom ju museli znížiť, pretože to a) znamená, že ľudia, ktorí používajú stránku, majú pomalé načítavanie stránok, a b) spôsobuje zvýšenie odhadovaného čakania. Všetci ľudia vo vašej fronte si povzdychnú!
Nezabudnite, že niekde v procese objednávky bude úzke miesto - každá transakcia má najpomalší krok - a v ňom sa vám nahromadí viacero relácií. Nechcete, aby ste sa dostali do minúty predaja lístkov, videli, že zaťaženie procesora vášho servera je hlboko pod jeho maximálnym číslom, a zvýšili rýchlosť. Vaši návštevníci sa pravdepodobne nedostali až k tlačidlu "Kúpiť teraz". Chcete počkať, kým vaša databáza sql bude hlásiť nové objednávky rovnakou alebo podobnou rýchlosťou ako vaša rýchlosť fronty, a vtedy vykonať merania a testy odozvy. Nezabudnite, že pri každom zvýšení rýchlosti bude trvať rovnaký čas, kým sa dodatoční návštevníci dostanú k vášmu úzkemu miestu, takže nebudete môcť presne vyhodnotiť, ako váš server funguje pri novej rýchlosti, kým neuplynie tento čas .
Už sme hovorili o tom, že po otvorení fronty je najlepšie postupne zvyšovať rýchlosť fronty. Pravdepodobne viete, že vaše servery majú limit, ktorý nemožno prekročiť bez toho, aby sa systém zrútil, a možno dokonca viete, aký je to limit - ale možno neviete, že keď sa zaťaženie blíži k tomuto limitu, zvyčajne sa to veľmi neprejaví - často len niekoľkými chybami alebo varovaniami, prípadne zaťažením procesora nad 80 %.
Keď webové služby zlyhajú, majú tendenciu veľmi rýchlo "prasknúť" alebo sa zastaviť. Zvyčajne je to preto, že keď váš systém už nedokáže spracovávať požiadavky tak rýchlo, ako prichádzajú, vytvárajú sa interné fronty spracovania. Váš systém potom musí vykonávať prácu spojenú so spracovaním, správou a ukladaním svojich vnútorných frontov, ako aj požiadaviek, a to je to, čo servery vyradí z prevádzky. Veľmi rýchlo. Keď sa to stane, vaše servery môžu na určitý čas reagovať chybovou stránkou, ale to vám nepomôže, pretože návštevníci, ktorí ju uvidia, okamžite stlačia tlačidlo Obnoviť, čím sa záťaž ešte znásobí.
Ak návštevníkom trvá zobrazenie vašich stránok dlhšie ako jednu sekundu, stlačte tlačidlo Obnoviť. Keď návštevník stlačí tlačidlo Obnoviť, váš webový server nevie, že návštevník už nečaká na odpoveď na pôvodnú požiadavku. Ak je prijatá pôvodná požiadavka aj požiadavka na obnovenie, váš webový server spracuje obe. To znamená viac práce pre váš webový server, ešte pomalšie odpovede pre všetkých vašich návštevníkov a viac ľudí, ktorí stlačia tlačidlo refresh, čo vedie k začarovanému kruhu, ktorý váš webový server zastaví ešte predtým, ako začne odosielať chybové odpovede.
Netlačte preto na svoje servery viac, ako je potrebné. Snaha o získanie posledných 20 % kapacity procesora sa zvyčajne neoplatí riskovať. Ak sa veľkosť fronty zobrazená na portáli Queue-Fair (žltý obrázok a čiara Čakanie v grafoch) znižuje alebo dokonca len pomalšie zvyšuje, minútu po minúte, a zobrazená doba čakania je 50 minút alebo menej, potom spracovávate objednávky dostatočne rýchlo a fronta sa nakoniec vyprázdni a prestane zobrazovať Stránky fronty automaticky, bez toho, aby ste museli čokoľvek robiť, a bez toho, aby ste museli svojmu šéfovi povedať, že ste na ňu príliš tlačili a pokazili ju. Nakoniec sa vám to podarí, pokiaľ je rýchlosť fronty vyššia ako počet pripojení každú minútu (oboje sa zobrazuje na portáli Queue-Fair) - bod zlomu je zvyčajne aspoň niekoľko minút po každej udalosti. Ak predávate produkt s obmedzeným množstvom, pravdepodobne sa vypredá skôr, ako sa dosiahne bod zvratu.
Dobrou správou je, že ak náhodou nastavíte príliš vysokú rýchlosť fronty a vaše servery sa zaseknú, Queue-Fair vám pomôže rýchlo obnoviť prevádzku - stačí, ak frontu podržíte, kým vaše servery nebudú opäť pripravené prijímať návštevníkov. V režime podržania sa ľuďom vo fronte zobrazí špeciálna stránka podržania, ktorú môžete navrhnúť pred vašou online udalosťou. Keď je fronta v režime Podržania, nikto nie je prepustený z prednej časti fronty, ale noví internetoví návštevníci sa stále môžu pripojiť do fronty vzadu, aby boli spravodlivo zaradení do fronty po odstránení blokovania, čo sa stane veľmi rýchlo, pretože Queue-Fair chráni vašu stránku pred dopytom. Stránka Podržať je lepším používateľským zážitkom ako nastavenie rýchlosti fronty na naozaj nízku úroveň, najmä ak ju aktualizujete tak, aby ste návštevníkom povedali, v akom čase očakávate opätovné otvorenie fronty, čo sa dá ľahko urobiť pomocou editora stránky portálu, aj keď sú v rade už státisíce ľudí - a v režime Podržať ich dokonca môžete pustiť po jednom pomocou jedinečného tlačidla Queue-Fair Pripustiť jedného, ak potrebujete, kým sa váš systém spamätá z jeho záseku.
Ak teda zistíte, že vaše servery potrebujú počas podujatia prestávku, stránka Podržať je presne to, čo potrebujete, a navyše pomôže vašim serverom rýchlejšie sa zotaviť.
V tomto článku sme vysvetlili, prečo je fronta založená na rýchlosti vždy tou správnou cestou, a uviedli sme dve metódy na výpočet potrebnej rýchlosti, ale pokiaľ ste nevykonali úplné a presné virtuálne testovanie záťaže návštevníkov na celom toku transakcií a nie ste si tým naozaj extra mega istí, naša rada je vždy rovnaká:
Ak predávate výrobok v obmedzenom množstve, nemusíte venovať pozornosť ani kroku 7.
To platí pre prvú frontu, keď nepoznáte skutočnú maximálnu rýchlosť fronty, ktorú môže váš systém podporovať. Pri ďalších frontoch, keď zmeriate rýchlosť frontu, ktorú váš systém skutočne zvládne, môžete opäť použiť rovnaký údaj - ale len v prípade, že sa vo vašom systéme nič nezmenilo. V praxi sa váš systém pravdepodobne neustále vyvíja a upravuje a možno neviete, ako nedávne zmeny ovplyvnili maximálnu rýchlosť frontu - prečo teda nezačať od polovice predchádzajúceho nameraného čísla a nezopakovať vyššie uvedený postup?
Takto teda môžete použiť Queue-Fair, aby bol váš predaj pekný a bezpečný, a nezabudnite, že je vždy lepšie byť v bezpečí, ako ľutovať.
2024 The Fair Queue People Ltd. - Všetky práva vyhradené.
Súčasť rodiny riešení Orderly pre fronty - OrderlyQ - OrderlyStats - WeQ4U
