Kuidas meie veebijärjekorra kasutamine hoiab ära saidi ja veebisaidi kokkuvarisemise - kui palju samaaegseid kasutajaid suudab veebiserver käsitleda?

Miks kasutada hinnapõhist virtuaalset ooteruumi?

Määrapõhine või üks välja, üks sisse? Me kaalume plusse ja miinuseid.

Me ei leidnud tegelikult ühtegi plussi, et üks välja, üks sisse. Lühidalt öeldes seisneb selle lähenemisviisi probleem selles, et kui kasutajad on e-kaubanduse veebisaitide külastajad, ei tea veebiserver, mitu samaaegset kasutajat tal igal ajahetkel on. See on showstopper. Siin on põhjus.

Hiljem selles artiklis räägime ka sellest, kuidas kasutada oma saidi kaitsmiseks ka määrapõhist virtuaalset ruumi.



G2 kõrgeima hindega virtuaalne ooteruum
G2 on maailma enim külastatud SaaSi ülevaatuste veebisait, kus meil on täiuslik 5,0 / 5 tärni hinne.

Mida meie kliendid ütlevad Queue-Fair kohta


koormuse testimine http taotlused kui palju taotlusi veebiserver hanle ilma täiendavate serveriressursside

Mitu samaaegset kasutajat suudab veebiserver käsitleda?

Kui te teate, kui palju samaaegseid kasutajaid veebiserver töötleb ja kui pikk on tehingu keskmine kestus või külastuse kestus alates tehinguvoo esimesest leheküljest kuni tellimuse kinnitamise leheküljeni, saate selle teisendada Queue Rate'iks, kasutades Little'i seadust, jagades kasutajate arvu kestusega, näiteks nii:

Ootejärjekorra kiirus = samaaegsed kasutajad / tehingu aeg

Kui täpne on kiirusel põhinev järjekorrasüsteem?

Queue-Fair toimetab külastajad teie veebisaidile teie poolt määratud kiirusega - meil on kaugelt kõige täpsem järjekorra AI, mis tagab, et soovitud külastajate arv iga minut on see, mida te iga minut saate, võttes automaatselt arvesse inimesi, kes ei ole kohal, kui nende kord on kutsutud, samuti inimesi, kes tulevad tagasi hilinemisega.

Kuidas see väljendub samaaegsete kasutajate arvus? Loomulikult ei võta iga külastaja, kes teie saidile jõuab, täpselt sama palju aega, et oma tehing lõpule viia, kuid suurte arvude seaduse tõttu saate Queue-Fair abil väga püsiva arvu samaaegseid kasutajaid.

Oletame näiteks, et teie järjekorra määr on 100 külastajat minutis. Me saadame teie saidile 100 külastajat iga minut ühtlase vooguna - see on see, mida me teeme, ja me oleme selles hämmastavalt head. Ütleme ka, et inimesed kasutavad teie veebisaiti keskmiselt (keskmiselt) viis minutit, kusjuures 70% neist kulub 4 kuni 6 minutit alates hetkest, mil nad järjekorrast mööduvad, kuni hetkeni, mil nad teevad oma viimase lehepäringu (olenemata sellest, kas nad viivad tehingu lõpule või mitte). See tähendab, et standardhälve on üks minut mõlemal pool keskmisest. Statistiliselt tähendab see, et iga külastaja kohta, kellel kulub viis ja pool minutit, leidub teine, kellel kulub neli ja pool minutit, ning need erinevused üksikute külastuste kestuses mitme seansi lõikes kipuvad seega üksteist neutraliseerima, kui te loete palju neid kuidagi. Suurte arvude seadus ütleb, et see tühistamine muutub seda täpsemaks, mida suurem on kaasatud inimeste arv.

operatsioonisüsteemi maksimaalne arv veebiserveri ressursse
üheaegsete kasutajate keskmise näitaja arvutamine koos usaldusvahemikuga

Kui täpselt? Me saame selle välja töötada väikese statistika abil. Valimi suurus on 5 * 100 = 500, mis on siinkohal suur arv. Nii palju inimesi te loete. See tähendab, et tehingu aja keskväärtuse standardviga on 1 (standardhälve, 1 minut) jagatud valimi suuruse ruutjuurega (seega 500 ruutjuurega) vastavalt keskväärtuse standardvea statistilisele valemile, mis annab tehingu aja keskväärtuse standardveaks 0,044 minutit ehk kõigest 2,7 sekundit, mis on vähem kui üks protsent.

