Hogyan akadályozza meg az online várólistánk használata a webhely és a weboldal összeomlását - hány egyidejű felhasználót tud kezelni egy webszerver?

Miért használjon tarifaalapú virtuális várótermet?

Árfolyam-alapú vagy one-out, one-in? Mérlegeljük az előnyöket és hátrányokat.

Valójában nem találtunk semmilyen előnyös tulajdonságot az egy ki, egy be játékhoz képest. Dióhéjban az a probléma ezzel a megközelítéssel, hogy amikor a felhasználók az e-kereskedelmi webhelyek látogatói, a webszerver nem tudja, hogy hány egyidejű felhasználója van egy adott pillanatban. Ez egy showstopper. Itt van, hogy miért.

A cikk későbbi részében azt is elmondjuk, hogyan használhatsz egy áralapú virtuális szobát a webhelyed védelmére is.



A legmagasabbra értékelt virtuális váróterem a G2-en

Ügyfeleink véleménye a Queue-Fair-ról


terhelés tesztelés http kérések hány kérés egy web szerver hanle nélkül extra szerver erőforrások

Hány egyidejű felhasználót tud kezelni egy webszerver?

Ha tudja, hogy hány egyidejű felhasználót kezel egy webszerver, valamint a tranzakció átlagos időtartamát vagy a látogatás időtartamát a tranzakciófolyam első oldalától a megrendelés megerősítő oldaláig, akkor ezt a Little-törvény segítségével átkonvertálhatja a várakozási arányra, ha a felhasználók számát elosztja az időtartammal, a következőképpen:

Sorbanállási ráta = Egyidejű felhasználók / tranzakciós idő

Mennyire pontos egy sebességalapú várólista-rendszer?

A Queue-Fair az Ön által megadott ütemben szállít látogatókat a weboldalára - messze a legpontosabb sorbanállási AI-val rendelkezünk, amely biztosítja, hogy a percenként kívánt látogatók száma az a látogatók száma, amelyet percenként kap, automatikusan figyelembe véve azokat az embereket, akik nincsenek jelen, amikor sorra kerülnek, valamint azokat, akik későn jönnek vissza.

Hogyan fejeződik ez ki az egyidejű felhasználók számában? Természetesen nem minden látogató, aki eléri az Ön webhelyét, fogja pontosan a tranzakció átlagos idejét igénybe venni a tranzakció befejezéséhez, de a nagy számok törvénye miatt a Queue-Fair-val nagyon állandó számú egyidejű felhasználót fog kapni.

Tegyük fel például, hogy a várakozási ráta 100 látogató percenként. Mi minden egyes percben 100 látogatót küldünk az oldalára, egyenletes folyamban - ez az, amit csinálunk, és elképesztően jók vagyunk benne. Tegyük fel azt is, hogy az emberek átlagosan (átlagosan) öt percig használják a webhelyét, és 70%-uknak 4-6 percig tart a várólistán való áthaladás és az utolsó oldalletöltés között (akár befejezik a tranzakciót, akár nem). Ez az átlagtól számított egy perc szórás az átlag mindkét oldalán. Statisztikailag ez azt jelenti, hogy minden egyes látogatóra, aki öt és fél percig tart, jut egy másik, aki négy és fél percig tart, és ezért az egyes látogatások időtartamának több munkamenet közötti eltérései általában kioltják egymást, ha sok látogatót számolunk bármilyen módon. A nagy számok törvénye azt mondja, hogy ez a kioltás egyre pontosabbá válik, minél nagyobb az érintettek száma.

az operációs rendszer maximális számú webkiszolgáló erőforrásainak száma
az átlagos érték kiszámítása az egyidejű felhasználókra vonatkozóan, konfidenciaintervallummal együtt

Pontosan mennyire pontosan? Ezt egy kis statisztikával ki tudjuk számolni. A minta mérete 5 * 100 = 500, ami itt a nagy szám. Ennyi embert számolunk. Ez azt jelenti, hogy a tranzakcióidő átlagos standard hibája 1 (a standard eltérés, 1 perc) osztva a minta méretének négyzetgyökével (tehát 500 négyzetgyökével) az átlagos standard hibára vonatkozó statisztikai képlet szerint, ami a tranzakcióidő átlagos standard hibáját 0,044 percnek, vagyis mindössze 2,7 másodpercnek adja, ami kevesebb, mint egy százalék.

