Emme oikeastaan löytäneet mitään hyviä puolia yksi ulos, yksi sisään. Lyhyesti sanottuna tämän lähestymistavan ongelmana on se, että kun käyttäjät ovat sähköisen kaupankäynnin verkkosivustojen kävijöitä, verkkopalvelin ei tiedä, kuinka monta samanaikaista käyttäjää sillä on milloinkin. Se on showstopper. Tässä on syy.
Myöhemmin tässä artikkelissa kerromme myös, miten voit käyttää hintaan perustuvaa virtuaalihuonetta myös sivustosi suojaamiseen.
Perinteisesti sähköisen kaupankäynnin palvelimet asetetaan tukemaan yhtäaikaisten käyttäjien enimmäismäärää, ja kuormitus määritellään usein tällä tavoin. Tämän lähestymistavan käyttämisessä verkkosivuston jonon ylläpitämiseen on ongelma, jonka ratkaisemme hinnoilla.
Ongelma johtuu siitä, että kävijät käyttävät verkkopalvelinta todellisuudessa vain silloin, kun heidän selaimensa lataa kutakin verkkosivua.
Sanotaan esimerkiksi, että sähköisen kaupankäynnin sivusto myy lippuja. Kävijän matkan alusta sen loppuun (käyttäjän istuntoon) on kuusi sivua, kun kävijä on
Koko maksutapahtuma kestää keskimäärin viisi minuuttia.
Oletetaan, että esimerkiksi 100 kävijää saapuu ostamaan lippuja joka minuutti, ja prosessiin kuluu keskimäärin viisi minuuttia. Millä tahansa hetkellä tapahtumaprosessissa on samanaikaisesti 500 ihmistä, ja palvelin on varustettava tukemaan 500 samanaikaista käyttäjää.
Voisi ajatella, että voisi luoda samanaikaisen käyttäjälaskurin, jota kasvatetaan joka kerta, kun uusi kävijä saapuu etusivulle, ja jota vähennetään joka kerta, kun kävijä suorittaa tapahtuman loppuun, ja että tämä kertoisi, kuinka monta käyttäjää yksittäinen palvelin käsittelee kerrallaan, mutta tämä ei toimi.
Se ei toimi, koska kaikki kävijät eivät tee ostotapahtumaa loppuun. Ihmiset muuttavat mieltään, häiriintyvät tai lähtevät pois ja palaavat myöhemmin. Koska verkkopalvelin on vuorovaikutuksessa kävijöiden kanssa vain silloin, kun heidän selaimensa lataavat sivuja, verkkopalvelin ei voi mitenkään tietää, milloin tämä on tapahtunut tai kenelle.
Sen sijaan yksittäisen palvelimen on odotettava, että kävijä ei enää osallistu tapahtumaprosessiin, ja odotettava, että kävijä ei enää lähetä sivupyyntöjä, minkä jälkeen hänen istuntonsa katkeaa. Aikakatkaisut on aina asetettava paljon pidemmiksi kuin keskimääräinen tapahtuma-aika (esimerkiksi 20 minuuttia tässä esimerkissä), koska joillakin kävijöillä kestää paljon kauemmin kuin toisilla saada tapahtuma päätökseen.
Voitaisiin lisätä mahdollisuus pienentää myös omaa laskennallista samanaikaiskäyttäjien laskuria joka kerta, kun vierailijan istunto päättyy tällä tavoin, mutta tämä antaa erittäin huonoja tuloksia.
Jos 10 % joka minuutti saapuvista 100 kävijästä ei jatka ostotapahtuman loppuun saattamista, ne kävijät, jotka suorittavat ostotapahtuman loppuun, ovat aktiivisia keskimäärin viisi minuuttia ja ne, jotka eivät suorita ostotapahtumaa loppuun, katsotaan aktiivisiksi aina vähintään 20 minuuttia (itse asiassa istunnon aikakatkaisu ja istunnon keskimääräinen kesto ovat todennäköisempiä, kun otetaan huomioon useita istuntoja).
Se on 90 * 5 + 10 * 20 = 650, ja palvelin ilmoittaa 650 samanaikaista käyttäjää, vaikka se on todellisuudessa vähemmän varattu!
Lisäksi jopa 10 * 20 = 200 näistä samanaikaisista käyttäjistä ei todellisuudessa käytä sivustoa, vaan on keskeyttämässä, mikä on yli 30 prosenttia raportoiduista samanaikaisista käyttäjistä, vaikka vain 10 prosenttia kävijöistä ei saa tapahtumaa päätökseen.
Oletetaan, että tälle verkkosivustolle halutaan lisätä jono, jota ohjataan samanaikaiskäyttäjien laskurilla. Kun sivuston kapasiteetti on saavutettu, jonon kärjessä oleva henkilö pääsee sivustolle vasta, kun laskuri laskee. Tätä kutsutaan yksi ulos-yksi sisään -jonoksi. Näin tapahtuu, että 30 prosenttia ajasta jonon kärjessä oleva henkilö odottaa jonkun, joka ei aio suorittaa maksutapahtumaa loppuun, jotta hän ei suorittaisi maksutapahtumaa loppuun.
Sivustolle aiheutuu myös ylimääräistä teknistä integrointityötä ja kuormitusta laskurin luomisesta ja toiminnasta sekä tietojen jakamisesta jonotusjärjestelmän kanssa. Jos jako- tai laskentamekanismi kaatuu tai rikkoutuu, jono jää jumiin. Vielä pahempaa on se, että jos yksittäinen palvelin on niin kiireinen, ettei se pysty päivittämään jonopalvelinta, jotta se voisi ilmoittaa jonopalvelimelle, että se päästää seuraavan henkilön sisään, myös jono jumittuu.
Kaikki nämä ongelmat voidaan ratkaista helposti ja yksinkertaisesti lähettämällä kävijöitä jonon etupäästä vakioidulla, kiinteällä nopeudella - tässä tapauksessa 100 kävijää minuutissa.
Näin ei tarvitse mitata yhtäaikaisten käyttäjien todellista määrää, eikä monimutkaista integrointia lippusivuston kanssa tarvita, eikä jono voi juuttua jumiin.
Siksi keksimme ja patentoimme vuonna 2004 kiireisille verkkosivustoille suunnatun hinnoitteluun perustuvan virtuaalisen odotushuoneen.
Hämmästyttävä ja helppo tuote! Queue-Fair on todella kaunis. Niin helppo asettaa parametrit reaaliajassa, ja se on myös helppo integroida. Tuki on reaktiivinen ja ystävällinen. Sain perustettua virtuaalisen odotushuoneen 15 minuutissa asetuksineen! Suojelen siis infrastruktuuriani kaikilta näiltä liikennehuipuilta Queue-Fair:n avulla.
Ohjelmistonne ansiosta kaikki pidettiin jonossa pois palvelimeltamme, ja ostajat pääsivät kulkemaan järjestelmän läpi rauhallisesti. Se oli mahtavaa! Kaikki verkkokaupat, joissa asiakkaita on paljon, pitäisivät tätä todella hyödyllisenä. Kiitos paljon ja jatkakaa hyvää työtä!
Loistavaa! Olemme erittäin tyytyväisiä ja tyytyväisiä Queue-Fair:n kanssa, on hienoa saada tämäntasoista tukea. Palvelu toimii täydellisesti - myimme tuhansia lippuja hetkessä, ja Queue-Fair auttoi meitä hallitsemaan liikennettä suurten ruuhkahuippujen aikana! Suosittelemme Queue-Fair:ta myös palvelukumppaneillemme. Olen todella tyytyväinen!
Queue-Fair:n työntekijät tekivät kaikkensa auttaakseen meitä ottamaan jonotusjärjestelmänsä käyttöön yhden päivän aikana. Kun jonossa oli yli 25 000 ihmistä, he auttoivat meitä hallitsemaan liikennettä ruuhkahuippujen aikana. Queue-Fair tekee sen, mihin se on tarkoitettu; asettaa ihmisiä jonoon kilpailukykyiseen hintaan. Olemme tyytyväisiä Queue-Fair-järjestelmään ja käytämme sitä jatkossakin tulevissa tapahtumissa.
Queue-Fair oli juuri sitä, mitä tarvitsimme liikenteen hallintaan ja tukipalvelu on loistava!. Järjestelmä on toiminut erittäin hyvin! Etsimme useita yrityksiä ja epäilemättä olemme löytäneet parhaan! Kiitos paljon, Queue-Fair!
Suuri kiitos siitä, että käänsit kyselymme niin nopeasti. Lähetimme sähköpostia keskiviikkona klo 21.00 ja saimme täysin brändätyn jonosivun, joka oli käyttövalmis torstaina klo 11.00. Yksinkertaisesti loistava! Kojelauta ja ominaisuudet ovat loistavia - todella intuitiivisia, todella siistejä ja helppokäyttöisiä. Jonotimme yli 22 000 ihmistä tuotteen lanseeraustapahtumaamme erittäin kilpailukykyisin kustannuksin. Paljon kiitoksia kaikesta! Olen todella iloinen voidessani antaa Queue-Fair:lle loistavan suosittelun ja suosittelen heitä kaikille yrityksille, jotka tarvitsevat jonotusjärjestelmän tapahtumaansa tai kampanjaansa.
Jos tiedät, kuinka monta yhtäaikaista käyttäjää verkkopalvelin käsittelee ja kuinka kauan tapahtuma kestää keskimäärin tapahtumavirran ensimmäiseltä sivulta tilauksen vahvistussivulle, voit muuntaa tämän jononopeudeksi käyttämällä Littlen lakia jakamalla käyttäjien määrän kestolla seuraavasti:
Jononopeus = yhtäaikaiset käyttäjät / tapahtuma-aika
Queue-Fair toimittaa kävijöitä verkkosivustollesi määrittelemälläsi tahdilla - meillä on ylivoimaisesti tarkin Jono AI alalla, joka varmistaa, että haluamasi kävijöiden määrä minuutissa on kävijöiden määrä, jonka saat joka minuutti, ja ottaa automaattisesti huomioon ihmiset, jotka eivät ole paikalla, kun heidän vuoronsa on kutsuttu, sekä ihmiset, jotka palaavat myöhässä.
Miten tämä näkyy samanaikaisten käyttäjien määrässä? Jokainen sivustollesi saapuva kävijä ei tietenkään kestä täsmälleen yhtä kauan kuin keskimääräinen transaktioaika, mutta Queue-Fair:n avulla saat hyvin tasaisen määrän samanaikaisia käyttäjiä, koska suurten lukujen laki pätee.
Sanotaan esimerkiksi, että jononopeutesi on 100 kävijää minuutissa. Lähetämme sivustollesi 100 kävijää joka minuutti tasaisena virtana - sitä me teemme, ja olemme hämmästyttävän hyviä siinä. Oletetaan myös, että ihmiset käyttävät verkkosivustoasi keskimäärin (keskimäärin) viisi minuuttia, ja 70 prosentilla heistä kestää 4-6 minuuttia siitä hetkestä, kun heidät ohitetaan jonosta, siihen hetkeen, kun he tekevät viimeisen sivupyynnön (riippumatta siitä, suorittavatko he tapahtuman vai eivät). Keskihajonta on siis yksi minuutti keskiarvon molemmin puolin. Tilastollisesti tämä tarkoittaa, että jokaista kävijää kohden, joka viipyy viisi ja puoli minuuttia, on toinen, joka viipyy neljä ja puoli minuuttia, ja nämä vaihtelut yksittäisten käyntien kestoissa useiden istuntojen välillä kumoavat yleensä toisensa, kun lasketaan paljon kävijöitä jollakin tavalla. Suurten lukujen laki sanoo, että tämä kumoutuminen on sitä tarkempaa, mitä suurempi on osallistuvien ihmisten määrä.
Kuinka tarkkaan? Voimme selvittää sen pienen tilaston avulla. Otoskoko on 5 * 100 = 500, joka on tässä tapauksessa suuri luku. Niin monta ihmistä lasketaan. Tämä tarkoittaa, että tapahtuma-ajan keskivirhe on 1 (keskihajonta, 1 minuutti) jaettuna otoskoon neliöjuurella (eli 500:n neliöjuurella) tilastollisen keskivirheen kaavan mukaisesti, jolloin tapahtuma-ajan keskivirhe on 0,044 minuuttia eli vain 2,7 sekuntia, mikä on alle yksi prosentti.
Tämä tarkoittaa, että kun jonon nopeus on 100 ja tapahtuma-aika on 5 minuuttia plus tai miinus minuutti kutakin yksittäistä kävijää kohden, sinun pitäisi odottaa 495-505 samanaikaista käyttäjää sivustollasi noin 70 % ajasta, joten matematiikka sanoo, että nopeuteen perustuvan jonon käyttäminen tuottaa erittäin tasaisen kuormituksen verkkopalvelimillesi halutulla tavalla.
Mutta onko matematiikka oikein? Tässä on joitakin hienouksia - esimerkiksi otoskoko, jota olemme iloisesti neliöimässä, ei ole aina täsmälleen 500 joka kerta, kun samanaikaisia käyttäjiä lasketaan (eli millä tahansa hetkellä), ja myös normaalijakauma (Gaussin jakauma) voi antaa negatiivisia tapahtuma-aikoja, joita ei esiinny todellisessa elämässä. Käytämme siis kävijäkohtaista, sekuntikohtaista simulaattoria mittausten tekemiseen tällaisten laskelmien tarkistamiseksi, ja se kertoo meille, että edellä mainituilla luvuilla pitäisi odottaa 493-507 kävijää 70 prosenttia ajasta, joten matematiikka pitää paikkansa huomattavan hyvin! Mittaukset kertovat myös, että sivustollasi on 500 ± 15 samanaikaista käyttäjää vähintään 95 % ajasta.
Se on luultavasti tasaisempi kuin se tarkkuus, jolla verkkopalvelimesi voi mitata sivustoa käyttävien ihmisten lukumäärän! Vielä parempaa on se, että vaikka sinulla ei olisi aavistustakaan siitä, mikä on kävijöiden keskimääräinen tapahtuma-aika tai keskihajonta, nämä matemaattiset suureet ovat olemassa riippumatta siitä, tiedätkö ne vai et, ja saat joka tapauksessa vakaan kuormituksen.
Lopputulos on, että Queue-Fair tuottaa haluamasi kävijämäärän minuutissa lähes täydellisellä tarkkuudella, mikä johtaa erittäin tasaiseen samanaikaisten käyttäjien määrään sivustollasi ja vakaaseen verkkopalvelimen kuormitukseen, jota voit hallita täysin.
Hurraa!
Ja nyt varoitus. On syytä huomata, että sivustosi samanaikaisten käyttäjien määrän vakaus - ja siten palvelinkuormituksen vakaus - riippuu ratkaisevasti siitä, kuinka tarkasti virtuaalisen odotushuoneen palveluntarjoaja lähettää sinulle haluamasi kävijämäärän joka minuutti, ja tämä on siksi avaintekijä, kun valitset virtuaalisen odotushuoneen alustan. Koska me tarjoamme maailman tarkimman Virtual Waiting Room -palvelimen, kukaan ei pysäytä palvelintulvia paremmin kuin Queue-Fair.
Entä jos et tiedä, kuinka monta samanaikaista käyttäjää palvelin voi käsitellä tai kuinka monta transaktioaikaa? Voit tarkastella sivua, joka todennäköisesti on pullonkaulasi - yleensä se, joka on seurausta "Osta heti" -painikkeen napsauttamisesta. Etsi Google Analyticsin avulla kyseisen sivun kuukausittaiset yksittäiset kävijät tai laske kuukausittaiset tilauksesi. Jaa tämä luvulla 30 * 24 * 60 = 43 200, joka on minuuttien määrä kuukaudessa (noin). Tämä on keskimääräinen kävijämääräsi minuutissa koko kuukauden aikana. Kerro tämä kolmella. Se on keskimääräinen kävijämääräsi minuutissa työaikana (noin). Tuplaa tämä. Tämä on luultavasti turvallinen luku Queue Rate -arvolle.
Sanotaan esimerkiksi, että käsittelet 100 000 tilausta kuukaudessa - se tarkoittaa 100 000 klikkausta Osta nyt -painiketta. Se on 100 000 / 43 200 = 2,31 tilausta minuutissa. Odotettavissa on, että suurin osa näistä tilauksista tehdään päivällä ja että palvelimesi ovat hiljaisempia yöllä, joten kerro tämä luvulla 3, niin saat 7 tilausta minuutissa karkeaksi arvioksi siitä, kuinka kiireinen palvelimesi on työaikana. Jos saatu luku on alle 50: kysynnässä on huippuja ja notkahduksia, joten jos palvelimesi ei ole huomattavan hidas ruuhka-aikoina, kerro tämä luvulla 2, jolloin saat 14 aktiivista käyttäjää minuutissa. Jos luku on yli 50: minuuttien väliset huiput ja notkahdukset ovat pienempiä, eikä ole turvallista kaksinkertaistaa tätä lukua. Luku, johon päädyt, on luultavasti turvallinen luku jononopeudelle aluksi, ja se vastaa sitä, kuinka monta pyyntöä sekunnissa voit turvallisesti hallita; voit aina kasvattaa sitä, jos huomaat, että järjestelmät vastaavat loppukäyttäjien suorituskykyyn vielä tällä nopeudella.
Jos tilauksesi ovat aikaleimattuja, voit myös tarkastella suurinta tilausta, jonka olet ottanut yhden minuutin aikana viimeisen kuukauden aikana - mutta käytä sitä varoen, sillä et tiedä, kuinka monta tilausta olet saattanut pudottaa tämän minuutin aikana palvelimesi hidastumisen vuoksi, joten vähennä tästä 20 prosenttia.
Tämän artikkelin loppuosassa käsitellään muita tapoja laskea jononopeus.
On syytä huomauttaa, että "samanaikaisille käyttäjille" on ainakin kaksi määritelmää.
Käytämme määritelmää "transaktiovirtaan samaan aikaan osallistuvien ihmisten määrä ". Tämä on avainluku, joka sinun on tiedettävä jononopeuden asettamiseksi. Se on se, kuinka monta käyttäjää katsoo sivustoasi juuri nyt. Samanaikaisten istuntojen määrä on yleensä jonkin verran suurempi kuin samanaikaisten yhteyksien tai samanaikaisten käyttäjien määrä, koska osa istunnoista on ajoittumassa, mikä lisää istunnon keskimääräistä kestoa.
Vastakohtana tälle on Concurrent Requests (samanaikaisten pyyntöjen määrä), joka on verkkopalvelimen kerrallaan käsittelemien HTTP-pyyntöjen määrä. On hyvin hämmentävää, että monet tekniikan alan ihmiset tarkoittavat "kuinka monta samanaikaista pyyntöä", kun he sanovat "kuinka monta samanaikaista käyttäjää".
Sitten on vielä Concurrent Connections (tai samanaikaiset TCP-yhteydet samaan palvelinporttiin verkkokortillasi), joka on palvelinportissa tai taustapalvelussa kerrallaan avoinna olevien TCP/IP-socketien määrä. Sivupyyntöjä tehdessään selaimet jättävät yhteyden oletusarvoisesti auki siltä varalta, että sivulta tulee lisää pyyntöjä tai että käyttäjä siirtyy toiselle sivulle. Tämä vähentää uusien TCP/IP-yhteyksien avaamista koskevien pyyntöjen määrää sekunnissa, mikä tekee palvelinprosessista tehokkaamman. Näiden samanaikaisten yhteyksien aikakatkaisut vaihtelevat selaimittain 60 sekunnista aina siihen, että yhteys ei sulkeudu koskaan. Palvelimesi voi myös sulkea yhteydet automaattisesti sen jälkeen, kun niitä ei ole käytetty. Linux-verkkopalvelimissa voit laskea samanaikaisten yhteyksien määrän samaan palvelinporttiin tällä komennolla: netstat -aenp | grep ":80 \|:443 " | wc -l
jota voit kokeilla, jos olet utelias. Jotkut kutsuvat tätä myös "samanaikaisiksi käyttäjiksi", vaikka todellisuudessa se tarkoittaa samanaikaisia yhteyksiä.
Jos pyydät hosting-palveluntarjoajaa kertomaan verkkopalvelimesi käsittelemien yhtäaikaisten käyttäjien enimmäismäärän (kuinka paljon huippuliikennettä), hän luultavasti antaa sinulle luvun yhtäaikaisista istunnoista, yhtäaikaisista pyynnöistä tai yhtäaikaisista yhteyksistä siitä yksinkertaisesta syystä, että hän ei tiedä keskimääräistä tapahtuma-aikaasi, tapahtumavirran sivujen lukumäärää tai muita tietoja, joiden avulla hän voisi kertoa, kuinka monta yhtäaikaista käyttäjää verkkopalvelimesi käsittelee. Kaikilla näillä luvuilla on eri arvot.
Jos kysyt hosting-palveluntarjoajaltasi tai tekniseltä tiimiltäsi tietoja enimmäisliikennemääristä, on erittäin tärkeää, että selvität, tarkoittavatko he yhtäaikaisia käyttäjiä, yhtäaikaisia istuntoja, yhtäaikaisia pyyntöjä vai yhtäaikaisia yhteyksiä.
Tässä on syy. Jokainen sivu on yksi HTTP-pyyntö, mutta kaikki kuvat, skriptit ja muut tiedostot, jotka tulevat verkkosovelluksestasi ja joita selain käyttää sivun näyttämiseen, ovat myös HTTP-pyyntöjä.
Kuvitellaan, että tekninen tiimi on kertonut sinulle, että palvelin tukee 500 samanaikaista käyttäjää, mutta he tarkoittavatkin 500 samanaikaista pyyntöä. Käytät edellä esitettyä kaavaa ja oletat, että sivustosi voi tukea 100 kävijää minuutissa, kun tapahtuma-aika on 5 minuuttia.
Voiko se? Ei.
Kun ihmiset kulkevat tapahtumavirran läpi, he tekevät palvelimillesi pyyntöjä vain kunkin sivun latautuessa. Tämä vaikuttaa siihen, kuinka paljon liikennettä sekunnissa tai aktiivisia käyttäjiä palvelimesi pystyy käsittelemään. Viiden minuutin transaktioajasta se on vain muutama sekunti keskivertokäyttäjälle. Saatat siis ajatella, että 500 samanaikaista pyyntöä tarkoittaa, että voit käsitellä paljon enemmän samanaikaisia käyttäjiä, mutta saatat olla väärässä. Ymmärrätkö nyt, kuinka monimutkaista on ymmärtää verkkosivustosi kapasiteetti sen mukaan, kuinka paljon liikennettä tai aktiivisten käyttäjien kokonaismäärä on?
Jotta voit laskea samanaikaisten käyttäjien enimmäismäärän samanaikaisten pyyntöjen enimmäismäärästä, sinun on myös tiedettävä seuraavat tiedot
Tiedät varmaan jo 1) ja 2) - esimerkissämme se on 6 sivua ja 5 minuuttia. Voit helposti laskea sivut, jotka näet tapahtuman aikana. Jos et tiedä keskimääräistä tapahtuma-aikaa, Google Analytics voi kertoa sen, tai voit tarkistaa verkkopalvelimen lokitiedot.
Firefox-selain voi auttaa 3) ja 4) kohdissa. Napsauta sivustosi sivua hiiren kakkospainikkeella, valitse Inspect Element (Tarkista elementti) ja Network (Verkko) -välilehti. Paina sitten CTRL-SHIFT-R päivittääksesi sivun kokonaan. Näet verkon latausajat jokaisen sivun elementin osalta luettelossa. Haluat varmistaa, että näet siirtokoot Siirretty-sarakkeessa, sillä muuten tiedostoja saatetaan tarjoilla välimuistista, mikä voi sotkea laskelmasi. Saatat nähdä, että jotkin skriptit ja muut resurssit tulevat muilta palvelimilta kuin sivustoltasi, joten voit kirjoittaa sivustosi verkkotunnuksen vasemmalla olevaan suodatinruutuun. Jos haluat nähdä Duration-sarakkeen, napsauta hiiren oikealla painikkeella mitä tahansa sarakeotsikkoa ja valitse ponnahdusvalikosta Timings -> Duration. Näytön pitäisi näyttää tältä:
Tämän sivun Firefox-verkkovälilehti, joka näyttää pyynnön keston ja määrän osoitteesta queue-fair.com tulleista pyynnöistä.
Sivujesi näyttämisessä käytettävät tiedostot voivat olla peräisin useilta eri sivustoilta, joten haluat myös käyttää vasemmassa yläkulmassa olevaa suodatinta näyttämään vain oman sivustosi tiedostot - mutta vain, jos olet varma , että muiden sivustojen tiedostot eivät ole syynä hitaaseen sivulataukseen tai osa pullonkaulaa.
Firefox laskee pyynnöt näytön vasemmassa alareunassa ja näyttää 36 HTTP-pyyntöä vain tälle yhdelle sivulle.
Sinun on tehtävä tämä jokaiselle sivulle tapahtumavirrassasi - laske kokonaismäärä ja jaa se sivujen lukumäärällä löytääksesi HTTP-pyyntöjen keskimääräisen lukumäärän jokaiselle sivulle, numero 3) luettelossamme. Voit nyt nähdä, miksi kunkin HTML-sivun lapsipyyntöjen määrä on keskeinen tekijä sen kannalta, kuinka paljon liikennettä verkkopalvelimesi pystyy käsittelemään.
Numeron 4) kohdalla sinun on tarkasteltava Duration-saraketta ja löydettävä kaikkien sivujesi kaikkien HTTP-pyyntöjen keskiarvo. Jos et ole varma, oleta puoli sekuntia - tähän liittyy joka tapauksessa paljon epävarmuutta (ks. jäljempänä).
Annetaanpa muutamia esimerkkilukuja. Olemme jo sanoneet, että esimerkkipalvelimen prosessivirrassa on kuusi dynaamista sivua, mikä on 1), ja että keskimääräinen tapahtuma-aika on viisi minuuttia, mikä on 2). Oletetaan, että sivua kohden on 36 HTTP-pyyntöä, mikä vastaa 3), ja että palvelimen käsittelyaika on puoli sekuntia kutakin HTTP-pyyntöä kohden, mikä vastaa 4).
Näillä luvuilla palvelin, joka pystyy käsittelemään 500 samanaikaista pyyntöä, pystyy käsittelemään 500 / (0,5 sekuntia) = 1000 HTTP-pyyntöä sekunnissa, mikä on 60 000 HTTP-pyyntöä minuutissa, kun se on täysin kuormitettu.
Viiden minuutin tapahtuma-aikana se voi käsitellä 5 * 60 000 = 300 000 HTTP-pyyntöä. Kuulostaa paljolta, eikö?
Jokaista kävijää kohden on kuitenkin kuusi sivua, joilla kullakin on keskimäärin 36 HTTP-pyyntöä, eli 6 * 36 = 216 pyyntöä.
Joten 300 000 HTTP-pyynnön kapasiteetti voi teoriassa käsitellä 300 000 / 216 = 1 389 samanaikaista käyttäjää.
Hei, se on hienoa! Luulimme, että jonotusnopeus voisi olla vain 100, mutta 1389 / 5 minuuttia = 278 kävijää minuutissa, joten voimme saada korkeamman jonotusnopeuden!
No, luultavasti ei. Kävijäsi eivät esimerkiksi lähetä pyyntöjä tasan puolen sekunnin välein, kuten edellä esitetyssä laskelmassa oletetaan. Vielä tärkeämpää on se, että olet mitannut syötetyt tiedot silloin, kun sivusto ei ole kiireinen. Roskaa sisään, roskaa ulos.
Kun sivusto on kiireinen, palvelimella kestää kauemmin käsitellä pyyntöjä - olet varmasti huomannut tämän muilla sivustoilla, kun sivuilla on kiire, ja olet odottanut sivuja kauemmin. Tämä pidentää palvelimen keskimääräistä aikaa yhden HTTP-pyynnön käsittelyyn (4), mikä pienentää maksimiläpimenoa. Ota siis 278 kävijää minuutissa ja puolita se. Puolita se sitten uudelleen. Todennäköisesti realistisesti katsottuna sinulla on noin 70 uutta kävijää minuutissa maksimikuormituksella.
Muita sekoittavia tekijöitä ovat välimuistitallennus, joka tarkoittaa, että kävijöiden selaimen ei välttämättä tarvitse tehdä jokaista yksittäistä pyyntöä jokaista sivua varten - tämä tarkoittaa yleensä sitä, että palvelin tarvitsee vähemmän resursseja ja voi lisätä uusien kävijöiden määrää minuutissa, jonka palvelin pystyy käsittelemään. Kuormantasaajat, jotka jakavat kuormaa useille palvelimille, ja staattisen sisällön tarjoaminen dynaamisten sivujen sijaan voivat myös nopeuttaa palvelinprosessia, koska kukin palvelin tarvitsee vähemmän resursseja.
Tulet myös huomaamaan, että kaikki sivut eivät vie yhtä paljon aikaa, sillä joidenkin sivujen tuottaminen ja tarjoilu vaatii vähemmän resursseja kuin toisten. Tietokantahaut, hakukyselyt ja päivitykset vievät pisimpään aikaa, joten jossain kohtaa prosessia on pullonkaula, jossa ihmiset kasaantuvat odottamaan luottokorttitietojen käsittelyä ja tilausten tallentamista tai odottamaan saatavuuden tarkistamista. Jokaisessa tapahtumavirrassa on hitain vaihe, joten jossakin on aina pullonkaula, ja kysymykseen, kuinka monta yhtäaikaista käyttäjää verkkopalvelin voi käsitellä, on aina olemassa enimmäisarvovastaus - ja rajoituksia voi olla useita. Tällöin haluat asettaa jononopeuden riittävän alhaiseksi, jotta palvelimellasi on prosessiaikakapasiteettia käsitellä tarpeeksi monta yhtäaikaista käyttäjää prosessin hitaimmassa vaiheessa, jotta ihmiset eivät kasaannu sinne. Muuten verkkopalvelimesi voi kirjaimellisesti pysähtyä.
Kokemuksemme mukaan kaikki yliarvioivat ensimmäiseen myyntiin lähtiessään palvelimiensa kyvyn selviytyä suuresta liikennemäärästä.
Kaikki.
Istunnon keskimääräisen keston ja loppukäyttäjän suorituskyvyn tarkka määrittäminen hitaan tai ruuhkahuipun aikana ei ole heikkohermoisille. Parasta on suorittaa kunnollinen kuormitustesti, jossa "väärennetyt" asiakkaat todella käyvät läpi tilausprosessin kuormitustestauksen aikana aivan kuten oikeassa elämässä, tekemällä samat HTTP-pyynnöt samassa järjestyksessä ja samoilla odotusajoilla sivujen välillä kuormitustestauksen aikana kuin oikeassa elämässä, ja pitää silmällä prosessorikuormitusta, IO-läpimenoa ja vasteaikoja virtuaalisten kävijöiden määrän kasvaessa. Voit käyttää tähän Apache JMeteriä (pidämme myös K6:sta kevyempiä kuormia tai hitaampia koneita varten), mutta olipa käyttämäsi työkalu mikä tahansa, on aikaa vievää ja hankalaa jäljitellä jokaisen yksittäisen käyttäjän käyttäytymistä täsmälleen oikealla tavalla (erityisesti välimuistitallennuksen monimutkaisuuden vuoksi). Silloinkin kannattaa ottaa maksimilukusi ja puolittaa se.
Jos näin ei ole, kannattaa olla varovainen.
Voit helposti muuttaa minkä tahansa Queue-Fair-jonon jononopeutta milloin tahansa Queue-Fair-portaalin avulla. Aloita 10 kävijällä minuutissa tai tapahtumamäärälläsi tavallisempana päivänä, katso, miten se toimii hetken aikaa lippujen myynnin alkamisen jälkeen, ja jos kaikki näyttää hyvältä, prosessorikuormitus on alhainen, sql-tietokantasi on kunnossa ja (ennen kaikkea) sivusi reagoivat, kun painat CTRL-SHIFT-R-näppäintä, nosta sitä enintään 20 prosenttia, odota hetki ja toista. Löydät pian todellisen nopeuden, jota tarvitset tämän "kuorman tasapainottamisen" aikana (näetkö, mitä teimme?), ja muista, että asiakaskokemuksen kannalta jononopeuden nostaminen on hyvä asia, koska se vähentää jonossa olevien asiakkaiden arvioituja odotusaikoja, ja kaikki ovat tyytyväisiä, kun vastausaika on lyhyempi arvioidun odotuksen ansiosta.
Haluat välttää asettamasta jononopeutta liian korkeaksi ja joutua sitten tilanteeseen, jossa sinun on laskettava sitä, koska tämä a) tarkoittaa, että sivuston käyttäjät kokevat sivujen latautumisen hitaaksi ja b) aiheuttaa arvioitujen odotusajankohtien kasvamisen. Kaikki jonossa olevat ihmiset huokaisevat!
Muista, että tilausprosessissasi on pullonkaula jossain vaiheessa - jokaisessa tapahtumassa on hitain vaihe - ja sinne kasautuu useita istuntoja. Et halua, että lipunmyynnissä on minuutti aikaa, huomaat, että palvelimen prosessorikuorma on reilusti alle maksimiluvun, ja nostat nopeutta. Kävijäsi eivät luultavasti ole päässeet "Osta nyt" -painikkeeseen asti. Haluat odottaa, kunnes sql-tietokantasi raportoi uusia tilauksia samalla tai samankaltaisella nopeudella kuin jonotusnopeutesi, ja tehdä mittaukset ja reagointikykytestit silloin. Muista, että aina kun nostat nopeutta, ylimääräisten kävijöiden saapuminen pullonkaulaan kestää saman verran, joten et voi arvioida tarkasti, miten palvelimesi toimii uudella nopeudella, ennen kuin tämä aika on kulunut.
Olemme jo keskustelleet siitä, että jononopeutta kannattaa lisätä asteittain, kun jono on avattu. Olet luultavasti tietoinen siitä, että palvelimillasi on raja, jota ei voi ylittää ilman järjestelmän kaatumista, ja saatat jopa olla tietoinen siitä, mikä tämä raja on - mutta et ehkä tiedä, että kun kuormitus lähestyy tätä rajaa, siitä on yleensä hyvin vähän merkkejä - usein vain muutamia virheitä tai varoituksia tai prosessorin kuormitus on yli 80 prosenttia.
Kun verkkopalvelut epäonnistuvat, ne yleensä "napsahtavat" tai katkeavat hyvin nopeasti. Tämä johtuu yleensä siitä, että kun järjestelmä ei enää pysty käsittelemään pyyntöjä yhtä nopeasti kuin ne tulevat, sisäiset käsittelyjonot kasaantuvat. Järjestelmän on tällöin tehtävä työtä sisäisten jonojensa ja pyyntöjen käsittelyn, hallinnan ja tallentamisen eteen, ja tämä on se, mikä kaataa palvelimet yli laidan. Hyvin nopeasti. Kun näin tapahtuu, palvelimesi voivat ehkä jonkin aikaa vastata virhesivulla, mutta se ei auta sinua, koska sen näkevät kävijät painavat välittömästi Päivitä, mikä lisää kuormitusta.
Jos kävijöillä kestää yli sekunnin nähdä sivusi, he painavat Päivitä. Kun kävijä painaa päivitä, verkkopalvelimesi ei tiedä, että kävijä ei enää odota vastausta alkuperäiseen pyyntöön. Jos sekä alkuperäinen että päivityspyyntö vastaanotetaan, verkkopalvelimesi käsittelee molemmat. Tämä tarkoittaa enemmän työtä verkkopalvelimelle, vielä hitaampia vastauksia kaikille kävijöille ja sitä, että yhä useampi kävijä käyttää päivityspyyntöä, mikä johtaa noidankehään, joka pysäyttää verkkopalvelimesi ennen kuin se edes alkaa lähettää virhevastauksia.
Älä siis painosta palvelimiasi enempää kuin on tarpeen. Viimeisen 20 prosentin prosessorikapasiteetin tavoittelu ei yleensä ole riskin arvoista. Jos Queue-Fair-portaalissa näkyvä jonon koko (keltainen odotusluku ja -viiva kaavioissa) pienenee tai jopa vain kasvaa hitaammin minuutti minuutilta ja näytetty odotusaika on 50 minuuttia tai vähemmän, käsittelet tilauksia riittävän nopeasti, jolloin jono tyhjenee lopulta ja lakkaa näyttämästä jonosivuja automaattisesti ilman, että sinun tarvitsee tehdä mitään, ja ilman, että sinun tarvitsee kertoa pomollesi, että painostit palvelinta liian kovaa ja rikoit sen. Pääset siihen lopulta niin kauan kuin jonon etuosan nopeus on suurempi kuin liittymisten määrä minuutissa (molemmat näkyvät Queue-Fair-portaalissa) - käännekohta on yleensä vähintään muutaman minuutin kuluttua kustakin tapahtumasta. Jos myyt rajoitetun määrän tuotetta, se todennäköisesti myydään loppuun ennen käännekohdan saavuttamista.
Hyvä uutinen on se, että jos asetat jononopeuden vahingossa liian korkeaksi ja palvelimesi katkeavat, Queue-Fair voi auttaa sinua pääsemään nopeasti takaisin toimintaan - aseta jono vain pitoon, kunnes palvelimesi ovat taas valmiita käsittelemään kävijöitä. Hold-tilassa jonossa olevat ihmiset näkevät erityisen Hold-sivun, jonka voit suunnitella ennen verkkotapahtumaa. Ketään ei päästetä jonon etuosasta läpi, kun se on pidossa, mutta uudet internetkävijät voivat silti liittyä jonon takaosaan, ja heidät voidaan asettaa reilusti jonoon, kun tukos on poistunut, mikä tapahtuu hyvin nopeasti, koska Queue-Fair suojaa sivustoasi kysynnältä. Pidä-sivu on parempi käyttökokemus kuin jononopeuden asettaminen todella alhaiseksi, varsinkin jos päivität sen kertomaan kävijöille, mihin aikaan odotat jonon avautuvan uudelleen, mikä on helppo tehdä portaalisivun editorilla, vaikka satoja tuhansia ihmisiä olisi jo jonossa - ja Pidä-tilassa voit jopa päästää heidät läpi yksi kerrallaan Queue-Fair:n ainutlaatuisella Päästä yksi -painikkeella, jos sinun on tarpeen, sillä aikaa kun järjestelmäsi toipuu katkoksesta.
Jos palvelimesi siis joutuvat pitämään taukoa tapahtuman aikana, Hold-sivu on juuri se, mitä tarvitset, ja se auttaa palvelimiasi toipumaan nopeammin.
Tässä artikkelissa olemme selittäneet, miksi nopeuteen perustuva jono on aina oikea tapa edetä, ja antaneet kaksi tapaa laskea tarvitsemasi nopeus, mutta ellet ole tehnyt täydellistä ja tarkkaa virtuaalista kävijäkuormitustestausta koko tapahtumavirrallesi ja olet todella erittäin erittäin mega varma siitä, neuvomme on aina sama:
Jos myyt rajoitetun määrän tuotetta, sinun ei tarvitse kiinnittää huomiota myöskään vaiheeseen 7.
Tämä koskee ensimmäistä jonoa, kun et tiedä, kuinka suurta jononopeutta järjestelmäsi voi tukea. Kun olet mitannut järjestelmän todellisuudessa käsittelemän jononopeuden, voit käyttää samaa lukua myöhemmissä jonoissa - mutta vain, jos mikään ei ole muuttunut järjestelmässäsi. Käytännössä järjestelmääsi todennäköisesti kehitetään ja muutetaan jatkuvasti, etkä ehkä tiedä, miten viimeaikaiset muutokset ovat vaikuttaneet maksimivaiheen jononopeuteen - miksi et siis aloittaisi puolet edellisestä mitatusta luvusta ja toista edellä kuvattua prosessia?
Näin käytät Queue-Fair:ta, jotta myyntisi olisi mukavaa ja turvallista, ja muista, että on aina parempi olla varma kuin katua.
2024 The Fair Queue People Ltd. - Kaikki oikeudet pidätetään.
Osa Orderly-jonoratkaisuperhettä - OrderlyQ - OrderlyStats - WeQ4U