See tähendab, et kui järjekorra määr on 100 ja tehingu aeg on 5 minutit pluss või miinus minut iga üksiku külastaja kohta, siis peaksite ootama 495-505 samaaegset kasutajat teie saidil umbes 70% ajast, nii et matemaatika ütleb, et kiirusel põhineva järjekorra kasutamine tagab teie veebiserveritele soovitud väga püsiva koormuse.

Aga kas matemaatika on täpne? Siin on mõningaid nüansse - näiteks ei ole valimi suurus, mida me rõõmsalt ruudustame, iga kord, kui samaaegseid kasutajaid loendatakse (st igal ajahetkel), alati täpselt 500, ja ka normaalne (Gaussi) jaotus võib anda negatiivseid tehinguaegu, mida tegelikus elus ei esine. Niisiis, me kasutame külastajate kaupa, sekundi kaupa simulaatorit, et teha mõõtmisi selliste arvutuste kontrollimiseks, ja see ütleb meile, et ülaltoodud arvude puhul peaksite 70% ajast ootama 493-507 külastajat, nii et matemaatika peab märkimisväärselt hästi paika! Andmete mõõtmine ütleb meile ka, et teie saidil on vähemalt 95% ajast 500 ± 15 samaaegset kasutajat.

See on tõenäoliselt stabiilsem kui täpsus, millega teie veebiserver suudab mõõta teie veebilehe kasutajate arvu! Veelgi parem on see, et isegi kui te ei tea, milline on teie külastajate keskmine tehinguaeg või standardhälve, on need matemaatilised suurused olemas, olenemata sellest, kas te teate neid või mitte, ja te saate niikuinii stabiilse koormuse.

Tulemuseks on see, et Queue-Fair annab soovitud külastajate arvu minutis peaaegu täiusliku täpsusega, mille tulemuseks on väga stabiilne samaaegsete kasutajate arv teie saidil ja stabiilne veebiserveri koormus, mille üle teil on täielik kontroll.

Hurraa!


servers capacity can be exceeced with inaccurate queues Ja nüüd hoiatus. Tasub märkida, et samaaegsete kasutajate arvu stabiilsus teie saidil - ja seega teie serveri koormuse stabiilsus - sõltub kriitiliselt sellest, kui täpselt teie virtuaalse ooteruumi teenusepakkuja saadab teile iga minut soovitud külastajate arvu, ja seetõttu on see võtmetegur virtuaalse ooteruumi platvormi valimisel. Kuna me pakume kõige täpsemat Virtual Waiting Room'i maailmas, ei peata keegi teie serverite üleujutusi paremini kui Queue-Fair.

Lihtne viis järjekorra määra arvutamiseks

Mis siis, kui te ei tea, kui palju samaaegseid kasutajaid server suudab käsitleda või kui palju tehinguaega? Võite vaadata lehte, mis tõenäoliselt on teie kitsaskoht - tavaliselt see, mis on "Osta kohe" nupule klõpsamise tulemus. Kasutage Google Analyticsit, et leida selle lehe igakuised unikaalsed külastajad või loendage oma igakuiseid tellimusi. Jagage see 30 * 24 * 60 = 43 200, mis on minutite arv kuus (ligikaudu). See on teie keskmine külastajate arv minutis kogu kuu jooksul. Korrutage see kolmega. See on teie keskmine külastajate arv minutis tööajal (ligikaudu). Tihendage see kahekordseks. See on tõenäoliselt turvaline arv, mida saab kasutada järjekorra määrana.