Ez azt jelenti, hogy 100-as várakozási ráta és 5 perces tranzakciós idő mellett, plusz-mínusz egy perc minden egyes látogató esetében 495-505 egyidejű felhasználóra számíthat az idő 70%-ában, így a matematika szerint a ráta alapú várakozási sor használata a kívánt módon nagyon egyenletes terhelést biztosít a webszervereken.

De vajon a matematika pontos? Van itt néhány finomság - például a minta mérete, amelyet vidáman négyzetre gyökereztetünk, nem mindig pontosan 500 minden alkalommal, amikor az egyidejű felhasználókat számoljuk (azaz bármely adott időpontban), és a normál (Gauss) eloszlás negatív tranzakciós időket is adhat, amelyek a valóságban nem fordulnak elő. Ezért egy látogatóról látogatóra, másodpercről másodpercre történő szimulátorral méréseket végzünk az ilyen jellegű számítások ellenőrzésére, és ez azt mutatja, hogy a fenti számokkal az idő 70%-ában 493 és 507 közötti látogatóra kell számítani, tehát a matematika figyelemre méltóan jól áll! Az adatok mérése azt is elárulja, hogy az oldalának az idő legalább 95%-ában 500 ± 15 egyidejű felhasználója lesz.

Ez valószínűleg stabilabb, mint az a pontosság, amellyel a webszervered képes mérni az oldaladat használó emberek számát! Sőt, az igazán szép dolog itt az, hogy még ha fogalma sincs arról, hogy a látogatók átlagos tranzakciós ideje vagy szórása milyen, ezek a matematikai mennyiségek léteznek, akár ismeri őket, akár nem, és így mindenképpen stabil terhelést kap.

Az eredmény az, hogy a Queue-Fair szinte tökéletes pontossággal biztosítja a kívánt látogatók percenkénti számát, ami nagyon stabil egyidejű felhasználószámot eredményez a webhelyén, és stabil webszerver-terhelést, amely felett teljes mértékben Ön rendelkezik.

Hurrá!


servers capacity can be exceeced with inaccurate queues És most egy figyelmeztetés. Érdemes megjegyezni, hogy a webhelyen egyidejűleg jelenlévő felhasználók számának stabilitása - és ezáltal a szerverterhelés stabilitása - döntően attól függ, hogy a Virtuális Váróterem szolgáltatója milyen pontosan küldi Önnek a kívánt látogatószámot percenként, ezért ez kulcsfontosságú tényező a Virtuális Váróterem platform kiválasztásakor. Mivel mi biztosítjuk a világ legpontosabb Virtuális Várótermet, senki sem állítja meg jobban a szerverei áradását, mint a Queue-Fair.

Egyszerű módja a várakozási ráta kiszámításának

Mi van akkor, ha nem tudja, hogy hány egyidejű felhasználót tud kezelni egy kiszolgáló, vagy a tranzakciós időt? Megnézheti azt az oldalt, amely valószínűleg a szűk keresztmetszetet jelenti - általában azt, amelyik a "Vásárlás most" gombra kattintás eredménye. A Google Analytics segítségével keresse meg az adott oldal havi egyedi látogatóit, vagy számolja meg a havi megrendeléseit. Ossza ezt el 30 * 24 * 60 = 43 200-zal, ami a havi percek száma (megközelítőleg). Ez az átlagos látogatottsága percenként az egész hónap során. Ezt szorozza meg hárommal. Ez az átlagos látogatói percenkénti látogatottsága munkaidőben (megközelítőleg). Duplázza meg ezt. Valószínűleg ez egy biztonságos számadat a Queue Rate számára.

