Iš tikrųjų neradome jokių "one-out" ir "one-in" privalumų. Trumpai tariant, šio metodo problema yra ta, kad kai naudotojai yra elektroninės komercijos svetainių lankytojai, žiniatinklio serveris nežino, kiek vienu metu yra naudotojų bet kuriuo laiko momentu. Tai stabdys. Štai kodėl.
Vėliau šiame straipsnyje taip pat pasakojame, kaip naudoti įkainiais pagrįstą virtualųjį kambarį svetainei apsaugoti.
Tradiciškai elektroninės komercijos serveriai yra parenkami taip, kad palaikytų maksimalų vienu metu veikiančių naudotojų skaičių, ir apkrova dažnai apibrėžiama tokiu būdu. Naudojant šį metodą svetainės eilei paleisti iškyla problema - šią problemą sprendžiame naudodami tarifus.
Problema kyla dėl to, kad lankytojai faktiškai naudojasi žiniatinklio serveriu tik tuo metu, kai jų naršyklė įkelia kiekvieną tinklalapį.
Tarkime, elektroninės komercijos svetainėje parduodami bilietai. Nuo lankytojo kelionės pradžios iki kelionės pabaigos (naudotojo sesijos) yra šeši puslapiai, nes lankytojas
Visas sandorio procesas vidutiniškai trunka penkias minutes.
Tarkime, kad, vėlgi, kas minutę bilietų pirkti atvyksta 100 lankytojų, o vidutinis proceso užbaigimo laikas - penkios minutės. Bet kuriuo laiko momentu sandorio procese vienu metu dalyvauja 500 žmonių, todėl serveris turi būti pritaikytas aptarnauti 500 vienu metu veikiančių naudotojų.
Galima būtų manyti, kad galima sukurti konkurečių naudotojų skaitiklį, kuris būtų didinamas kiekvieną kartą, kai į pagrindinį puslapį ateina naujas lankytojas, ir mažinamas kiekvieną kartą, kai lankytojas užbaigia operaciją, ir taip sužinoti, kiek naudotojų vienu metu aptarnauja vienas serveris, tačiau tai neveikia.
Tai neveiks, nes ne kiekvienas lankytojas užbaigia sandorį. Žmonės persigalvoja, išsiblaško arba nueina ir grįžta vėliau. Kadangi žiniatinklio serveris bendrauja su lankytojais tik tada, kai jų naršyklės įkelia puslapius, žiniatinklio serveris neturi galimybės sužinoti, kada tai įvyko ir kam.
Kad nustatytų, jog lankytojas nebedalyvauja sandorio procese, vienas serveris turi palaukti, kol šis lankytojas nebegaus daugiau puslapio užklausų, ir tada nutraukti lankytojo sesiją. Laiko limitai visada turi būti nustatyti daug ilgesni nei vidutinis sandorio laikas (šiame pavyzdyje, tarkime, 20 minučių), nes kai kurie lankytojai užtrunka daug ilgiau nei kiti, kol užbaigia sandorį.
Galima būtų pridėti galimybę taip pat mažinti savo hipotetinį "Concurrent User" skaitiklį kiekvieną kartą, kai lankytojo sesija tokiu būdu baigiasi, tačiau tai duoda labai prastus rezultatus.
Jei 10 % iš 100 lankytojų, atvykstančių kiekvieną minutę, neužbaigia sandorio, tie, kurie užbaigia, bus aktyvūs vidutiniškai penkias minutes, o tie, kurie neužbaigia, visada bus laikomi aktyviais bent 20 minučių (iš tikrųjų, atsižvelgiant į kelias sesijas, labiau tikėtina, kad bus taikomas sesijos pabaigos laikas ir vidutinė sesijos trukmė).
Tai yra 90 * 5 + 10 * 20 = 650, ir serveris praneš apie 650 tuo pačiu metu veikiančių naudotojų, nors iš tikrųjų jis yra mažiau užimtas!
Be to, net 10 * 20 = 200 iš šių vienu metu veikiančių naudotojų iš tikrųjų nesinaudoja svetaine, o jų veikla baigiasi, t. y. daugiau kaip 30 % visų vienu metu veikiančių naudotojų, nors tik 10 % lankytojų nepavyksta užbaigti sandorio.
Dabar tarkime, kad norima į šią svetainę įtraukti eilę, kurią kontroliuoja mūsų "Concurrent User Counter". Kai svetainė bus perpildyta, eilės priekyje esantis asmuo bus įleistas į svetainę tik tada, kai skaitiklis sumažės. Tai vadinama "vienas išėjimas-vienas įėjimas" eile. Atsitiks taip, kad 30 % laiko eilės priekyje esantis asmuo lauks, kol kas nors, kas nesiruošia užbaigti savo sandorio, baigs nebaigti savo sandorio.
Be to, reikia atlikti papildomus techninius integracijos darbus ir apkrauti svetainę, kad būtų galima sukurti ir paleisti skaitiklį bei dalytis šia informacija su eilių sistema. Jei dalijimosi arba skaičiavimo mechanizmas neveikia arba sugenda, eilė užstringa. Dar blogiau, jei vienas serveris taip užimtas, kad negali atnaujinti eilės serverio ir pranešti eilės serveriui, kad šis įleistų kitą asmenį, eilė taip pat užstringa.
Visos šios problemos lengvai ir paprastai išsprendžiamos vietoj to siunčiant lankytojus iš eilės priekio pastoviu fiksuotu greičiu - šiuo atveju 100 lankytojų per minutę.
Tokiu būdu nereikia matuoti faktinio vienu metu dirbančių naudotojų skaičiaus, nereikia sudėtingos integracijos su bilietų pardavimo svetaine ir nėra rizikos, kad eilė užstrigs.
Todėl 2004 m. išradome ir užpatentavome įkainiais pagrįstą virtualų laukiamąjį, skirtą užimtoms svetainėms.
‘Penkių žvaigždučių Queue-Fair apžvalga! Komanda yra labai profesionali ir maloni, labai punktuali ir atsižvelgia į klientų poreikius. Atvirai kalbant, puikiai sutariame visais aspektais. Queue-Fair yra labai svarbus įrankis valdant renginius, kuriuose dalyvauja daug dalyvių.’
‘Mums tai buvo labai ver tinga. Pagalba buvo profesionali, palaikymas buvo aukščiausios kokybės, ir jie net prisijungė prie mūsų susitikimo, kad stebėtų su mumis visais, kai eilė ėmė veikti. Tai buvo puiku!’
‘Patinka paslauga, palaikymas yra aukščiausio lygio nuo renginio pradžios iki pabaigos. Queue-Fair dėka mūsų renginys buvo įgyvendintas nepriekaištingai, viskas veikė puikiai 👍 Džiaugiamės, kad pasirinkome Queue-Fair paslaugą. Queue-Fair reiškė, kad galėjome pardavinėti internetinius bilietus į parodą, nesukeldami nuostolių infrastruktūrai ir neapsunkindami veiklos. Nėra nieko, kas galėtų nepatikti - paslauga apskritai nuostabi.’
‘Paprasta ir lengva naudoti, puikus klientų aptarnavimas. Lengva pritaikyti Queue-Fair savo prekės ženklui. Queue-Fair apsaugo mūsų klientų renginius nuo stambaus greičio pardavimo laikotarpiu.’
‘Nuostabu!!! Queue-Fair dirbo labai gerai ir parama yra labai gera. Queue-Fair išsprendė daugelio žmonių prieigos prie projekto problemą ir išvengė mano serverio gedimų. Planuojame ir toliau naudoti Queue-Fair būsimuose projektuose. Ačiū Queue-Fair!!!’
‘"Queue-Fair" žmonės viršijo savo galimybes ir padėjo mums įdiegti jų eilių sudarymo sistemą per vieną dieną. Kai eilėje laukė daugiau nei 25 000 žmonių, jie padėjo mums valdyti srautą per didžiausius pikus. Queue-Fair daro tai, ką ir turi daryti - rikiuoja žmones į eilę už konkurencingą kainą. Esame patenkinti "Queue-Fair" sistema ir naudosimės ja per būsimus renginius.’
‘Puikus įrankis išgelbėjo mūsų parduotuvę. Klientų aptarnavimas labai geras. Queue-Fair išsprendžia serverio prisotinimo problemą, kai parduodame daug bilietų. Nustatymas buvo paprastas ir man patiko įrankio efektyvumas.’
‘Kokybiškas produktas ir patikimas aptarnavimas. Buvome sukrėsti, kaip greitai buvo galima jį įdiegti ir kaip lengva juo naudotis. Produktas veikė tiksliai taip, kaip buvo numatyta. Norime padėkoti Queue-Fair komandai už tai, kad procesas buvo sklandus, ir už paramą, padėjusią mums atlikti sąranką. Kai organizuosime panašius renginius, būtinai pasitelksime Queue-Fair.’
‘Labai naudinga priemonė ir puiki techninė pagalba. Labai vertinu sklandų jo veikimą. Jis padeda mums sėkmingai valdyti didelio vartotojų srauto mūsų svetainėje laikotarpius. Dėl šio įrankio esame produktyvesni, nes jis leidžia mums skirti pastangų kitoms užduotims, o jo dalis lieka gerai padengta.’
‘Bendravimas ir lengvas naudojimasis Queue-Fair platforma iš tiesų daro produktą išskirtinį. Mums reikėjo eilės dėl ypač intensyvaus renginio mūsų svetainėje, o aš galėjau ją matyti realiuoju laiku, efektyviai atlikti pakeitimus ir įsitikinti, kad mūsų svetainė nesugrius. Kai man kildavo klausimų ar reikėdavo pagalbos, jie buvo labai paslaugūs. Tikrai rekomenduoju šią platformą ir paslaugą.’
‘Puikus! Patogus naudoti, lengvai nustatomas ir pradedamas naudoti - ir puikus verslo ryšys! Queue-Fair puikiai veikia, kai reikalai įsibėgėja, ir padeda sumažinti bilietų pardavimo svetainės apkrovą. Sukūrus Queue-Fair, atsižvelgiant į paprastą naudojimą, suteikta galimybė pagalbos komandai juo naudotis - nereikėjo jokių programuotojų!’
‘Pašalina visą stresą, susijusį su didelės paklausos renginių pristatymu. Labai lengva konfigūruoti ir nustatyti, o palaikymo komanda labai dėmesinga. Be to, kad nebeturėjome streso, renginius iš tikrųjų išpardavėme greičiau. Ji daro būtent tai, kas nurodyta ant skardinės. Sprendimas veikė puikiai.’
Jei žinote, kiek naudotojų vienu metu aptarnauja žiniatinklio serveris, ir vidutinę sandorio trukmę arba apsilankymo trukmę nuo pirmojo sandorio srauto puslapio iki užsakymo patvirtinimo puslapio, galite tai paversti eilės greičiu, naudodamiesi Little'o dėsniu, padalydami naudotojų skaičių iš trukmės, kaip nurodyta toliau:
eilės sparta = esamų naudotojų skaičius / operacijos laikas
Queue-Fair pristatys lankytojus į jūsų svetainę jūsų nurodytu greičiu - turime bene tiksliausią eilės dirbtinį intelektą, kuris užtikrina, kad kiekvieną minutę sulauktumėte tiek lankytojų, kiek norite, ir automatiškai atsižvelgia į žmones, kurių nėra, kai kviečiama jų eilė, taip pat į žmones, kurie grįžta pavėlavę.
Kaip tai susiję su vienu metu veikiančių naudotojų skaičiumi? Žinoma, ne kiekvienas į jūsų svetainę patekęs lankytojas užtruks lygiai tiek pat laiko, kiek vidutiniškai užtrunka sandoris, tačiau dėl didelių skaičių dėsnio su Queue-Fair turėsite labai pastovų vienu metu besinaudojančių vartotojų skaičių.
Tarkime, kad jūsų eilės dažnis yra 100 lankytojų per minutę. Kiekvieną minutę į jūsų svetainę siųsime po 100 lankytojų nuolatiniu srautu - tai mes darome ir mums tai stulbinamai gerai sekasi. Taip pat sakykime, kad žmonės jūsų svetaine naudojasi vidutiniškai (vidutiniškai) penkias minutes, o 70 proc. iš jų užtrunka nuo 4 iki 6 minučių nuo to momento, kai praeina eilę, iki to momento, kai pateikia paskutinę puslapio užklausą (nepriklausomai nuo to, ar užbaigia sandorį, ar ne). Standartinis nuokrypis yra viena minutė į abi puses nuo vidurkio. Statistiškai tai reiškia, kad kiekvienam lankytojui, kuris užtrunka penkias su puse minutės, tenka kitas, kuris užtrunka keturias su puse minutės, todėl šie atskirų apsilankymų trukmės svyravimai per kelias sesijas yra linkę panaikinti vienas kitą, kai bet kokiu būdu skaičiuojate daug lankytojų. Didelių skaičių dėsnis sako, kad šis panaikinimas tampa tuo tikslesnis, kuo didesnis dalyvaujančių žmonių skaičius.
Kaip tiksliai? Tai galime išsiaiškinti pasitelkę šiek tiek statistikos. Imties dydis yra 5 * 100 = 500, o tai yra didelis skaičius. Būtent tiek žmonių jūs skaičiuojate. Tai reiškia, kad pagal statistinę standartinės vidutinės pak laidos formulę vidutinė standartinė paklaida yra 1 (standartinis nuokrypis, 1 minutė), padalinta iš imties dydžio kvadratinės šaknies (taigi kvadratinė šaknis iš 500), todėl vidutinė standartinė vidutinė paklaida yra 0,044 minutės arba tik 2,7 sekundės, t. y. mažiau nei vienas procentas.
Tai reiškia, kad jei eilės sparta yra 100, o kiekvieno lankytojo operacijos trukmė - 5 minutės, plius minus minutė, turėtumėte tikėtis, kad maždaug 70 % laiko jūsų svetainėje vienu metu bus 495-505 naudotojai, taigi pagal matematinius skaičiavimus naudojant sparta pagrįstą eilę jūsų žiniatinklio serveriai bus apkrauti labai stabiliai, kaip pageidaujama.
Tačiau ar matematiniai skaičiavimai tikslūs? Čia yra keletas subtilybių - pavyzdžiui, imties dydis, kurį mes linksmai šaknijame kvadratu, ne visada yra lygiai 500 kiekvieną kartą, kai skaičiuojami gretutiniai naudotojai (t. y. bet kuriuo laiko momentu), be to, normalus (Gauso) pasiskirstymas gali duoti neigiamą sandorių laiką, kuris realiame gyvenime nepasitaiko. Taigi, siekdami patikrinti tokius skaičiavimus, naudojame simuliatorių, kuris atlieka matavimus sekundė po sekundės, ir tai rodo, kad pagal minėtus skaičius 70 % atvejų turėtumėte tikėtis 493-507 lankytojų, taigi matematika puikiai laikosi! Išmatavus duomenis taip pat paaiškėjo, kad jūsų svetainėje bent 95 % laiko bus 500 ± 15 lygiagrečių naudotojų.
Tai tikriausiai yra pastoviau nei tikslumas, kuriuo jūsų žiniatinklio serveris gali išmatuoti žmonių, besinaudojančių jūsų svetaine, skaičių! Dar geriau, kad net jei nežinote, koks yra jūsų lankytojų vidutinis sandorio laikas ar standartinis nuokrypis, šie matematiniai dydžiai egzistuoja nepriklausomai nuo to, ar jūs juos žinote, ar ne, ir vis tiek gausite stabilią apkrovą.
Taigi Queue-Fair beveik idealiai tiksliai nustatys norimą lankytojų skaičių per minutę, todėl jūsų svetainėje vienu metu bus labai pastovus naudotojų skaičius ir stabili žiniatinklio serverio apkrova, kurią galėsite visiškai kontroliuoti.
Ura!
O dabar įspėjimas. Verta pažymėti, kad vienu metu jūsų svetainėje esančių naudotojų skaičiaus stabilumas, taigi ir serverio apkrovos stabilumas, labai priklauso nuo to, kaip tiksliai jūsų virtualios laukiamosios salės paslaugų teikėjas kiekvieną minutę siunčia jums norimą lankytojų skaičių, todėl tai yra pagrindinis veiksnys renkantis virtualios laukiamosios salės platformą. Kadangi mes teikiame tiksliausią Virtualią laukimo salę pasaulyje, niekas geriau už Queue-Fair nesustabdo jūsų serverių užtvindymo.
Ką daryti, jei nežinote, kiek serveris gali dirbti su vienu metu veikiančiais vartotojais arba kiek laiko gali trukti operacija? Galite pažvelgti į puslapį, kuris gali būti jūsų kliūtis - paprastai tą, kuriame paspaudžiamas mygtukas "Pirkti dabar". Naudodamiesi "Google Analytics" raskite mėnesio unikalių to puslapio lankytojų skaičių arba suskaičiuokite mėnesio užsakymus. Padalykite šį skaičių iš 30 * 24 * 60 = 43 200 - tiek minučių per mėnesį (apytiksliai). Tai jūsų vidutinis lankytojų skaičius per minutę per visą mėnesį. Padauginkite tai iš trijų. Tai jūsų vidutinis lankytojų skaičius per minutę darbo valandomis (apytiksliai). Padvigubinkite šį skaičių. Tikriausiai tai yra saugus skaičius, kurį galima naudoti eilės normai nustatyti.
Pavyzdžiui, tarkime, kad per mėnesį apdorojate 100 000 užsakymų - tai 100 000 mygtuko "Pirkti dabar" paspaudimų. Tai yra 100 000 / 43 200 = 2,31 užsakymo per minutę. Galima tikėtis, kad dauguma šių užsakymų bus dienos metu, o naktį jūsų serveriai bus ramesni, todėl padauginkite šį skaičių iš 3 ir gausite 7 užsakymus per minutę - tai apytikslis įvertinimas, kiek darbo valandomis yra užimtas jūsų serveris. Jei gautas skaičius yra mažesnis nei 50: bus paklausos pikų ir nuosmukių, todėl jei piko valandomis jūsų serveris nėra pastebimai lėtas, padauginkite šį skaičių iš 2 ir gaukite 14 aktyvių naudotojų per minutę. Jei gautas skaičius yra didesnis nei 50: minutės pikas ir kritimas bus mažesni, palyginti su minutėmis, todėl nesaugu jį padvigubinti. Gautas skaičius tikriausiai yra saugus eilės greičio skaičius, nuo kurio galima pradėti ir kuris atitinka tai, kiek užklausų per sekundę galite saugiai valdyti; visada galite jį padidinti, jei pastebėsite, kad jūsų sistemos vis dar reaguoja į galutinio naudotojo našumą tokiu greičiu.
Jei jūsų užsakymai žymimi laiko žymomis, taip pat galite pažiūrėti, kiek daugiausiai užsakymų gavote per vieną minutę per pastarąjį mėnesį, tačiau naudokite atsargiai, nes nežinote, kiek užsakymų per tą minutę galėjo būti atmesta dėl sulėtėjusių serverių, todėl sumažinkite šį skaičių 20 %.
Likusioje šio straipsnio dalyje aptariami kiti eilės greičio nustatymo būdai.
Verta atkreipti dėmesį, kad įprastai vartojamos bent dvi sąvokos "lygiagretieji naudotojai" apibrėžtys.
Mes naudojame apibrėžtį: "sandorio sraute dalyvaujančių žmonių skaičius bet kuriuo metu". Tai pagrindinis skaičius, kurį reikia žinoti norint nustatyti eilės normą. Tai yra, kiek naudotojų šiuo metu peržiūri jūsų svetainę. Vienu metu vykstančių sesijų skaičius paprastai būna šiek tiek didesnis už vienu metu vykstančių prisijungimų arba vienu metu esančių naudotojų skaičių, nes kai kurios sesijos yra laike, todėl padidėja vidutinė sesijos trukmė.
Palyginkite tai su tuo, kiek vienu metu yra HTTP už klausų, kurias vienu metu apdoroja jūsų žiniatinklio serveris. Labai painu, kad daugelis specialistų, sakydami " kiek vartotojų vienu metu", turi omenyje "kiek vienu metu atliekamų užklausų".
Taip pat yra "Concurrent Connections" (arba lygiagretūs TCP ryšiai prie to paties serverio prievado tinklo sąsajos kortelėje), t. y. TCP/IP lizdų, atidarytų jūsų serverio prievade arba tarnybinėje stotyje bet kuriuo metu, skaičius. Atlikdamos puslapio užklausas, naršyklės pagal numatytuosius nustatymus palieka ryšį atvirą, jei puslapis pateiktų tolesnių užklausų arba naudotojas pereitų į kitą puslapį. Taip sumažinamas užklausų skaičius per sekundę naujiems TCP/IP ryšiams atidaryti, todėl serverio procesas tampa efektyvesnis. Šių lygiagrečių jungčių laikas skiriasi priklausomai nuo naršyklės: nuo 60 sekundžių iki niekada neuždaromo. Jūsų serveris taip pat gali automatiškai uždaryti ryšius po tam tikro laikotarpio, kai nėra jokios veiklos. Naudodami šią komandą "Linux" žiniatinklio serveriuose galite sužinoti vienalaikių prisijungimų prie to paties serverio prievado skaičių: netstat -aenp | grep ":80 \|:443 " | wc -l
kurį galite išbandyti, jei jums įdomu. Vėlgi, kai kurie žmonės tai taip pat vadina "lygiagrečiaisiais vartotojais", nors iš tikrųjų tai reiškia lygiagrečius ryšius.
Iš tiesų, jei paprašysite savo prieglobos paslaugų teikėjo nurodyti didžiausią vienu metu veikiančių vartotojų skaičių, kurį tvarko jūsų žiniatinklio serveris (koks yra didžiausias duomenų srautas), jis greičiausiai pateiks jums duomenis apie vienu metu veikiančias sesijas, vienu metu veikiančias užklausas arba vienu metu veikiančius ryšius dėl paprastos priežasties, nes nežino jūsų vidutinės sandorio trukmės, puslapių skaičiaus sandorio sraute ar kitos informacijos, kuri leistų pasakyti, kiek vienu metu veikiančių vartotojų tvarko jūsų žiniatinklio serveris. Visi šie skaičiai turi skirtingas reikšmes.
Jei prašote prieglobos paslaugų teikėjo arba techninės komandos informacijos apie didžiausią duomenų srautą, labai svarbu išsiaiškinti, ar jie turi omenyje tuo pačiu metu veikiančius vartotojus, tuo pačiu metu veikiančias sesijas, tuo pačiu metu veikiančias užklausas, ar tuo pačiu metu veikiančius ryšius.
Štai kodėl. Kiekvienas puslapis yra viena HTTP užklausa, tačiau visi iš jūsų žiniatinklio programos gaunami paveikslėliai, scenarijai ir kiti failai, kuriuos naršyklė naudoja puslapiui rodyti, taip pat yra HTTP užklausos.
Įsivaizduokime, kad technikų komanda jums pasakė, jog serveris palaiko 500 vienu metu veikiančių naudotojų, tačiau iš tikrųjų jie turėjo omenyje 500 vienu metu veikiančių užklausų. Turėdami 5 minučių transakcijos laiką, naudojate pirmiau pateiktą formulę ir darote prielaidą, kad jūsų svetainė gali palaikyti 100 lankytojų per minutę.
Ar gali? Ne.
Kai žmonės eina per sandorių srautą, jie iš tikrųjų siunčia užklausas iš jūsų serverių tik tuo metu, kai įkeliamas kiekvienas puslapis. Tai turi įtakos tam, kiek srauto per sekundę arba aktyvių naudotojų gali aptarnauti jūsų serveris. Iš penkių minučių transakcijos laiko vidutiniam naudotojui tai yra tik kelios sekundės. Todėl galite manyti, kad 500 vienalaikių užklausų reiškia, kad galite aptarnauti daug daugiau vienalaikių naudotojų, tačiau galite klysti. Ar dabar suprantate, kaip sudėtinga suprasti savo svetainės pajėgumą pagal tai, koks yra srautas arba bendras aktyvių naudotojų skaičius?
Norėdami apskaičiuoti didžiausią galimą vienu metu dirbančių naudotojų skaičių pagal didžiausią galimą bendrą vienu metu dirbančių užklausų skaičių, taip pat turite žinoti
Tikriausiai jau žinote 1) ir 2) punktus - mūsų pavyzdyje tai 6 puslapiai ir 5 minutės. Galite nesunkiai suskaičiuoti puslapius, kuriuos matote atlikdami sandorį. Jei nežinote vidutinės sandorio trukmės, tai gali pasakyti "Google Analytics" arba galite patikrinti savo žiniatinklio serverio žurnalus.
3) ir 4) atvejais gali padėti "Firefox" naršyklė. Dešiniuoju pelės klavišu spustelėkite svetainės puslapį, pasirinkite Inspect Element (tikrinti elementą) ir skirtuką Network (tinklas). Tada paspauskite CTRL-SHIFT-R, kad visiškai atnaujintumėte puslapį. Sąraše pamatysite kiekvieno puslapio elemento tinklo įkėlimo laiką. Norite įsitikinti, kad stulpelyje Perkelta matote perkėlimo dydžius, nes priešingu atveju failai gali būti pateikiami iš talpyklos, o tai gali sugadinti jūsų skaičiavimus. Gali būti, kad kai kurie skriptai ir kiti ištekliai bus siunčiami ne iš jūsų svetainės serverių, todėl kairėje esančiame filtro lange galite įvesti savo svetainės domeno pavadinimą. Norėdami pamatyti stulpelį "Trukmė", dešiniuoju pelės klavišu spustelėkite bet kurio stulpelio antraštę ir išskleidžiamajame meniu pasirinkite Laikas -> Trukmė. Jūsų ekranas turėtų atrodyti taip:
Šio puslapio "Firefox" tinklo skirtukas, rodantis queue-fair.com užklausų trukmę ir skaičių
Puslapiams rodyti naudojami failai gali būti iš įvairių svetainių, todėl norėdami rodyti tik tuos, kurie yra jūsų svetainėje, taip pat naudokite viršutiniame kairiajame kampe esantį filtrą, bet tik jei esate tikri, kad tie failai iš kitų svetainių nėra lėto puslapių įkėlimo priežastis arba kliūčių dalis.
"Firefox" skaičiuoja užklausas ekrano apačioje kairėje pusėje ir rodo 36 HTTP užklausas tik šiam vienam puslapiui.
Turite tai atlikti kiekvienam sandorių srauto puslapiui - suskaičiuokite bendrą skaičių ir padalykite iš puslapių skaičiaus, kad sužinotumėte vidutinį kiekvieno puslapio HTTP užklausų skaičių (3) mūsų sąraše. Dabar suprantate, kodėl kiekvieno HTML puslapio vaikų užklausų skaičius yra toks svarbus veiksnys, lemiantis, kokį srautą gali apdoroti jūsų žiniatinklio serveris.
4) atveju reikia peržiūrėti stulpelį "Trukmė" ir rasti visų savo puslapių HTTP užklausų vidurkį. Jei nesate tikri, numatykite pusę sekundės - vis tiek yra daug neapibrėžtumo (žr. toliau).
Pateiksime keletą pavyzdžių. Jau minėjome, kad pavyzdiniame serverio procesų sraute yra šeši dinaminiai puslapiai, t. y. 1), ir kad vidutinė operacijos trukmė yra penkios minutės, t. y. 2). Tarkime, kad vienam puslapiui tenka 36 HTTP užklausos, t. y. 3), o kiekvienos HTTP užklausos apdorojimo laikas serveryje yra pusė sekundės, t. y. 4).
Pagal šiuos skaičius serveris, galintis apdoroti 500 vienalaikių užklausų, gali apdoroti 500 / (0,5 sekundės) = 1000 HTTP užklausų per sekundę, t. y. 60 000 HTTP užklausų per minutę, kai jis yra visiškai išnaudotas.
Per penkias minutes jis gali apdoroti 5 * 60 000 = 300 000 HTTP užklausų. Atrodo daug, tiesa?
Tačiau kiekvienam lankytojui tenka šeši puslapiai, kurių kiekvienas vidutiniškai pateikia po 36 HTTP užklausas, taigi 6 * 36 = 216 užklausų.
Taigi, 300 000 HTTP užklausų talpa teoriškai gali būti pritaikyta 300 000 / 216 = 1 389 vienu metu veikiantiems naudotojams.
Ei, tai puiku! Manėme, kad galime turėti tik 100 lankytojų, bet 1 389 / 5 minutės = 278 lankytojai per minutę, taigi galime turėti didesnį eilių skaičių!
Tikriausiai ne. Pirma, lankytojai nesiųs užklausų tiksliai pusės sekundės intervalais, kaip numatyta pirmiau pateiktame skaičiavime. Dar svarbiau yra tai, kad įvesties duomenis matuosite tada, kai svetainė nebus užimta. Šiukšlės įeina, šiukšlės išeina.
Kai svetainė užimta, serveris ilgiau apdoroja užklausas - tai pastebėjote kitose svetainėse, kai jos yra užimtos ir ilgiau laukiate puslapių. Dėl to pailgėja vidutinis laikas, per kurį serveris apdoroja vieną HTTP užklausą (4), o tai sumažina didžiausią pralaidumą. Taigi paimkite 278 lankytojų per minutę skaičių ir sumažinkite jį perpus. Tada dar kartą sumažinkite perpus. Tikėtina, kad realiai per minutę, esant didžiausiam apkrovimui, sulauksite apie 70 naujų lankytojų.
Kiti klaidinantys veiksniai yra spartinančioji atmintinė, kuri reiškia, kad jūsų lankytojų naršyklėms gali nereikėti atlikti kiekvienos užklausos dėl kiekvieno puslapio - tai reiškia, kad serveriui reikia mažiau išteklių ir gali padidinti naujų lankytojų skaičių per minutę, kurį gali aptarnauti jūsų serveris. Apkrovos balansavimo įrenginiai, kurie paskirsto apkrovą keliems serveriams, ir statinio turinio, o ne dinaminių puslapių pateikimas taip pat gali pagreitinti jūsų serverio procesą, nes kiekvienam serveriui reikia mažiau išteklių.
Taip pat pastebėsite, kad ne visiems puslapiams sukurti reikia tiek pat laiko, nes vieniems puslapiams sukurti ir pateikti reikia mažiau išteklių nei kitiems. Paieška duomenų bazėje, paieškos užklausos ir atnaujinimai užtrunka ilgiausiai, todėl kur nors jūsų procese atsiras kliūčių, kai žmonės susikaups, laukdami, kol bus apdoroti kredito kortelės duomenys ir išsaugoti užsakymai, arba laukdami, kol bus patikrintas užimtumas. Kiekvienas sandorių srautas turi lėčiausią žingsnį, todėl visuomet kur nors yra siauras taškas, o į klausimą, kiek naudotojų vienu metu gali aptarnauti žiniatinklio serveris, visuomet galima atsakyti maksimalia verte - ir gali būti kelios ribos. Tokiu atveju norite nustatyti pakankamai mažą eilės spartą, kad užtikrintumėte, jog jūsų serveris turi procesoriaus laiko pajėgumų vienu metu apdoroti pakankamai žmonių lėčiausiame jūsų proceso žingsnyje, kad žmonės ten nesikauptų. Priešingu atveju jūsų žiniatinklio serveris gali tiesiog sustoti.
Mūsų patirtis rodo, kad pradėdami pirmąjį pardavimą visi pervertina savo serverių galimybes susidoroti su dideliu srautu.
Visi.
Tiksliai nustatyti vidutinę sesijos trukmę ir galutinio naudotojo našumą lėto ar didžiausio srauto metu nėra lengva užduotis. Geriausia atlikti tinkamą apkrovos testą, kai "netikri" klientai iš tikrųjų atlieka užsakymo procesą, o apkrovos testavimo metu testuoja lygiai taip pat, kaip ir realiame gyvenime, atlieka tas pačias HTTP užklausas ta pačia tvarka, tarp puslapių laukia tiek pat laiko, kiek ir realiame gyvenime, ir stebi procesoriaus apkrovą, IO pralaidumą ir atsako laiką, kai didėja virtualių lankytojų skaičius. Tam galite naudoti "Apache JMeter" (mums taip pat patinka " K6", kai apkrovos mažesnės arba mašinos lėtesnės), tačiau, kad ir kokią priemonę naudotumėte, imituoti kiekvieno vartotojo elgesį tiksliai pagal reikalavimus (ypač dėl spartinančiosios atmintinės sudėtingumo) užima daug laiko ir yra sudėtinga. Net ir tokiu atveju paimkite maksimalų skaičių ir sumažinkite jį perpus.
Jei to nėra, verčiau elkitės atsargiai.
Naudodamiesi Queue-Fair portalu galite bet kada lengvai pakeisti bet kurios Queue-Fair eilės greitį. Pradėkite nuo 10 lankytojų per minutę arba įprastinės dienos sandorių skaičiaus, pažiūrėkite, kaip seksis kurį laiką po to, kai bilietai bus pradėti pardavinėti, ir jei viskas atrodo gerai, procesoriaus apkrova nedidelė, sql duomenų bazė tvarkinga ir (svarbiausia) puslapiai reaguoja, kai paspaudžiate CTRL-SHIFT-R, padidinkite šį skaičių ne daugiau kaip 20 %, šiek tiek palaukite ir pakartokite. Netrukus nustatysite tikrąją normą, kurios jums reikia per šį apkrovos balansavimą (matote, ką čia padarėme?), ir atminkite, kad klientų patirties požiūriu eilės normą galima padidinti, nes dėl to sumažėja numatomas laukimas, kurį mato jūsų eilėje esantys klientai, ir visi džiaugiasi matydami atsako laiką, kuris užtikrina trumpesnį numatomą laukimą.
Norite vengti per didelio eilės greičio nustatymo, kad paskui nereikėtų jo mažinti, nes tai a) reiškia, kad svetainę naudojantys žmonės lėtai įkelia puslapius, ir b) padidina numatomą laukimo trukmę. Visi jūsų eilėje esantys žmonės atsidūsta!
Nepamirškite, kad užsakymo procese atsiras kliūčių - kiekviename sandoryje yra lėčiausias etapas - ir ten susikaups kelios sesijos. Nenorite, kad praėjus minutei nuo bilietų pardavimo pradžios pamatytumėte, kad jūsų serverio procesoriaus apkrova yra gerokai mažesnė už maksimalų skaičių, ir padidintumėte greitį. Jūsų lankytojai tikriausiai dar nepasiekė mygtuko "Pirkti dabar". Norite palaukti, kol jūsų sql duomenų bazė praneš apie naujus užsakymus tokiu pat arba panašiu greičiu kaip ir eilės rodiklis, ir tada atlikti matavimus bei reakcijos bandymus. Atminkite, kad kiekvieną kartą, kai padidinsite greitį, prireiks tiek pat laiko, kol papildomi lankytojai pasieks jūsų siaurą vietą, todėl negalėsite tiksliai įvertinti, kaip jūsų serveris veikia esant naujam greičiui, kol nepraeis šis laikas .
Jau aptarėme, kaip geriausia eilės greitį didinti palaipsniui, kai eilė jau atidaryta. Tikriausiai žinote, kad jūsų serveriai turi ribą, kurios negalima viršyti be sistemos gedimo, ir galbūt net žinote, kokia ta riba yra, tačiau galbūt nežinote, kad apkrovai artėjant prie šios ribos paprastai būna labai mažai ženklų - dažnai tik kelios klaidos ar įspėjimai arba procesoriaus apkrova viršija 80 %.
Sutrikus žiniatinklio paslaugų veikimui, jos paprastai labai greitai "sustreikuoja" arba užgęsta. Paprastai taip nutinka todėl, kad kai sistema nebegali apdoroti užklausų taip greitai, kaip jos ateina, susidaro vidinės apdorojimo eilės. Tuomet jūsų sistema turi apdoroti, tvarkyti ir saugoti ne tik užklausas, bet ir savo vidines eiles, todėl serveriams tenka dirbti daugiau nei reikia. Labai greitai. Kai tai atsitinka, jūsų serveriai kurį laiką gali atsakyti klaidos puslapiu, tačiau tai jums nepadės, nes jį pamatę lankytojai iš karto paspaus "Atnaujinti" ir dar labiau padidins apkrovą.
Dar prieš tai, jei lankytojai puslapius mato ilgiau nei sekundę, paspauskite "Atnaujinti". Kai lankytojas paspaudžia "Atnaujinti", jūsų žiniatinklio serveris nežino, kad lankytojas nebelaukia atsakymo į pradinę užklausą. Jei gaunama ir pradinė, ir atnaujinimo užklausa, žiniatinklio serveris apdoroja abi. Tai reiškia, kad jūsų žiniatinklio serveriui teks daugiau darbo, visi lankytojai gaus dar lėtesnius atsakymus, o daugiau žmonių paspaus atnaujinimo mygtuką, todėl užsisuks užburtas ratas, kuris sustabdys jūsų žiniatinklio serverį dar prieš jam pradedant siųsti klaidų atsakymus.
Todėl nespauskite savo serverių labiau, nei reikia. Paprastai neverta rizikuoti, jei norite išnaudoti 20 % procesoriaus laiko pajėgumo. Jei Queue-Fair portale rodomas eilės dydis (geltonas Laukimo skaičius ir linija diagramose) mažėja arba net tik lėčiau didėja, minutė po minutės, o rodomas laukimo laikas yra 50 minučių ar mažiau, vadinasi, užsakymus apdorojate pakankamai greitai ir eilė galiausiai ištuštės ir nustos rodyti eilės puslapius automatiškai, jums nieko nedarant ir nesakant viršininkui, kad per daug spaudėte ir sugadinote. Galiausiai to pasieksite, kol eilės priekio greitis bus didesnis nei prisijungimų kas minutę skaičius (abu šie rodikliai rodomi Queue-Fair portale) - lūžio taškas paprastai būna bent po kelių minučių po kiekvieno įvykio. Jei parduodate riboto kiekio gaminį, tikriausiai jį išparduosite anksčiau, nei bus pasiektas lūžio taškas.
Gera žinia yra ta, kad jei netyčia nustatėte per didelę eilės spartą ir serveriai sutriko, Queue-Fair gali padėti greitai atnaujinti veiklą - tiesiog atidėkite eilę, kol serveriai vėl bus pasirengę priimti lankytojus. Veikiant sulaikymo režimui, eilėje esantys žmonės mato specialų sulaikymo puslapį, kurį galite sukurti prieš internetinį renginį. Kai eilė sulaikoma, niekas neįleidžiamas iš eilės priekio, tačiau nauji interneto lankytojai vis tiek gali prisijungti prie eilės gale, kad būtų sąžiningai įrašyti į eilę, kai tik bus pašalinta blokada, o tai įvyks labai greitai, nes Queue-Fair apsaugo jūsų svetainę nuo paklausos. Sulaikymo puslapis yra pranašesnis už eilės greičio nustatymą labai žemai, ypač jei jį atnaujinsite ir lankytojams nurodysite, kada tikitės, kad eilė vėl atsidarys, o tai lengva padaryti portalo puslapio redaktoriumi, net jei eilėje jau yra šimtai tūkstančių žmonių, o esant sulaikymo režimui, jei reikia, net galite juos praleisti po vieną, naudodami unikalų Queue-Fair mygtuką "Priimti vieną", kol sistema atsigaus po užstrigimo.
Taigi, jei per renginį jūsų serveriams prireiktų pertraukos, puslapis "Hold" yra kaip tik tai, ko jums reikia, be to, padės serveriams greičiau atsistatyti.
Šiame straipsnyje paaiškinome, kodėl visuomet geriausia rinktis greičiu pagrįstą eilę, ir pateikėme du metodus, kaip apskaičiuoti reikiamą greitį, tačiau, jei neatlikote išsamaus ir tikslaus virtualaus lankytojo apkrovos testavimo su visu savo sandorių srautu ir nesate dėl to labai labai labai tikri, mūsų patarimas visuomet yra tas pats:
Jei parduodate riboto kiekio gaminį, 7 žingsniui dėmesio skirti nereikia.
Tai taikoma pirmajai eilei, kai nežinote tikrojo didžiausio eilės greičio, kurį gali palaikyti jūsų sistema. Vėlesnėms eilėms, kai išmatuosite eilių dažnį, kurį jūsų sistema iš tikrųjų gali išlaikyti, galėsite vėl naudoti tą patį skaičių, bet tik tuo atveju, jei jūsų sistemoje niekas nepasikeitė. Praktikoje jūsų sistema tikriausiai yra nuolat tobulinama ir keičiama, todėl galite nežinoti, kaip naujausi pokyčiai paveikė didžiausią eilių spartą, tad kodėl nepradėjus nuo pusės anksčiau išmatuoto skaičiaus ir pakartojus pirmiau aprašytą procesą?
Štai kaip naudoti Queue-Fair, kad jūsų pardavimas būtų gražus ir saugus, ir nepamirškite, kad visada geriau būti saugiam, nei gailėtis.
2004 m. išrasta ir užpatentuota "Queue-Fair" yra originali virtuali laukimo salė, kurioje galima internetu valdyti eiles užimtose svetainėse ir programėlėse.
2024 The Fair Queue People Ltd. - Visos teisės saugomos.
"Orderly" eilių sprendimų šeimos dalis - OrderlyQ - OrderlyStats - WeQ4U