Oletame näiteks, et te töötlete 100 000 tellimust kuus - see tähendab 100 000 "Osta kohe" nupu klikke. See on 100 000 / 43 200 = 2,31 tellimust minutis. Eeldate, et enamik neist tellimustest tehakse päeval ja teie serverid on öösel vaiksemad, seega korrutage see 3 ja see on 7 tellimust minutis, mis on ligikaudne hinnang, kui hõivatud on teie server tööajal. Kui saadud arv on väiksem kui 50: nõudluses on tippude ja madalseisude aeg, nii et kui teie server ei ole tipptundidel märgatavalt aeglane, korrutage see 2ga, et saada 14 aktiivset kasutajat minutis. Kui arv on suurem kui 50: minutiliste tippude ja madalseisude arv on võrreldes sellega väiksem ja selle kahekordistamine ei ole ohutu. See arv, millele te lõpuks jõuate, on tõenäoliselt ohutu arv Queue Rate'i jaoks, millega alustada, ja vastab sellele, kui palju päringuid sekundis saate ohutult hallata; te võite seda alati suurendada, kui leiate, et teie süsteemid reageerivad lõppkasutajate jõudlusele selle kiiruse juures veel hästi.

aktiivsete kasutajate maksimaalse taseme arvutamine teie veebirakenduse jaoks

Kui teie tellimused on ajatempliga, saate vaadata ka maksimaalset tellimuste arvu, mille olete viimase kuu jooksul ühe minuti jooksul võtnud - kuid kasutage seda ettevaatlikult, sest te ei tea, kui palju tellimusi te selle minuti jooksul olete serverite aeglustumise tõttu langenud, seega vähendage seda 20% võrra.

Selle artikli ülejäänud osas käsitletakse mõningaid muid viise, kuidas järjekorra kiirust välja arvutada.

segadus samaaegsete kasutajate samaaegsete ühenduste samaaegsete seansside ja keskmise seansi kestuse osas

Gotcha #1: Samaaegsed kasutajad vs Samaaegsed taotlused vs Samaaegsed ühendused vs Samaaegsed seansid

Väärib märkimist, et üldkasutuses on vähemalt kaks "samaaegsete kasutajate" määratlust.

Me kasutame määratlust "tehinguvoos osalevate inimeste arv igal ajal". See on võtmenumber, mida on vaja teada, et määrata järjekorra määr. See on see, kui palju kasutajaid vaatab teie saiti praegu. Samaaegsete seansside arv on tavaliselt mõnevõrra suurem kui samaaegsete ühenduste või samaaegsete kasutajate arv, sest osa seansse on ajastusprotsessis, mis suurendab seansi keskmist kestust.

Vastupidiselt sellele, kui palju on samaaegseid päringuid, mis on teie veebiserveri poolt korraga töödeldavate HTTP-päringute arv. Väga segadust tekitav on see, et paljud tehnikainimesed mõtlevad, kui nad ütlevad, mitu samaaegset taotlust, kui nad ütlevad, mitu samaaegset kasutajat.

Siis on veel Concurrent Connections (ehk samaaegsed TCP-ühendused samale serveripordile teie võrgukaardil), mis on teie serveripordil või backend-teenusel korraga avatud TCP/IP-sokkide arv. Lehekülje päringute tegemisel jätavad brauserid vaikimisi ühenduse avatuks, juhul kui lehe poolt tehakse täiendavaid päringuid või kui kasutaja läheb teisele lehele. See vähendab uute TCP/IP-ühenduste avamiseks tehtavate päringute arvu sekundis, muutes serveriprotsessi tõhusamaks. Nende samaaegsete ühenduste aegumistähtajad varieeruvad brauserite kaupa, alates 60 sekundist kuni mitte kunagi sulgemiseni. Teie server võib automaatselt sulgeda ühendusi ka pärast tegevusetuse perioodi. Linuxi veebiserverites saate selle käsuga teada, kui palju on samaaegseid ühendusi samale serveripordile:

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

mida võite proovida, kui olete uudishimulik. Jällegi, mõned inimesed nimetavad seda ka "Concurrent Users", kuigi tegelikult tähendab see samaaegseid ühendusi.

Tõepoolest, kui te palute oma veebimajutuse pakkujal öelda teile maksimaalset samaaegsete kasutajate arvu, mida teie veebiserver suudab käsitleda (kui palju tipptasemel liiklust), siis nad tõenäoliselt annavad teile tegelikult üheaegsete seansside, üheaegsete päringute või üheaegsete ühenduste arvu, sel lihtsal põhjusel, et nad ei tea teie keskmist tehingu aega, lehekülgede arvu teie tehinguvoos või muud teavet, mis võimaldaks neil öelda, kui palju üheaegseid kasutajaid teie veebiserver käsitleb. Kõigil neil numbritel on erinevad väärtused.