Tegyük fel például, hogy havonta 100 000 megrendelést dolgoz fel - ez 100 000 kattintást jelent a "Vásárolj most" gombra. Ez 100 000 / 43 200 = 2,31 megrendelés percenként. Arra számíthat, hogy a legtöbb ilyen megrendelés napközben történik, és a szerverei éjszaka csendesebbek, így szorozza meg ezt 3-mal, és ez 7 megrendelést jelent percenként, ami egy durva becslés arra vonatkozóan, hogy mennyire elfoglalt a szervere munkaidőben. Ha az így kapott szám kevesebb, mint 50: a keresletben csúcsok és hullámvölgyek lesznek, így ha a szervere nem feltűnően lassú a csúcsidőben, szorozza meg ezt 2-vel, hogy 14 aktív felhasználó per percet kapjon. Ha a szám több mint 50: a percenkénti csúcsok és hullámvölgyek ehhez képest kisebbek lesznek, és nem biztonságos ezt megduplázni. A végül kapott szám valószínűleg egy biztonságos szám a Queue Rate (Sorbanállási sebesség) kiindulási értékének, és megfelel annak, hogy hány kérést tud biztonságosan kezelni másodpercenként; ezt bármikor növelheti, ha úgy találja, hogy a rendszerek még mindig reagálnak a végfelhasználók teljesítményére ezen az arányon.

az aktív felhasználók maximális számának kiszámítása a webes alkalmazáshoz

Ha a megrendelései időbélyegzővel vannak ellátva, akkor megnézheti a maximális megrendeléseket is, amelyeket az elmúlt hónapban egyetlen perc alatt vett fel - de óvatosan használja, mivel nem tudhatja, hogy hány megrendelést dobott el ebben a percben a szerverek lassulása miatt, ezért csökkentse ezt 20%-kal.

A cikk további részében a Queue Rate kiszámításának néhány más módját tárgyaljuk.

zavar az egyidejű felhasználókkal, az egyidejű kapcsolatokkal, az egyidejű munkamenetekkel és az átlagos munkamenet időtartamával kapcsolatban.

Megvagy #1: Egyidejű felhasználók vs. Egyidejű kérések vs. Egyidejű kapcsolatok vs. Egyidejű munkamenetek

Érdemes rámutatni, hogy a "párhuzamos felhasználók" fogalmának legalább két definíciója létezik a közhasználatban.

Mi a következő meghatározást használjuk : "a tranzakcióáramlásban egy időben részt vevő személyek száma ". Ez az a kulcsszám, amelyet ismernie kell a sorbanállási ráta beállításához. Ez az, hogy hány felhasználó nézi éppen most az oldalát. Az egyidejű munkamenetek száma általában valamivel nagyobb, mint az egyidejű kapcsolatok vagy egyidejű felhasználók száma, mivel néhány munkamenet éppen időzítés alatt van, ami növeli a munkamenet átlagos időtartamát.

Ezzel szemben áll az Egyidejű kérések száma, amely a webkiszolgáló által egyszerre feldolgozott HTTP-kérések száma. Nagyon zavaró, hogy sok technikai szakember a hány egyidejű kérés alatt azt érti, hogy hány egyidejű felhasználó.

Aztán ott van még a Concurrent Connections (vagy a hálózati kártyádon ugyanazon szerverportra irányuló párhuzamos TCP-kapcsolatok), ami a szerverporton vagy a backend szolgáltatáson egy időben nyitott TCP/IP-csatlakozások számát jelenti. Az oldalkérések során a böngészők alapértelmezés szerint nyitva hagyják a kapcsolatot arra az esetre, ha az oldal további kéréseket intézne, vagy ha a felhasználó egy másik oldalra lépne. Ez csökkenti az új TCP/IP-kapcsolatok megnyitására irányuló másodpercenkénti kérések számát, így a kiszolgálási folyamat hatékonyabbá válik. Ezeknek az egyidejű kapcsolatoknak az időkorlátjai böngészőnként változnak, a 60 másodperctől a soha nem záródóig. A kiszolgáló automatikusan lezárhatja a kapcsolatokat egy bizonyos idő után is, ha nem történik aktivitás. Linuxos webkiszolgálókon ezzel a paranccsal megszámlálhatja az azonos szerverportra irányuló párhuzamos kapcsolatokat:

netstat -aenp | grep ":80 \|:443 " | wc -l

amit kipróbálhatsz, ha kíváncsi vagy. Ismétlem, egyesek ezt is "Concurrent Users"-nek hívják, pedig valójában párhuzamos kapcsolatokat jelent.

