Ako používanie našej online fronty zabraňuje zrúteniu webu a pádu webovej stránky - koľko súbežných používateľov zvládne webový server?

Prečo používať virtuálnu čakáreň na základe sadzby?

Na základe sadzieb alebo jeden výstup, jeden vstup? Zvažujeme výhody a nevýhody.

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.



Najlepšie hodnotená virtuálna čakáreň na G2

Čo hovoria naši klienti o Queue-Fair


testovanie záťaže http požiadavky koľko požiadaviek webový server hanle bez ďalších zdrojov servera

Koľko súbežných používateľov zvládne webový server?

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

Ako presný je systém frontu založený na rýchlosti?

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.

operačný systém maximálny počet zdrojov webového servera
výpočet priemernej hodnoty pre súbežných používateľov s intervalom spoľahlivosti

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


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

Jednoduchý spôsob výpočtu rýchlosti frontu

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

výpočet maximálnej úrovne aktívnych používateľov pre vašu webovú aplikáciu

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.

nejasnosti týkajúce sa súbežných používateľov súbežných pripojení súbežných relácií a priemerného trvania relácie

Mám ťa #1: Súbežní používatelia vs. Súbežné požiadavky vs. Súbežné pripojenia vs. Súbežné relácie

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.

Ak to urobíte nesprávne, môže to spôsobiť haváriu vašej webovej stránky!

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ť?

bezpečnosť najprv pre zdroje vášho servera, keď zisťujete, koľko požiadaviek môžu vaše webové stránky dostať, aby ste zabezpečili dobrý zážitok pre každého používateľa.

Prevod súbežných požiadaviek na súbežných používateľov

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ť

  1. Počet stránok v toku transakcií
  2. Priemerný čas transakcie návštevníka od prvej stránky po poslednú stránku vo vašom toku
  3. Koľko požiadaviek v priemere tvorí každú stránku
  4. Priemerný čas, ktorý váš server potrebuje na spracovanie jednej požiadavky HTTP

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:

Google spracováva správne nakonfigurovaný nginx s google analytics pre nahrávanie obrázkov

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

počítanie, koľko relácií súčasne, koľko používateľov a koľko požiadaviek za sekundu na vašu webovú aplikáciu, či už ide o jeden server alebo statický obsah.

Počítanie

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

Mám ťa #2: Webové servery sú so zaťažením pomalšie

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

čím väčšie je zaťaženie z dopravných nárazov, tým pomalšie sú počítače.

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

neisté, ako odhadnúť kapacitu serverov serverových zdrojov pre každého používateľa

Čo mám teda robiť?

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é presne napodobniť správanie každého jedného používateľa (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ň, pozrite sa, ako to pôjde chvíľu po spustení predaja lístkov, 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, zdvojnásobte ju, 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 poskytujú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ú!

Mám ťa #3: Príliš rýchle zvýšenie rýchlosti po otvorení frontu

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 .

spomaliť rozhodnutie o spotrebe zdrojov servera.
servery sa pri prekročení kapacity serverov spínajú.

Mám ťa #4: Prichytenie vašich serverov

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

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

Záver

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

  1. Začnite s nastavením rýchlosti fronty na 10 alebo s rýchlosťou transakcií v bežný deň.
  2. Sledujte zaťaženie procesora a ďalšie ukazovatele výkonu.
  3. Počkajte, kým sa do databázy sql nezaznamenajú nové objednávky rovnakou alebo podobnou rýchlosťou ako rýchlosť fronty.
  4. Stlačením klávesovej skratky CTRL-SHIFT-R na svojich stránkach skontrolujte odozvu.
  5. Zvýšte rýchlosť fronty najviac o 20 %.
  6. Vráťte sa ku kroku 2 a znova počkajte.
  7. Keď sa veľkosť frontu znižuje alebo sa neustále zvyšuje menej rýchlo každú minútu a zobrazený čas čakania je kratší ako 50 minút, nie je potrebné ho zrýchľovať.
  8. Pohodlne sa usaďte a relaxujte! Queue-Fair sa o vás postará.

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?

Pamätajte, že je vždy lepšie byť v bezpečí, ako ľutovať.


Stovky popredných organizácií dôverujú našim
riešeniam fronty

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

Jednoduché riešenie nárastu internetovej prevádzky

Začnite