Kui küsite oma hostinguteenuse pakkujalt või tehnikameeskonnalt teavet maksimaalse liiklustaseme kohta, on ülimalt oluline, et te selgitaksite, kas nad mõtlevad samaaegseid kasutajaid, samaaegseid seansse, samaaegseid päringuid või samaaegseid ühendusi.

Selle valesti tegemine võib teie veebilehe kokku kukutada!

Siin on põhjus. Iga lehekülg on üks HTTP päring, kuid kõik teie veebirakendusest tulevad pildid, skriptid ja muud failid, mida brauser kasutab lehe kuvamiseks, on samuti HTTP päringud.

Kujutame ette, et teie tehniline meeskond on teile öelnud, et server toetab 500 samaaegset kasutajat, kuid tegelikult tähendab see 500 samaaegset päringut. Kasutades oma 5-minutilist tehinguaega, kasutate ülaltoodud valemit ja eeldate, et teie sait suudab toetada 100 külastajat minutis.

Kas see on võimalik? Ei.

Kui inimesed läbivad tehinguvoo, teevad nad tegelikult ainult päringuid teie serveritelt, kui iga lehekülg laetakse. See mõjutab seda, kui palju liiklust sekundis või aktiivseid kasutajaid teie server suudab käsitleda. Viie minuti pikkusest tehinguajast on see keskmise kasutaja jaoks vaid paar sekundit. Seetõttu võite arvata, et 500 samaaegset päringut tähendab, et saate käsitleda palju rohkem samaaegseid kasutajaid, kuid te võite eksida. Kas nüüd näete, kuidas teie veebisaidi läbilaskevõime mõistmine selles osas, kui palju liiklust või aktiivsete kasutajate koguarvu on nii keeruline asi?

turvalisus kõigepealt teie serveri ressursside jaoks, kui töötate välja, kui palju päringuid teie veebilehed võivad saada, et pakkuda igale kasutajale head kogemust.

Samaaegsete taotluste teisendamine samaaegseteks kasutajateks

Selleks, et arvutada oma maksimaalne samaaegsete kasutajate arv samaaegsete taotluste maksimaalsest koguarvust, peate samuti teadma järgmist

  1. Teie tehinguvoo lehekülgede arv
  2. Keskmine külastajate tehingu aeg esimesest leheküljest kuni viimase leheküljeni teie voogus
  3. Mitu taotlust moodustab iga lehekülg keskmiselt
  4. Keskmine aeg, mis teie serveril kulub ühe HTTP päringu töötlemiseks.

Ilmselt teate juba 1) ja 2) - meie näites on see 6 lehekülge ja 5 minutit. Te võite hõlpsasti lugeda lehekülgi, mida te näete tehingu tegemise ajal. Kui te ei tea keskmist tehinguaega, võib Google Analytics seda teile öelda või võite kontrollida oma veebiserveri logisid.

Punktide 3) ja 4) puhul aitab Firefoxi brauser. Tehke oma saidi lehel paremklõps, valige Inspect Element ja vahekaart Network. Seejärel vajutage CTRL-SHIFT-R, et lehekülge täielikult värskendada. Saate näha võrgu laadimisaega iga lehe elemendi kohta loetelus. Tahate veenduda, et näete ülekandesuurusi veerus Transferred, sest vastasel juhul võidakse faile serveerida vahemälust, mis võib teie arvutusi segi ajada. Te võite näha, et mõned skriptid ja muud ressursid pärinevad teistest serveritest kui teie sait, seega võite sisestada oma saidi domeeninime vasakul asuvasse filtrikasti. Et näha veeru Duration (kestus), klõpsake paremal nupul ükskõik millise veeru päises ja valige hüpikmenüüst Timings -> Duration (ajastus -> kestus). Teie ekraan peaks välja nägema selline:

google töötleb korralikult konfigureeritud nginx koos google analytics pildi üleslaadimiseks