Valójában, ha megkéri a tárhelyszolgáltatóját, hogy mondja meg a webszerver által kezelt egyidejű felhasználók maximális számát (mekkora csúcsforgalmat), valószínűleg az egyidejű munkamenetek, egyidejű kérések vagy egyidejű kapcsolatok számát fogja megadni, azon egyszerű oknál fogva, hogy nem ismerik az átlagos tranzakciós időt, a tranzakcióáramlásban lévő oldalak számát, vagy bármely más olyan információt, amely lehetővé tenné számukra, hogy megmondják, hány egyidejű felhasználót kezel a webszerver. Mindezen számoknak különböző értékei vannak.

Ha a tárhelyszolgáltatótól vagy a technikai csapattól kér információt a maximális forgalmi szintekről, nagyon fontos, hogy tisztázza, hogy egyidejű felhasználókra, egyidejű munkamenetekre, egyidejű kérésekre vagy egyidejű kapcsolatokra gondolnak.

Ha ezt elrontod, összeomolhat a weboldalad!

Íme, miért. Minden oldal egyetlen HTTP-kérés, de a webalkalmazásból származó képek, szkriptek és egyéb fájlok, amelyeket a böngésző az oldal megjelenítéséhez használ, szintén HTTP-kérések.

Képzeljük el, hogy a technikai csapat azt mondta, hogy a kiszolgáló 500 egyidejű felhasználót támogat, de valójában 500 egyidejű kérést értettek alatta. Az 5 perces tranzakciós idővel a fenti képletet használja, és feltételezi, hogy a webhelye 100 látogatót tud támogatni percenként.

Tényleg? Nem.

Ahogy az emberek végigmennek a tranzakciós folyamaton, valójában csak az egyes oldalak betöltése közben kérnek kéréseket a szerverektől. Ez befolyásolja, hogy másodpercenként mekkora forgalmat vagy aktív felhasználókat tud kezelni a szervere. Az ötperces tranzakciós időből ez egy átlagos felhasználó számára csak néhány másodpercet jelent. Ezért azt gondolhatod, hogy az 500 párhuzamos kérés azt jelenti, hogy sokkal több párhuzamos felhasználót tudsz kezelni, de lehet, hogy tévedsz. Most már látja, hogy a webhely kapacitásának megértése a forgalom nagysága vagy az aktív felhasználók teljes száma szempontjából mennyire bonyolult dolog?

a biztonságot először a szerver erőforrásai számára, amikor kiszámítja, hogy hány kérést kaphatnak a weboldalak, hogy minden egyes felhasználó számára jó élményt nyújtsanak.

Egyidejű kérések átalakítása egyidejű felhasználókká

Ahhoz, hogy a maximális egyidejű felhasználók számát az egyidejű kérések maximális teljes számából kiszámíthassa, tudnia kell a következőket is

  1. Az oldalak száma a tranzakcióáramlásban
  2. A látogató átlagos tranzakciós ideje az első oldaltól az utolsó oldalig az Ön adatfolyamában
  3. Átlagosan hány kérés alkotja az egyes oldalakat
  4. Az átlagos idő, amely alatt a kiszolgáló feldolgoz egy HTTP-kérést.

Az 1) és a 2) pontot valószínűleg már ismered - a mi példánkban 6 oldal és 5 perc. Könnyen megszámolhatja, hogy milyen oldalakat lát tranzakció közben. Ha nem tudja az átlagos tranzakciós időt, a Google Analytics megmondhatja, vagy ellenőrizheti a webszerver naplóit.

A 3) és a 4) pontban a Firefox böngésző segíthet. Kattintson a jobb gombbal egy oldalra a webhelyén, válassza az Inspect Element (Elem ellenőrzése), majd a Network (Hálózat) lapot. Ezután nyomja le a CTRL-SHIFT-R billentyűt az oldal teljes frissítéséhez. A listában látni fogja az oldal minden elemének hálózati betöltési idejét. Meg kell győződnie arról, hogy az Átvitt oszlopban láthatja az átviteli méreteket, mivel ellenkező esetben előfordulhat, hogy a fájlok a gyorsítótárból kerülnek kiszolgálásra, ami összezavarhatja a számításokat. Előfordulhat, hogy néhány szkript és egyéb erőforrás nem az Ön webhelyétől eltérő szerverről érkezik, ezért a bal oldali szűrőmezőbe beírhatja webhelye domainnevét. Az Időtartam oszlop megjelenítéséhez kattintson a jobb gombbal bármelyik oszlopfejlécre, és válassza a felugró menüből az Időtartam -> Időtartam menüpontot. A képernyőnek így kell kinéznie:

