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.
Hagyományosan az e-kereskedelmi szervereket úgy állítják be, hogy maximális számú egyidejű felhasználót támogassanak, és a terhelést gyakran így határozzák meg. Van egy probléma azzal, ha ezt a megközelítést egy weboldal várólistájának futtatására használjuk - ezt a problémát mi az árakkal oldjuk meg.
A probléma azért merül fel, mert a látogatók csak akkor használják ténylegesen a webszervereket, amikor a böngészőjük betölti az egyes weboldalakat.
Tegyük fel például, hogy egy e-kereskedelmi oldal jegyeket árul. A látogatói utazás kezdetétől a látogatói utazás végéig (a felhasználói munkamenetig) hat oldal van, mivel a látogató
A teljes tranzakciós folyamat átlagosan öt percet vesz igénybe.
Tegyük fel, hogy például 100 látogató érkezik percenként jegyet vásárolni, és a folyamat átlagos időtartama öt perc. Egy adott időpontban 500 ember van egyszerre a tranzakciós folyamatban, és a kiszolgálót 500 egyidejű felhasználó támogatására kell felkészíteni.
Azt gondolhatnánk, hogy létrehozhatunk egy Concurrent User Counter-t, amely minden alkalommal növekszik, amikor egy új látogató érkezik a kezdőlapra, és minden alkalommal csökken, amikor egy látogató befejezi a tranzakciót, és ez megmondja, hogy hány felhasználót kezel egy szerver egy időben, de ez nem fog működni.
Nem fog működni, mert nem minden látogató fejezi be a tranzakciót. Az emberek meggondolják magukat, vagy megzavarodnak, vagy elmennek, és később térnek vissza. Mivel a webszerver csak akkor lép kapcsolatba a látogatókkal, amikor a böngészőjük betölti az oldalakat, a webszerver nem tudja, hogy ez mikor és kivel történt meg.
Ehelyett annak megállapításához, hogy a látogató már nem része a tranzakciós folyamatnak, az egyetlen kiszolgálónak meg kell várnia, hogy az adott látogatótól nem érkezik több oldalkérés, majd meg kell szüntetnie a látogató munkamenetét. Az időkorlátokat mindig sokkal hosszabbra kell beállítani, mint az átlagos tranzakciós idő (ebben a példában mondjuk 20 perc), mivel egyes látogatóknak sokkal tovább tart a tranzakció befejezése, mint másoknak.
Hozzáadhatnánk azt a lehetőséget, hogy minden alkalommal, amikor egy látogatói munkamenet ily módon leáll, csökkentse a fiktív Concurrent User Counter-t, de ez nagyon rossz eredményt ad.
Ha a percenként érkező 100 látogató 10%-a nem fejezi be a tranzakciót, akkor azok, akik befejezik, átlagosan öt percig aktívak, és azok, akik nem fejezik be, mindig legalább 20 percig aktívnak tekintendők (valójában a munkamenet-időtartam plusz az átlagos munkamenet időtartama valószínűbb, ha több munkamenetet veszünk figyelembe).
Ez 90 * 5 + 10 * 20 = 650, és a kiszolgáló 650 egyidejű felhasználót jelent, még akkor is, ha valójában kevesebbet dolgozik!
Továbbá, az egyidejű felhasználók közül 10 * 20 = 200 nem használja a webhelyet, és éppen az időzítés folyamatában van, ami a bejelentett egyidejű felhasználók több mint 30%-a, még akkor is, ha a látogatóknak csak 10%-a nem fejezi be a tranzakciót.
Most tegyük fel, hogy valaki szeretne egy várólistát hozzáadni ehhez a weboldalhoz, amelyet a Concurrent User Counter vezérel. Ha a webhely kapacitása elérte a kapacitást, akkor a sor elején álló személy csak akkor kerül át a webhelyre, ha a számláló csökken. Ezt nevezzük egy ki-bejáró sornak. Az fog történni, hogy az idő 30%-ában a sor elején álló személy arra fog várni, hogy valaki, aki nem fogja befejezni a tranzakcióját, befejezze a tranzakcióját, és ne fejezze be a tranzakcióját.
A számláló létrehozásával és működtetésével, valamint az információknak a várólista-rendszerrel való megosztásával járó további technikai integrációs munka és a weboldalra nehezedő terhelés is felmerül. Ha a megosztási vagy számlálási mechanizmus leáll vagy elromlik, a sorban állás elakad. Még rosszabb, ha az egyetlen szerver annyira elfoglalt, hogy nem tudja frissíteni a sorban állási szervert, hogy a sorban állási szervernek szóljon, hogy engedje be a következő személyt, akkor a sor is megreked.
Mindezek a problémák könnyen és egyszerűen megoldhatók, ha a látogatókat a sor elejéről küldjük el állandó, rögzített sebességgel - ebben az esetben 100 látogató percenként.
Így nem kell mérni az egyidejű felhasználók tényleges számát, nincs szükség bonyolult integrációra a jegyértékesítő weboldallal, és nem áll fenn a sorban állás kockázata.
Ezért találtuk fel és szabadalmaztattuk 2004-ben a forgalmas weboldalak számára a tarifaalapú virtuális várótermet.
‘A Queue-Fair nagyszerű a nagy online kiskereskedelmi eseményünkhöz. Nagyon intuitívnak tűnt a használata, és teljesen jól működött. A Queue-Fair folyamatosságot biztosít és növeli a bizalmat az ügyfelek online élménye iránt. Mindenképpen tervezzük a Queue-Fair használatát a jövőben olyan eseményekre, ahol hatalmas forgalomáradatra és nagyobb kiskereskedelmi eseményeken való részvételre számítunk.’
‘A Queue-Fair őszintén egy csodálatos termék - nagyon ajánlott. Bárcsak korábban váltottunk volna! Az egész folyamat a bevezetésig az egyik legsimább folyamat volt, amit valaha tapasztaltam. A Queue-Fair további funkciókkal rendelkezik, amelyeket az előző beszállítónk nem tudott elérni, így a váltás könnyű volt. Bárki, aki sorbanállási terméket keres, ne keressen tovább. Mi imádjuk!’
‘A kommunikáció nagyon zökkenőmentes volt, és minden jól működött. A kampány sikeres volt - a szerverünkkel végig a zöld zónában voltunk! Minden működött, mind technikai, mind ügyféloldalon, és pozitív visszajelzéseket kaptunk. Javasoljuk, hogy vegye fel a kapcsolatot a Queue-Fair-val! Örülök, hogy megtaláltuk a megoldást a problémáinkra.’
‘Minden tökéletesen működött! Minden alkalommal használni fogom, amikor forgalmi csúcsot kapunk, hogy ne veszítsünk el látogatókat. A Queue-Fair a legolcsóbb megoldás a piacon. Szó szerint néhány perc alatt telepíthető. Nagyszerű támogatás és nagyon jó reakcióképesség. Könnyen szerkeszthető oldalak. A legjobb bumm a pénzéért, amit kaphat a kritikus esemény kezelésére, képes voltam kezelni több mint 10.000 látogató forgalmi csúcsot a TV show hibátlanul.’
‘Nonszensz, költséghatékony sorbanállási rendszer, amely működik. A Queue-Fair segített nekünk mind a konkrét termékbevezetéseknél, mind a napi forgalmi csúcsoknál. Zökkenőmentesen működik számunkra - amikor bármilyen technológiát kipróbálunk, megnézzük, hogy a) működik-e és b) költséghatékony-e, és a Queue-Fair mindkettő, és nagyon boldog vagyok, hogy továbbra is használhatom a kiváló szolgáltatást. Több lehetőséget is megnéztünk, de a Queue-Fair volt az egyértelmű győztes az ár szempontjából, és hibátlan.’
‘Egyszerűen működik! Ez volt az idei év legkönnyebb indítása. A négy fő termékünkből minden elkelt, és a tervezettnél 20%-kal több bevételt értünk el. A sorban állási rendszer lehetővé tette az emberek számára, hogy úgy érezzék, több idejük van vásárolni, így további termékeket tettek a kosarukba. A bevezetésünk valós idejű megfigyelése jelentős betekintést nyújtott számunkra a jövőbeli termékbevezetésekhez is.’
‘Ez a megoldás lehetővé tette számomra az online értékesítés kezelését, mindenféle gond nélkül. Ez egy könnyen használható megoldás, amely lehetővé teszi, hogy valós időben beavatkozzunk az általunk átengedett látogatók áramlásába. Könnyen konfigurálható, még a sorban állás vizuális megjelenítését és szövegeit is testre szabhatjuk. Külön köszönet Mattnek, aki mindent elmagyarázott nekem franciául, elérhető és hatékony, köszönöm még egyszer Matt! Mielőtt ezt a szolgáltatást használtuk volna, a webszerverünk lassulási problémákkal küzdött, és elérhetetlenné vált. A látogatók áramlásának szabályozásával sikerült orvosolni ezt a problémát.’
‘Vannak olyan eseményeink, amelyek rendkívül népszerűek, és amelyek miatt egyszerre nagyszámú ember látogatja meg a weboldalunkat. A Queue-Fair segít ennek kezelésében, megoldva ezzel a problémát. A legjobban a beállítás során nyújtott támogatás és a könnyű használat tetszett nekünk. A Queue-Fair-t azért ajánljuk, mert kiváló alternatívája más várólista-szolgáltatóknak, és kiváló támogatást nyújt.’
‘Robusztus, életmentő és könnyen megvalósítható! Imádjuk, hogy milyen gyorsan el lehet kezdeni használni, és nagyon felhasználóbarát a kezelőfelülete. A Queue-Fair használatának nincsenek hátrányai, ami megoldotta a nagy forgalom kezelésének problémáját bizonyos pillanatokban, így nem maradunk le egyetlen eladásról sem, és az ügyfélélményt a lehető legjobban tartjuk! Minden, amit vártam a nagy forgalommal kapcsolatos problémáim megoldására, megoldódott, amint bevezettem a Queue-Fair-t.’
‘Tökéletes szolgáltatás, amely segített nekünk az év legforgalmasabb időszakában. Öröm volt velük dolgozni, rugalmasságot biztosítottak, ahol szükségünk volt rá, és kiváló támogatást nyújtottak gyors válaszidővel. A szolgáltatás pontosan megfelelt az igényeinknek.’
‘A tökéletes megoldás a limitált kiadású figuránk megjelenéséhez! A Queue-Fair-t nagyon könnyű megvalósítani, és a paraméterek beállításában jó támogatást és útmutatást kaptunk. A valós idejű jelentés nagyszerű, és lehetővé teszi számunkra, hogy az esemény során a szerverünk összeomlása nélkül módosítsuk a paramétereinket. Nagyon elégedettek vagyunk, és tervezzük, hogy a Queue-Fair-t használjuk a jövőbeli kiadásainkhoz.’
‘Kiváló termék, amelyet kiváló ügyfélszolgálat támogat . A Queue-Fair tökéletes megoldást jelentett a weboldalunkon keresztül a jegyek iránti kereslet növekedésének kezelésére. A Queue-Fair kezeli a webes forgalom tüskéit, segít elkerülni a szerver túlterhelését, és lehetővé teszi ügyfeleink számára, hogy könnyen lássák, hogy a sorban állásuk tisztességes. Ügyfeleink valós időben nyomon követhetik a sorban állás előrehaladását. A Queue-Fair terméke és szolgáltatása felülmúlta várakozásainkat.’
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ő
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.
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á!
É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.
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.
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.
É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.
Í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?
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
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:
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).
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.
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.
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.
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 ebben az esetben is fogd 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 egyszerűen módosíthatja bármely Queue-Fair várólistára vonatkozó várakozási sebességet. 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 oldalak reagálnak, amikor megnyomja a CTRL-SHIFT-R billentyűt, emelje meg legfeljebb 20 százalékkal, várjon egy kicsit, és ismételje meg. A "terheléskiegyenlítés" (látod, mit csináltunk?) során hamarosan megtalálod a ténylegesen szükséges sebességet, és ne feledd, hogy az ügyfélélmény szempontjából nem baj, ha megemeled a Queue Rate-t, mivel ez azt eredményezi, hogy a várakozási idő, amelyet a sorban lévő ügyfelek látnak, csökken, és mindenki örömmel látja, hogy 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!
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.
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.
Ha a látogatóknak egy másodpercnél több időbe telik, hogy lássák az oldalaidat, akkor még előtte nyomják meg a Frissítés gombot. Amikor a látogató a frissítésre kattint, a webszerver nem tudja, hogy a látogató már nem vár választ az eredeti kérésre. Ha mind az eredeti, mind a frissítési kérelem beérkezik, a webszerver mindkettőt feldolgozza. Ez több munkát jelent a webszerver számára, még lassabb válaszokat az összes látogató számára, és még több látogató nyomja le a frissítést, ami egy ördögi körhöz vezet, amely megakasztja a webszerverét, mielőtt még hibaválaszokat küldene.
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.
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:
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?
Így használd a Queue-Fair-t, hogy a továbbértékesítésed szép és biztonságos legyen, és ne feledd, mindig jobb félni, mint megijedni.
A 2004-ben feltalált és szabadalmaztatott Queue-Fair az eredeti virtuális váróterem, amely online várólisták kezelését biztosítja a forgalmas weboldalak és alkalmazások számára.
2024 The Fair Queue People Ltd. - Minden jog fenntartva.
A sorbanállási megoldások Orderly családjának része - OrderlyQ - OrderlyStats - WeQ4U