Firefoxi võrgu vahekaart selle lehekülje jaoks, mis näitab päringute kestust ja arvu queue-fair.com'ist pärit päringute arvu.

Teie lehekülgede kuvamisel kasutatavad failid võivad pärineda mitmest erinevast saidist, seega soovite kasutada ka filtrit üleval vasakul, et näidata ainult teie saidi faile - kuid ainult siis, kui olete kindel , et need failid teistelt saitidelt ei ole aeglase lehe laadimise põhjus või osa teie kitsaskohast.

Firefox loeb taotlusi teie jaoks ekraani vasakus allosas ja näitab 36 HTTP-päringut ainult selle ühe leheküljekohta.

Te peate seda tegema iga lehekülje kohta oma tehinguvoos - loendage kokku ja jagage lehekülgede arvuga, et leida iga lehekülje keskmine HTTP päringute arv (number 3) meie nimekirjas. Nüüd näete, miks on iga HTML-lehe lastepäringute arv selline võtmetegur, mis määrab, kui palju liiklust teie veebiserver suudab töödelda.

Numbri 4) puhul peate vaatama veergu Duration (kestus) ja leidma kõigi teie lehekülgede kõigi HTTP-päringute keskmise. Kui te ei ole kindel, eeldage, et see on pool sekundit - selles on niikuinii palju ebakindlust (vt allpool).

arvutuste tegemine, et välja arvutada, mitu sessiooni korraga, mitu kasutajat ja mitu päringut sekundis teie veebirakenduses, olgu see siis üks server või staatiline sisu.

Matemaatika tegemine

Esitame mõned näited. Me ütlesime juba, et näidisserveri protsessivoolus on kuus dünaamilist lehekülge, mis on 1), ja et keskmine tehingu aeg on viis minutit, mis on 2). Oletame, et lehekülje kohta on 36 HTTP päringut, mis on 3), ja et iga HTTP päringu töötlemisaeg on pool sekundit, mis on 4).

Nende numbrite abil saab server, mis suudab käsitleda 500 samaaegset päringut, käsitleda 500 / (0,5 sekundit) = 1000 HTTP päringut sekundis, mis on 60 000 HTTP päringut minutis, kui see on täielikult ammendatud.

Viie minuti jooksul suudab see 5 * 60 000 = 300 000 HTTP-päringut töödelda. Tundub palju, eks?

Kuid iga külastaja kohta on kuus lehekülge, millest igaühel on keskmiselt 36 HTTP päringut, seega 6 * 36 = 216 päringut.

Seega, 300 000 HTTP taotluse maht võib teoreetiliselt käsitleda 300 000 / 216 = 1 389 samaaegset kasutajat.

Gotcha #2: Veebiserverid muutuvad koormusega aeglasemaks

Hei, see on suurepärane! Me arvasime, et meie järjekorra määr on ainult 100, kuid 1389 / 5 minutit = 278 külastajat minutis, nii et meil võib olla suurem järjekorra määr!

Tõenäoliselt mitte. Esiteks, teie külastajad ei saada päringuid täpselt poole sekundi tagant, nagu eespool esitatud arvutused eeldavad. Veelgi olulisem on see, et te olete mõõtnud oma sisendandmeid siis, kui sait ei ole hõivatud. Prügi sisse, prügi välja.

Kui sait on hõivatud, võtab serveril päringute töötlemine kauem aega - olete seda märganud ka teistel saitidel, kui asjad on hõivatud, et te ootate lehti kauem. See suurendab keskmist aega, mis serveril kulub ühe HTTP-päringu töötlemiseks (4), mis vähendab maksimaalset läbilaskevõimet. Seega võtke 278 külastajat minutis ja vähendage see poole võrra. Seejärel vähendage see uuesti poole võrra. Maksimaalse koormuse korral on teil tõenäoliselt reaalselt umbes 70 uut külastajat minutis.

mida suurem on koormus teie liiklussagedusest, seda aeglasemaks muutuvad masinad.

Muud segavad tegurid on vahemälu, mis tähendab, et teie külastajate brauserid ei pea tegema iga lehe kohta iga üksiku päringu - see tähendab, et server vajab vähem ressursse ja võib suurendada uute külastajate arvu minutis, millega teie server suudab toime tulla. Koormuse tasakaalustajad, mis jaotavad koormust mitme serveri vahel, ja staatilise sisu, mitte dünaamiliste lehekülgede serveerimine võivad samuti kiirendada teie serveriprotsessi, kuna iga server vajab vähem ressursse.