google feldolgozza a megfelelően konfigurált nginx a google analytics a kép feltöltéséhez

A Firefox Network lapja ehhez az oldalhoz, amely a queue-fair.com oldalról érkező kérések időtartamát és számát mutatja.

Az oldalai megjelenítéséhez használt fájlok számos különböző webhelyről származhatnak, ezért a bal felső sarokban található szűrővel csak a saját webhelyéről származó fájlokat érdemes megjeleníteni - de csak akkor, ha biztos benne , hogy a más webhelyekről származó fájlok nem okozzák a lassú oldalletöltést, vagy nem képezik a szűk keresztmetszet részét.

A Firefox megszámolja a kéréseket a kijelző bal alsó részén, és 36 HTTP-kérést mutat csak erre az egy oldalra.

Ezt a tranzakcióáramlás minden egyes oldalára meg kell tennie - számolja meg az összeset, és ossza el az oldalak számával, hogy megtalálja az egyes oldalak HTTP-kéréseinek átlagos számát (3.) a listánkon. Most már láthatja, hogy az egyes HTML-oldalakhoz tartozó gyermekkérések száma miért olyan kulcsfontosságú tényező annak szempontjából, hogy a webszerver mekkora forgalmat tud kezelni.

A 4.) számhoz meg kell néznie az Időtartam oszlopot, és meg kell találnia az összes HTTP-kérés átlagát az összes oldalra vonatkozóan. Ha nem vagy biztos benne, feltételezz fél másodpercet - ebben amúgy is sok a bizonytalanság (lásd alább).

a matematikai számítások elvégzése annak kiszámításához, hogy hány munkamenet van egyidejűleg, hány felhasználó és hány kérés van másodpercenként a webes alkalmazáson, legyen az egyszerveres vagy statikus tartalom

A matematika elvégzése

Adjunk néhány példát. Már mondtuk, hogy a példaszerver folyamatfolyamatában hat dinamikus oldal van, ami az 1), és hogy az átlagos tranzakciós idő öt perc, ami a 2). Tegyük fel, hogy oldalanként 36 HTTP-kérés a 3), és fél másodperc a szerver feldolgozási ideje minden egyes HTTP-kérésre, ami a 4).

Ezekkel a számokkal egy kiszolgáló, amely 500 egyidejű kérést tud kezelni, 500 / (0,5 másodperc) = 1000 HTTP-kérést tud kezelni másodpercenként, ami 60 000 HTTP-kérést jelent percenként, amikor teljesen ki van merülve.

Az ötperces tranzakciós idő alatt 5 * 60 000 = 300 000 HTTP-kérést tud kezelni. Soknak tűnik, igaz?

De minden egyes látogatóra hat oldal jut, amelyek mindegyikén átlagosan 36 HTTP-kérés van, tehát 6 * 36 = 216 kérés.

Tehát a 300.000 HTTP-kérés kapacitása elméletileg 300.000 / 216 = 1.389 egyidejű felhasználót tud kezelni.

Megvagy #2: A webszerverek lassulnak a terheléssel

Hé, ez nagyszerű! Azt hittük, hogy csak 100-as várakozási arányt tudunk elérni, de 1,389 / 5 perc = 278 látogató percenként, így magasabb várakozási arányt is elérhetünk!

Nos, valószínűleg nem. Először is, a látogatók nem fognak pontosan fél másodpercenként kéréseket küldeni, ahogy azt a fenti számítás feltételezi. Ennél is fontosabb, hogy a bemeneti adatokat akkor mérte, amikor a webhely nem forgalmas. Szemét be, szemét ki.

Amikor a webhely elfoglalt, a szervernek tovább tart a kérések feldolgozása - ezt már más webhelyeken is észrevehette, amikor a dolgok elfoglaltak, hogy tovább várakozik az oldalakra. Ez megnöveli a kiszolgáló átlagos idejét egy HTTP-kérés feldolgozásához (4), ami csökkenti a maximális átviteli teljesítményt. Vegyük tehát a 278 látogatót percenként, és felezzük meg. Aztán ismét felezd meg. Valószínűleg reálisan körülbelül 70 új látogatóval számolhatsz percenként maximális terhelés mellett.

