Kaip naudojantis mūsų internetine eile išvengiama svetainės ir svetainės gedimų - kiek vienu metu prisijungusių naudotojų gali aptarnauti žiniatinklio serveris?

Kodėl verta naudoti įkainiais pagrįstą virtualų laukiamąjį?

Įkainiais pagrįsta ar "vienas išeina, vienas įeina"? Svarstome privalumus ir trūkumus.

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.



Aukščiausiai įvertintas virtualus laukiamasis " G2

Ką mūsų klientai sako apie Queue-Fair


apkrovos testavimas http užklausos kiek užklausų gali atlikti žiniatinklio serveris be papildomų serverio išteklių

Kiek vienu metu veikiančių naudotojų gali aptarnauti žiniatinklio serveris?

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

Kiek tiksli yra tarifais pagrįsta eilių sistema?

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.

operacinės sistemos maksimalus žiniatinklio serverio išteklių skaičius
vidutinio skaičiaus apskaičiavimas vienu metu veikiantiems naudotojams su pasikliautinuoju intervalu

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!


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

Lengvas būdas apskaičiuoti eilės greitį

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.

apskaičiuoti maksimalų aktyviųjų naudotojų lygį jūsų žiniatinklio programai.

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.

painiava dėl lygiagrečių naudotojų lygiagrečių prisijungimų lygiagrečių sesijų ir vidutinės sesijos trukmės

Turiu #1: Vienkartiniai naudotojai vs. Vienkartinės užklausos vs. Vienkartiniai prisijungimai vs. Vienkartinės sesijos

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.

Jei tai padarysite neteisingai, jūsų svetainė gali sugesti!

Š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?

pirmiausia saugokite savo serverio išteklius, kai nustatote, kiek užklausų gali gauti jūsų tinklalapiai, kad kiekvienas naudotojas galėtų gauti gerą patirtį.

Lygiagrečių užklausų konvertavimas į lygiagrečius naudotojus

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

  1. Sandorio srauto puslapių skaičius
  2. Vidutinė lankytojo operacijos trukmė nuo pirmojo iki paskutinio srauto puslapio
  3. Kiek vidutiniškai užklausų sudaro kiekvieną puslapį
  4. Vidutinis laikas, per kurį jūsų serveris apdoroja vieną HTTP užklausą

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

atlikti matematinius skaičiavimus ir nustatyti, kiek sesijų vienu metu, kiek naudotojų ir kiek užklausų per sekundę yra jūsų žiniatinklio programoje, nesvarbu, ar tai būtų vieno serverio, ar statinio turinio programa.

Matematiniai skaičiavimai

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.

Turiu #2: Apkrovus žiniatinklio serverius, jie tampa lėtesni

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

kuo didesnė apkrova dėl srauto šuolių, tuo lėtesnės mašinos.

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.

neaišku, kaip apskaičiuoti serverių pajėgumus serverio išteklius kiekvienam naudotojui.

Ką man daryti?

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ą ir testuoja apkrovą 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, reikia daug laiko ir sudėtinga tiksliai imituoti kiekvieno vartotojo elgesį (ypač dėl spartinančiosios atmintinės sudėtingumo). 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ą pardavus bilietus, ir jei viskas atrodo gerai, procesoriaus apkrova nedidelė, sql duomenų bazė tvarkinga ir (svarbiausia) puslapiai reaguoja paspaudus CTRL-SHIFT-R, padvigubinkite šį skaičių, š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 trumpesnį numatomą laukimo laiką.

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!

Turiu #3: Per greitas greičio didinimas atidarius eilę

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 .

sulėtinti sprendimą naudoti serverio išteklius.
serveriai suveikia, kai viršijami serverių pajėgumai.

Turiu #4: Jūsų serverių fiksavimas

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

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.

Išvada

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

  1. Pradėkite nuo eilės greičio, nustatyto kaip 10, arba įprastinės dienos sandorių greičio.
  2. Stebėkite procesoriaus apkrovą ir kitus našumo rodiklius.
  3. Palaukite, kol į sql duomenų bazę bus įrašomi nauji užsakymai tokiu pat arba panašiu greičiu kaip ir eilės rodiklis.
  4. Paspauskite CTRL-SHIFT-R ir patikrinkite puslapių jautrumą.
  5. Padidinkite eilės greitį ne daugiau kaip 20 %.
  6. Grįžkite prie 2 veiksmo ir vėl palaukite.
  7. Kai eilės dydis mažėja arba kas minutę nuolat didėja ne taip sparčiai, o rodomas laukimo laikas yra trumpesnis nei 50 minučių, jo greitinti nereikia.
  8. Atsisėskite ir atsipalaiduokite! Queue-Fair pasirūpino jumis.

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ą?

Atminkite, kad visada geriau saugotis, nei gailėtis.


Šimtai pirmaujančių organizacijų pasitiki mūsų
eilių sprendimais

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

Paprastas interneto srauto padidėjimo sprendimas

Pradėkite