Samuti leiate, et kõik leheküljed ei võta sama kaua aega, sest mõnede tegemiseks ja serveerimiseks on vaja vähem ressursse kui teiste tegemiseks. Andmebaasiotsingud, otsingupäringud ja uuendused võtavad kõige kauem aega, nii et teie protsessis tekib kusagil kitsaskoht, kus inimesed kuhjuvad, oodates krediitkaardiandmete töötlemist ja tellimuste salvestamist või oodates, et kontrollitakse saadavust. Igal tehinguvoolul on kõige aeglasem samm, seega on alati kusagil kitsaskoht, ja alati on olemas maksimaalse väärtusega vastus küsimusele, kui paljude samaaegsete kasutajatega veebiserver hakkama saab - ja siin võib olla mitu piirangut. Sellisel juhul soovite seada oma Queue Rate'i piisavalt madalaks, et tagada, et teie serveril on cpu-aegne võimsus, et töödelda piisavalt palju inimesi samaaegselt teie protsessi kõige aeglasema sammu jaoks, nii et inimesed ei kuhjuks seal. Vastasel juhul võib teie veebiserver sõna otseses mõttes seisma jääda.

ebakindel, kuidas hinnata serverite võimsust serveri ressursse iga üksiku kasutaja jaoks

Mida ma siis teen?

Meie kogemus näitab, et esimese müügi puhul hindavad kõik üle oma serverite võimet tulla toime suure andmemahuga.

Kõik.

Keskmise sessiooni kestuse ja lõppkasutaja jõudluse täpne määramine aeglase või tippliikluse ajal ei ole nõrganärviliste jaoks. Kõige parem on teha korralik koormustest, kus "võltskliendid" läbivad koormustesti ajal tellimisprotsessi täpselt nii, nagu nad seda ka päriselus teeksid, tehes koormustesti ajal samu HTTP-päringuid samas järjekorras ja samade ooteaegadega lehekülgede vahel nagu päriselus, ning jälgige oma protsessori koormust, IO läbilaskevõimet ja vastamisaega, kui suurendate virtuaalsete külastajate arvu. Võite kasutada selleks Apache JMeterit (meile meeldib ka K6 kergemate koormuste või aeglasemate masinate puhul), kuid ükskõik, millist vahendit te kasutate, on aeganõudev ja keeruline jäljendada iga kasutaja käitumist täpselt õigel viisil (eriti seoses vahemälu kasutamise keerukusega). Isegi siis võtke oma maksimaalne arv ja vähendage seda poole võrra.

Selle puudumisel olge ettevaatlikumad.

Queue-Fair-portaali kaudu saate igal ajal hõlpsasti muuta Queue-Fair-järjekorra kiirust. Alustage 10 külastajaga minutis või oma tehingukiirusega tavalisemal päeval, vaadake, kuidas see läheb natuke aega pärast piletite müüki minekut, ja kui kõik tundub hea, teie protsessori koormus on madal, teie sql-andmebaas on korras ja (eelkõige) teie leheküljed reageerivad, kui vajutate CTRL-SHIFT-R, tõstke seda mitte rohkem kui 20 protsendi võrra, oodake natuke ja korrake. Selle "koormuse tasakaalustamise" (näete, mida me seal tegime?) käigus leiate peagi tegeliku määra, mida vajate, ja pidage meeles, et kliendikogemuse seisukohast on okei tõsta järjekorra määra, sest see põhjustab hinnangulise ooteaja vähenemist, mida teie kliendid järjekorras näevad, ja kõik on rahul, kui reageerimisaeg pakub lühemat hinnangulist ooteaega.

Mida te soovite vältida, on järjekorra määra liiga kõrgeks seadmine ja seejärel selle langetamine, sest see a) tähendab, et saidi kasutajatel on aeglane lehekülje laadimine ja b) põhjustab hinnanguliste ooteaegade suurenemist. Kõik teie järjekorras olevad inimesed ohkavad!