minél nagyobb a terhelés a forgalmi hullámok miatt, annál lassabbak lesznek a gépek.

További zavaró tényezők közé tartozik a gyorsítótárazási funkció, ami azt jelenti, hogy a látogatók böngészőjének nem kell minden egyes oldalhoz minden egyes kérést megtennie - ez általában azt jelenti, hogy a szervernek kevesebb erőforrásra van szüksége, és növelheti a szerver által percenként kezelhető új látogatók számát. A terheléselosztók, amelyek több szerver között osztják el a terhelést, és a dinamikus oldalak helyett statikus tartalmak kiszolgálása szintén felgyorsíthatja a szerver folyamatát, mivel minden egyes szerver kevesebb erőforrást igényel.

Azt is látni fogja, hogy nem minden oldal elkészítése egyforma időt vesz igénybe, mivel egyesek előállításához és kiszolgálásához kevesebb erőforrásra van szükség, mint másokéhoz. Az adatbázis-keresések, a keresési lekérdezések és a frissítések tartanak a legtovább, így valahol a folyamatában lesz egy szűk keresztmetszet, ahol az emberek felhalmozódnak, várva a hitelkártyaadatok feldolgozására és a megrendelések tárolására, vagy a rendelkezésre állás ellenőrzésére várva. Minden tranzakcióáramlásnak van egy leglassabb lépése, így mindig van valahol egy szűk keresztmetszet, és mindig van egy maximális értékű válasz arra a kérdésre, hogy hány egyidejű felhasználót tud kezelni egy webszerver - és ez több korlátot is jelenthet. Ebben az esetben a Queue Rate-t elég alacsonyra kell állítani ahhoz, hogy a szerverének legyen cpu időkapacitása elegendő ember egyidejű feldolgozására a folyamat leglassabb lépésénél, hogy az emberek ne halmozódjanak fel ott. Ellenkező esetben a webszervered szó szerint leállhat.

bizonytalan, hogyan lehet megbecsülni a szerverek kapacitását szerver erőforrások minden egyes felhasználó számára

Akkor mit tegyek?

Az a tapasztalatunk, hogy az első eladáskor mindenki túlbecsüli szervereinek képességét, hogy megbirkózzon a nagy forgalommal.

Mindenki.

Az átlagos munkamenet időtartamának és a végfelhasználói teljesítménynek a pontos meghatározása lassú vagy csúcsforgalom idején nem a gyengéknek való. A legjobb, amit tehetünk, hogy futtatunk egy megfelelő terheléses tesztet, ahol a "hamis" ügyfelek terheléses tesztelés közben ténylegesen végigmennek a rendelési folyamaton, pontosan úgy, mint a való életben, ugyanazokat a HTTP-kérelmeket ugyanabban a sorrendben, ugyanazokkal az oldalak közötti várakozásokkal, mint a való életben, és figyeljük a processzorterhelést, az IO-átviteli sebességet és a válaszidőket, ahogy növeljük a virtuális látogatók számát. Használhatja ehhez az Apache JMeter-t (mi a K6-ot is szeretjük a kisebb terheléshez vagy lassabb gépekhez), de bármilyen eszközt is használ, időigényes és trükkös minden egyes felhasználó viselkedését pontosan a megfelelő módon utánozni (különösen a gyorsítótárazással kapcsolatos komplexitások miatt). Még akkor is vedd a maximális számodat és felezd meg.

Ennek hiányában inkább az óvatosságra int.

A Queue-Fair portálon keresztül bármikor könnyen módosíthatja bármely Queue-Fair várólista várakozási sebességét. Kezdje 10 látogatóval percenként, vagy egy átlagosabb napon a tranzakciós rátájával, nézze meg, hogy megy ez egy kis ideig, miután a jegyek értékesítésre kerülnek, és ha minden jónak tűnik, a processzor terhelése alacsony, az sql-adatbázis rendben van, és (mindenekelőtt) az oldalai reagálnak, amikor megnyomja a CTRL-SHIFT-R-t, duplázza meg, várjon egy kicsit, és ismételje meg. A "terheléskiegyenlítés" (látod, mit csináltunk?) során hamarosan megtalálod a szükséges tényleges sebességet, és ne feledd, hogy az ügyfélélmény szempontjából nem baj, ha növeled a Queue Rate-ot, mivel ez csökkenti a becsült várakozási időt, amit a sorban lévő ügyfelek látnak, és mindenki örül, ha a válaszidő rövidebb becsült várakozási időt biztosít.

