Miten online-jonomme käyttö estää sivuston kaatumisen ja verkkosivuston kaatumisen - kuinka monta samanaikaista käyttäjää verkkopalvelin voi käsitellä?

Miksi käyttää hintaan perustuvaa virtuaalista odotushuonetta?

Hinnoitteluperusteinen vai yksi ulos, yksi sisään? Punnitsemme etuja ja haittoja.

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.



G2:n korkeimmalle arvioitu virtuaalinen odotushuone

Mitä asiakkaamme sanovat Queue-Fair:sta?


kuormitus testaus http-pyyntöjä kuinka monta pyyntöä web-palvelin hanle ilman ylimääräisiä palvelimen resursseja

Kuinka monta yhtäaikaista käyttäjää verkkopalvelin voi käsitellä?

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

Kuinka tarkka on nopeuteen perustuva jonotusjärjestelmä?

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

käyttöjärjestelmän enimmäislukumäärä web-palvelimen resursseja
samanaikaisten käyttäjien keskimääräisen luvun laskeminen luottamusväliä käyttäen

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!


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

Helppo tapa laskea jononopeus

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.

aktiivisten käyttäjien enimmäismäärän laskeminen verkkosovellukselle

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.

sekaannus samanaikaisista käyttäjistä, samanaikaisista yhteyksistä, samanaikaisista istunnoista ja istunnon keskimääräisestä kestosta.

Gotcha #1: Samanaikaiset käyttäjät vs samanaikaiset pyynnöt vs samanaikaiset yhteydet vs samanaikaiset istunnot

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ämän väärin tekeminen voi kaataa sivustosi!

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?

turva ensin palvelimen resursseja, kun selvitetään, kuinka monta pyyntöä verkkosivut voivat saada, jotta jokainen käyttäjä saa hyvän kokemuksen.

Samanaikaisten pyyntöjen muuntaminen samanaikaisiksi käyttäjiksi

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

  1. Sivujen lukumäärä tapahtumavirrassa
  2. Kävijän keskimääräinen tapahtuma-aika ensimmäiseltä sivulta viimeiselle sivulle virtauksessasi.
  3. Kuinka monta pyyntöä kukin sivu keskimäärin sisältää?
  4. Keskimääräinen aika, jonka palvelimesi tarvitsee yhden HTTP-pyynnön käsittelyyn.

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

google käsittelee oikein konfiguroitu nginx google analytics kuvan lataamiseen

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

laskea, kuinka monta istuntoa samanaikaisesti, kuinka monta käyttäjää ja kuinka monta pyyntöä sekunnissa web-sovelluksellasi on, olipa kyseessä yksittäinen palvelin tai staattinen sisältö.

Laskutoimitukset

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

Gotcha #2: Verkkopalvelimet hidastuvat kuormituksen myötä

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.

mitä suurempi kuormitus liikennevirroista aiheutuu, sitä hitaammiksi koneet muuttuvat.

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

epävarma siitä, miten arvioida palvelimien kapasiteettia palvelinresursseja jokaiselle käyttäjälle.

Mitä minä sitten teen?

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 saada jäljiteltyä 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 sujuu jonkin 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, kaksinkertaista se, 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 on hyvä nostaa jononopeutta, koska tämä vähentää jonossa olevien asiakkaiden arvioituja odotusaikoja, ja kaikki ovat tyytyväisiä, kun vastausaika tuottaa lyhyemmän arvioidun odotuksen.

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!

Gotcha #3: Nopeuden nostaminen liian nopeasti jonon avaamisen jälkeen

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.

hidastaa palvelimen resurssien käyttöä koskevan päätöksen tekemistä
palvelimet napsahtavat, kun palvelimien kapasiteetti ylittyy

Gotcha #4: Palvelinten napsauttaminen

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.

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

Päätelmä

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:

  1. Aloita asettamalla Queue Rate -arvoksi 10 tai tavallisemman päivän tapahtumamääräsi.
  2. Tarkkaile prosessorin kuormitusta ja muita suorituskykyindikaattoreita.
  3. Odota, kunnes uusia tilauksia kirjataan sql-tietokantaan samalla tai vastaavalla nopeudella kuin jononopeus.
  4. Paina CTRL-SHIFT-R-näppäintä sivuillasi tarkistaaksesi responsiivisuuden.
  5. Nosta jononopeutta enintään 20 %.
  6. Palaa vaiheeseen 2 ja odota uudelleen.
  7. Kun jonon koko pienenee tai kasvaa tasaisesti ja vähemmän nopeasti joka minuutti, ja odotusaika on alle 50 minuuttia, sen ei tarvitse enää nopeutua.
  8. Istu alas ja rentoudu! Queue-Fair:lla on sinut turvassa.

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?

Muista, että on aina parempi olla varma kuin katua.


Sadat johtavat organisaatiot luottavat
jonoratkaisuihimme

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

Yksinkertainen ratkaisu internet-liikenteen vyöryihin

Aloita