Gotcha #3: Kiiruse suurendamine liiga kiiresti pärast järjekorra avanemist

Pidage meeles, et kusagil teie tellimisprotsessis on kitsaskoht - igal tehingul on kõige aeglasem samm - ja sinna kuhjuvad mitu seanssi. Mida te ei taha teha, on see, et saate piletimüügiga minut aega, näete, et teie serveri protsessori koormus on tunduvalt alla selle maksimumarvu, ja tõstate kiirust. Teie külastajad ei ole tõenäoliselt jõudnud veel nupuni "Osta kohe". Te soovite oodata, kuni teie sql-andmebaas teatab uutest tellimustest sama või sarnase kiirusega kui teie järjekorra määr ja teha siis oma mõõtmised ja reageerimisvõime testid. Pidage meeles, et iga kord, kui te suurendate määra, kulub sama palju aega, et lisakülastajad jõuaksid teie kitsaskohani, nii et te ei saa täpselt hinnata, kuidas teie server uue määra juures toimib, enne kui see aeg on möödunud.

aeglustab otsuse tarbida serveri ressursse
serverite võimsuse ületamisel napsub serverite võimsuse ületamisel

Gotcha #4: Serverite klõpsamine

Me juba arutasime, kuidas on kõige parem suurendada järjekorra kiirust järk-järgult, kui järjekord on avatud. Tõenäoliselt olete teadlik, et teie serveritel on piir, mida ei saa ületada ilma süsteemi kokkuvarisemiseta, ja võib-olla olete isegi teadlik sellest, mis see piir on - kuid mida te ei pruugi teada, on see, et kui koormus läheneb sellele piirile, on tavaliselt väga vähe märke - sageli ainult mõned vead või hoiatused või protsessori koormus üle 80%.

Kui veebiteenused ebaõnnestuvad, kipuvad nad väga kiiresti "kokku vajuma" või katkema. Tavaliselt on see tingitud sellest, et kui teie süsteem ei suuda enam päringuid nii kiiresti töödelda, kui need laekuvad, tekivad sisemised järjekorrad. Seejärel peab teie süsteem tegema tööd nii oma sisemiste järjekordade kui ka päringute töötlemiseks, haldamiseks ja säilitamiseks ning see ongi see, mis serverid üle jõu käivitab. Väga kiiresti. Kui see juhtub, võivad teie serverid mõnda aega vastata vealehega, kuid see ei aita teid, sest külastajad, kes seda näevad, vajutavad kohe "Värskenda", mis suurendab koormust.

Isegi enne seda, kui külastajatel kulub rohkem kui umbes sekund, et teie lehekülge näha, vajutavad nad Refresh. Kui külastaja vajutab refresh, ei tea teie veebiserver, et külastaja ei oota enam vastust algsele päringule. Kui saabub nii algne kui ka värskenduspäring, töötleb teie veebiserver neid mõlemaid. See tähendab teie veebiserverile rohkem tööd, veelgi aeglasemaid vastuseid kõigile teie külastajatele ja rohkem inimesi, kes vajutavad värskendust, mille tulemuseks on nõiaring, mis krabab teie veebiserverit enne, kui see hakkab isegi vigade vastuseid saatma.

Nii et ärge suruge oma servereid rohkem kui vaja. Viimase 20% cpu ajamahutavuse poole püüdlemine ei ole tavaliselt riski väärt. Kui Queue-Fair-portaalis näidatud järjekorra suurus (kollane ooteaega näitav joon ja joon graafikutes) väheneb või isegi lihtsalt kasvab aeglasemalt, minuti kaupa, ja näidatud ooteaeg on 50 minutit või vähem, siis töötlete tellimusi piisavalt kiiresti ja järjekord tühjeneb lõpuks ning lõpetab automaatselt järjekorra näitamise, ilma et te peaksite midagi tegema ja ilma, et peaksite oma ülemusele ütlema, et surusite seda liiga kõvasti ja rikkusite selle. Te jõuate lõpuks selleni, kui järjekorra eesmise osa kiirus on suurem kui liitumiste arv minutis (mõlemad on näidatud Queue-Fair portaalis) - pöördepunkt on tavaliselt vähemalt mõne minuti pärast iga sündmuse lõppu. Kui te müüte piiratud kogusega toodet, müüakse see tõenäoliselt enne pöördepunkti jõudmist välja.