Amit el akarsz kerülni, az az, hogy túl magasra állítsd be a várakozási arányt, majd kerülj abba a helyzetbe, hogy csökkentened kell, mivel ez a) azt jelenti, hogy a webhelyet használó emberek lassú oldalbetöltést tapasztalnak, és b) a becsült várakozási idő növekedését okozza. A sorban állók mind felsóhajtanak!

Megvagy #3: A sebesség túl gyors emelése a sor megnyitása után

Ne feledje, hogy valahol a rendelési folyamatban lesz egy szűk keresztmetszet - minden tranzakciónak van egy leglassabb lépése -, és ott több munkamenet fog felhalmozódni. Amit nem akarsz, az az, hogy egy percet tölts a jegyértékesítésben, és azt lásd, hogy a szerver processzorterhelése jóval a maximális szám alatt van, és emeld meg a sebességet. A látogatóid valószínűleg még nem jutottak el a "Vásárolj most" gombig. Várni akarsz, amíg az sql-adatbázisod az új megrendeléseket ugyanolyan vagy hasonló arányban jelenti, mint a várakozási arányod, és akkor végezd el a méréseket és a válaszkészségi teszteket. Ne feledje, hogy minden alkalommal, amikor növeli a sebességet, ugyanannyi időbe telik, amíg az extra látogatók elérik a szűk keresztmetszetet, így nem tudja majd pontosan felmérni, hogyan teljesít a szervere az új sebesség mellett, amíg ez az idő el nem telik.

lelassítja a szerver erőforrásainak fogyasztására vonatkozó döntést
a szerverek leállnak, amikor a szerverek kapacitása túllépésre kerül

Megvagy #4: A kiszolgálók megpattintása

Azt már megbeszéltük, hogy a sorbanállás megnyitásakor a sorbanállási arányt érdemes fokozatosan növelni. Valószínűleg tisztában van azzal, hogy a szervereinek van egy határértéke, amelyet nem lehet túllépni a rendszer összeomlása nélkül, és talán még azzal is tisztában van, hogy mi ez a határérték - de azt talán nem tudja, hogy amikor a terhelés megközelíti ezt a határt, általában nagyon kevés jelzést ad - gyakran csak néhány hibát vagy figyelmeztetést, vagy 80% feletti processzorterhelést.

Ha a webes szolgáltatások meghibásodnak, akkor hajlamosak nagyon gyorsan leállni vagy leállni. Ennek oka általában az, hogy amint a rendszer már nem tudja olyan gyorsan feldolgozni a kéréseket, ahogyan azok beérkeznek, belső feldolgozási sorok alakulnak ki. A rendszernek ekkor a kérések mellett a belső várólisták feldolgozásával, kezelésével és tárolásával is foglalkoznia kell, és ez az, ami a szervereket a tönk szélére sodorja. Nagyon gyorsan. Amint ez megtörténik, szerverei egy ideig talán képesek egy hibaoldallal válaszolni, de ez nem segít, mert az ezt látó látogatók azonnal a Frissítésre fognak kattintani, ami tovább növeli a terhelést.

Tehát ne erőltesse a szervereit a kelleténél jobban. A cpu időkapacitás utolsó 20%-ára való törekvés általában nem éri meg a kockázatot. Ha a Queue-Fair portálon megjelenített várólista mérete (a sárga Várakozás ábra és vonal a grafikonokon) percről percre csökken vagy akár csak lassabban növekszik, és a megjelenített várakozási idő 50 perc vagy annál kevesebb, akkor elég gyorsan dolgozza fel a megrendeléseket, és a várólista végül ki fog ürülni, és automatikusan leállítja a várólisták megjelenítését, anélkül, hogy bármit is tennie kellene, és anélkül, hogy szólnia kellene a főnökének, hogy túl keményen nyomta és tönkretette. Előbb-utóbb el fogod érni, amíg a Sor elejének sebessége nagyobb, mint a percenkénti csatlakozások száma (mindkettő a Queue-Fair portálon látható) - a fordulópont általában legalább néhány perccel az egyes események után van. Ha korlátozott mennyiségű terméket árul, valószínűleg már a fordulópont elérése előtt el fog fogyni.

A jó hír az, hogy ha véletlenül túl magasra állította a várólista sebességét, és a szerverei összeomlanak, a Queue-Fair segíthet a gyors helyreállításban - egyszerűen csak várakoztassa a várólistát, amíg a szerverei újra készen állnak a látogatók kezelésére. Tartás üzemmódban a sorban állók egy speciális Tartás oldalt látnak, amelyet az online esemény előtt megtervezhet. Senkit sem engednek át a sor elejéről, amikor a sor tartási módban van, de az új internetes látogatók továbbra is csatlakozhatnak a sorhoz a hátsó sorban, hogy tisztességesen sorba kerüljenek, amint a torlódás megszűnik, ami nagyon gyorsan megtörténik, mivel a Queue-Fair megvédi webhelyét a kereslettől. A Tartás oldal kiváló felhasználói élményt nyújt, mintha nagyon alacsonyra állítaná a Sorban állás arányát, különösen, ha frissíti azt, hogy közli a látogatókkal, hogy mikorra várja a sor újranyitását, amit a Portál oldal szerkesztőjével könnyen megtehet, még akkor is, ha már több százezer ember áll a sorban - és a Tartás módban akár egyesével is átengedheti őket a Queue-Fair egyedülálló Admit One gombjával, ha erre van szükség, amíg a rendszer helyreáll a megakadásból.

Ha tehát úgy találja, hogy szervereinek szünetet kell tartaniuk az esemény alatt, a Hold oldal pont erre a célra szolgál, és ráadásul segít a szerverek gyorsabb helyreállításában.

Következtetés

Ebben a cikkben elmagyaráztuk, hogy miért mindig a sebességalapú várólista a legjobb megoldás, és két módszert adtunk meg a szükséges sebesség kiszámításához, de hacsak nem végeztél teljes és pontos virtuális látogatói terhelési tesztelést a teljes tranzakcióáramlásodon, és nem vagy igazán szuper extra mega biztos ebben, a tanácsunk mindig ugyanaz:

  1. Kezdje a várakozási arányt 10-re állítva, vagy a tranzakciós arányt egy átlagosabb napon.
  2. Figyelje a processzor terhelését és más teljesítménymutatókat.
  3. Várjon, amíg az új megrendelések rögzítése az sql-adatbázisban ugyanolyan vagy hasonló ütemben történik, mint a várakozási arány.
  4. A CTRL-SHIFT-R billentyűkombinációval ellenőrizheti az oldalai érzékenységét.
  5. Növelje a várakozási arányt legfeljebb 20%-kal.
  6. Térjen vissza a 2. lépéshez, és várjon ismét.
  7. Amint a sor mérete csökken vagy percenként folyamatosan, kevésbé gyorsan növekszik, és a feltüntetett várakozási idő kevesebb, mint 50 perc, nem kell gyorsabban haladnia.
  8. Dőljön hátra és pihenjen! A Queue-Fair gondoskodik önről.

Ha korlátozott mennyiségű terméket árul, akkor a 7. lépésre sem kell figyelnie.

Ez az első várólistára vonatkozik, amikor nem ismeri a rendszer által támogatható tényleges maximális várakozási sebességet. A további sorok esetében, ha már megmérte a rendszer által ténylegesen kezelhető várakozási sebességet, akkor újra használhatja ugyanazt a számot - de csak akkor, ha semmi sem változott a rendszerben. A gyakorlatban a rendszerét valószínűleg folyamatosan fejlesztik és módosítják, és nem biztos, hogy tudja, hogy a legutóbbi változások hogyan befolyásolták a maximális várakozási sebességet - miért nem kezdjük tehát a korábbi mért érték felével, és ismételjük meg a fenti folyamatot?

Ne feledje, mindig jobb félni, mint megijedni.


Vezető szervezetek százai bíznak a
sorbanállási megoldásainkban

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

Az egyszerű megoldás az internetes forgalmi hullámokra

Kezdje el