Hea uudis on see, et kui te kogemata seate järjekorra kiiruse liiga kõrgeks ja teie serverid murduvad, aitab Queue-Fair teil kiiresti tööle saada - pange järjekord lihtsalt ootele, kuni teie serverid on jälle valmis külastajate käitlemiseks. Hoidmisrežiimis näevad järjekorras olevad inimesed spetsiaalset hoidmislehte, mille saate kujundada enne veebisündmust. Kui järjekord on ootel, ei lasta kedagi järjekorra esiosast läbi, kuid uued internetikülastajad saavad siiski järjekorda liituda tagapool, et neid saaks õiglaselt järjekorda seada, kui ummistus on kõrvaldatud, mis juhtub väga kiiresti, sest Queue-Fair kaitseb teie saiti nõudluse eest. Ooteleht on parem kasutajakogemus kui järjekorra määramine tõesti madalaks, eriti kui te uuendate seda, et öelda külastajatele, millal te ootate järjekorra taasavamist, mida on lihtne teha portaalilehe redaktoriga, isegi kui järjekorras on juba sadu tuhandeid inimesi - ja ootelehel saate neid isegi ükshaaval läbi lasta Queue-Fair unikaalse Admit One nupu abil, kui teil on vaja, kuni teie süsteem taastub oma sakist.

Seega, kui teie serverid peavad ürituse ajal pausi tegema, siis on lehe "Hoidke" kasutamine just see, mida te selleks vajate, ja aitab teie serveritel kiiremini taastuda.

Kokkuvõte

Selles artiklis oleme selgitanud, miks kiirusel põhinev järjekord on alati parim viis ja andnud kaks meetodit vajaliku kiiruse arvutamiseks, kuid kui te ei ole teinud täielikku ja täpset virtuaalset külastajate koormuse testimist kogu oma tehinguvoo kohta ja olete selles osas tõesti super extra mega kindel, on meie nõuanne alati sama:

  1. Alustage, kui järjekorra määraks on seatud 10 või teie tehingu määr tavalisel päeval.
  2. Jälgige oma protsessori koormust ja muid jõudlusnäitajaid.
  3. Oodake, kuni uued tellimused salvestatakse teie sql-andmebaasis sama või sarnase kiirusega kui teie järjekorra määr.
  4. Vajutage CTRL-SHIFT-R oma lehekülgedel, et kontrollida reageerimisvõimet.
  5. Suurendage järjekorra määra mitte rohkem kui 20%.
  6. Minge tagasi sammu 2 juurde ja oodake uuesti.
  7. Kui järjekorra suurus väheneb või suureneb pidevalt vähem kiiresti iga minutiga ja näidatud ooteaeg on alla 50 minuti, ei pea see enam kiiremini minema.
  8. Istu maha ja lõõgastu! Queue-Fair on teid katnud.

Kui te müüte piiratud koguses toodet, ei pea te ka sammule 7 tähelepanu pöörama.

See on teie esimese järjekorra jaoks, kui te ei tea tegelikku maksimaalset järjekorra kiirust, mida teie süsteem suudab toetada. Kui te olete mõõtnud järjekorra kiiruse, mida teie süsteem tegelikult suudab taluda, saate järgnevate järjekordade puhul kasutada sama arvu uuesti - kuid ainult juhul, kui teie süsteemis ei ole midagi muutunud. Tegelikkuses on teie süsteemi tõenäoliselt pidevalt arendatud ja muudetud ning te ei pruugi teada, kuidas hiljutised muudatused on mõjutanud teie maksimaalset järjekorra kiirust - seega miks mitte alustada pooltest eelmistest mõõdetud näitajatest ja korrata ülaltoodud protsessi?

Niisiis, kuidas kasutada Queue-Fair-d, et teha oma onsale kõik kenasti ja turvaliselt, ja pidage meeles, et alati on parem olla kindel kui kahetseda.


Sajad juhtivad organisatsioonid usaldavad meie
järjekorra lahendusi

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

Lihtne lahendus teie internetiliikluse üleujutustele

Alusta