Patiesībā mēs nevarējām atrast nekādus plusus par "one-out, one-in". Īsāk sakot, šīs pieejas problēma ir tāda, ka tad, ja lietotāji ir e-komercijas vietņu apmeklētāji, tīmekļa serveris nezina, cik daudz vienlaicīgu lietotāju tam ir jebkurā brīdī. Tas ir traucēklis. Lūk, kāpēc.
Vēlāk šajā rakstā mēs arī pastāstīsim, kā izmantot uz tarifiem balstītu virtuālo istabu, lai aizsargātu arī savu vietni.
Tradicionāli e-komercijas serveri tiek nodrošināti tā, lai atbalstītu maksimālo vienlaicīgo lietotāju skaitu, un slodze bieži tiek definēta šādā veidā. Izmantojot šo pieeju, pastāv problēma, kas saistīta ar tīmekļa vietnes rindas uzturēšanu - šo problēmu mēs risinām ar likmēm.
Problēma rodas tāpēc, ka apmeklētāji tīmekļa serveri faktiski izmanto tikai tad, kad pārlūkprogramma ielādē katru tīmekļa lapu.
Piemēram, pieņemsim, ka e-komercijas vietnē tiek pārdotas biļetes. No apmeklētāja ceļojuma sākuma līdz apmeklētāja ceļojuma beigām (lietotāja sesija) ir sešas lapas, jo apmeklētājs
Viss darījuma process vidēji aizņem piecas minūtes.
Pieņemsim, ka, piemēram, katru minūti ierodas 100 apmeklētāji, lai iegādātos biļetes, un vidējais laiks, kas nepieciešams, lai pabeigtu šo procesu, ir piecas minūtes. Jebkurā konkrētā brīdī darījuma procesā vienlaikus ir 500 cilvēku, un serverim jābūt nodrošinātam, lai tas varētu apkalpot 500 vienlaicīgus lietotājus.
Varētu domāt, ka varētu izveidot vienlaicīgu lietotāju skaitītāju, kas tiek palielināts katru reizi, kad sākumlapā ierodas jauns apmeklētājs, un samazināts katru reizi, kad apmeklētājs pabeidz darījumu, un ka tas parādītu, cik daudz lietotāju vienlaikus apstrādā viens serveris, taču tas nedarbosies.
Tas nedarbosies, jo ne katrs apmeklētājs pabeidz darījumu. Cilvēki maina savu lēmumu, novērš uzmanību vai aiziet prom un atgriežas vēlāk. Tā kā tīmekļa serveris mijiedarbojas ar apmeklētājiem tikai tad, kad viņu pārlūkprogrammas ielādē lapas, tīmekļa serveris nevar zināt, kad tas ir noticis un kam tas noticis.
Tā vietā, lai noteiktu, ka apmeklētājs vairs nepiedalās darījuma procesā, vienotajam serverim ir jāgaida, vai šis apmeklētājs vairs nesaņem lapas pieprasījumus, un pēc tam jāpārtrauc šī apmeklētāja sesija. Laiks vienmēr jānosaka daudz ilgāks par vidējo darījuma laiku (piemēram, 20 minūtes šajā piemērā), jo dažiem apmeklētājiem darījuma pabeigšana aizņem daudz vairāk laika nekā citiem.
Šādā veidā varētu pievienot iespēju arī samazināt savu nosacīto vienlaicīgo lietotāju skaitītāju katru reizi, kad apmeklētāja sesija beidzas, taču tas dod ļoti sliktus rezultātus.
Ja 10 % no 100 apmeklētājiem, kas ierodas katru minūti, nepabeidz savu darījumu, tie, kas pabeidz, būs aktīvi vidēji piecas minūtes, bet tie, kas nepabeidz, vienmēr tiks uzskatīti par aktīviem vismaz 20 minūtes (patiesībā sesijas laiks plus vidējais sesijas ilgums ir ticamāks, ja ņem vērā vairākas sesijas).
Tas ir 90 * 5 + 10 * 20 = 650, un serveris ziņos par 650 vienlaicīgiem lietotājiem, lai gan patiesībā tas ir mazāk aizņemts!
Turklāt pat 10 * 20 = 200 no šiem vienlaicīgajiem lietotājiem faktiski neizmanto vietni un ir procesā, kad tiek pārtraukta to izmantošana, kas ir vairāk nekā 30 % no paziņotajiem vienlaicīgajiem lietotājiem, lai gan tikai 10 % no apmeklētājiem nav pabeiguši darījumu.
Pieņemsim, ka kāds vēlas pievienot šai vietnei rindu, ko kontrolē mūsu vienlaicīgo lietotāju skaitītājs. Tiklīdz vietne būs pilnībā noslogota, persona, kas atrodas rindas priekšgalā, tiks ielaista vietnē tikai tad, kad skaitītāja vērtība samazināsies. To sauc par rindu "viens iznācis - viens ienācis" (one-out-one-in queue). Notiks tā, ka 30 % gadījumu rindas priekšgalā esošā persona gaidīs, kamēr kāds, kurš neplāno pabeigt savu darījumu, nepabeigs savu darījumu.
Ir arī papildu tehniskās integrācijas darbs un tīmekļa vietnes noslogojums, kas saistīts ar skaitītāja izveidi un darbību, kā arī šīs informācijas apmaiņu ar rindu sistēmu. Ja koplietošanas vai skaitīšanas mehānisms nedarbojas vai sabojājas, rinda iestrēgst. Vēl ļaunāk, ja vienīgais serveris ir tik aizņemts, ka nespēj atjaunināt rindas serveri, lai paziņotu rindas serverim, ka jālaiž nākamā persona, rinda arī iestrēgst.
Visas šīs problēmas ir viegli un vienkārši atrisināmas, nosūtot apmeklētājus no rindas sākuma ar nemainīgu, fiksētu ātrumu - šajā gadījumā 100 apmeklētāji minūtē.
Šādā veidā nav jāmēra faktiskais vienlaicīgo lietotāju skaits, nav nepieciešama sarežģīta integrācija ar biļešu pārdošanas vietni un nav riska, ka rinda var iestrēgt.
Tāpēc 2004. gadā mēs izgudrojām un patentējām uz tarifiem balstītu virtuālo uzgaidāmo telpu aizņemtām tīmekļa vietnēm.
‘Lieliska platforma! Queue-Fair ir patiešām viegli izmantot, ar lielisku klientu atbalstu - vienmēr atbild ātri un skaidri. Lieliskie tiešraides ziņojumi palīdzēja mums precīzi uzraudzīt datplūsmu pasākumu atklāšanas laikā, turklāt tos bija viegli integrēt un izveidot zīmolu. Queue-Fair nodrošina, ka ikvienam ir vienlīdzīgas iespējas apmeklēt mūsu pasākumus, ko mēs patiešām novērtējam.’
‘Queue-Fair ir godīgi pārsteidzošs produkts - ļoti ieteicams. Es vēlos, lai mēs būtu pārgājuši agrāk! Viss process līdz ieviešanai bija viens no gludākajiem, kādus jebkad esmu piedzīvojis. Queue-Fair ir papildu funkcijas, ko mūsu iepriekšējais piegādātājs nespēja nodrošināt, tāpēc pāreja bija vienkārša. Ikvienam, kas meklē rindu produktu, nevajadzētu meklēt tālāk. Mums tas patīk!’
‘Novērš visu stresu, kas saistīts ar liela pieprasījuma pasākumu uzsākšanu. Ļoti viegli konfigurēt un iestatīt, un atbalsta komanda ir ļoti uzmanīga. Papildus tam, ka nav stresa, mēs patiesībā pārdodam produktus ātrāk. Tas dara tieši to, kas norādīts uz skārda. Risinājums darbojās perfekti.’
‘Labākā uzgaidāmā telpa, ļoti viegli to īstenot, ļoti noderīga!!!! Sistēma darbojas ļoti labi - mēs to izmantosim arī turpmākajos pasākumos, un man patīk šis pakalpojums! Mēs varam sadalīt mūsu servera slodzi, jo visi lietotāji var uzturēties virtuālajā uzgaidāmajā telpā, tāpēc, manuprāt, es izdarīju labu izvēli, izvēloties šo rīku. Viss bija lieliski!’
‘Viegli lietojams rīks un atsaucīga komanda. Katru sestdienu mēs piedāvājam ierobežotu produktu skaitu priekšpiegādei, radot masveida un ātru servera pārslodzi. Mums bija jāatrod risinājums, lai absorbētu datplūsmu un padarītu mūsu klientu iepirkšanās pieredzi raitāku. Šo rīku bija viegli uzstādīt manā tīmekļa vietnē. Viņu dokumentācija ir pilnīga un precīza.’
‘Nekādu muļķību nesagādājoša, izmaksu ziņā efektīva rindu veidošanas sistēma, kas darbojas. Queue-Fair mums ir palīdzējis gan īpašu produktu laišanas tirgū, gan ikdienas satiksmes maksimuma gadījumos. Tā mums darbojas nevainojami - kad mēs izmēģinām jebkuru tehnoloģiju, mēs vēlamies pārliecināties, ka a) tā darbojas un b) ir rentabla, un Queue-Fair atbilst abām šīm prasībām, un es ar prieku turpinu izmantot šo lielisko pakalpojumu. Mēs izskatījām vairākas iespējas, bet Queue-Fair bija nepārprotams uzvarētājs cenas ziņā, un tas ir nevainojams.’
‘Lieliski! Lietotājam draudzīgs, viegli iestat āms un sāk darboties - un lieliska biznesa komunikācija! Queue-Fair lieliski darbojas, kad viss kļūst karstāks, un palīdz samazināt biļešu pārdošanas vietnes slodzi. Izveidojot Queue-Fair, domājot par lietošanas ērtumu, tas ļāva to izmantot atbalsta komandai - nav nepieciešami programmētāji!’
‘Pēc veiksmīgas CrowdCube kampaņa kampaņu mūs pārpludināja ar pieprasījumiem. Mēs vēlējāmies pārliecināties, ka nezaudējam potenciālo klientu kontaktus. Mēs bijām pārsteigti par to, cik ātri Queue-Fair varēja nodrošināt mūsu darbības uzsākšanu - tik vienkārši instalējams, izmantojot tikai vienu koda rindu!’
‘Lielisks serviss. Mēs izmantojam Queue-Fair katru mēnesi, un tas ir darbojies lieliski. Mēs zvanījām Queue-Fair svētdienas vakarā, jo mēs darījām pilienu. Viņi nekavējoties atbildēja un atrisināja problēmu piecu minūšu laikā! Viņi izglāba mūsu pilienu un visu izdarīja ļoti ātri!’
‘Kvalitatīvs produkts un uzticams serviss. Mēs bijām šokēti par to, cik ātri tas tika uzstādīts un cik viegli to bija lietot. Produkts darbojās tieši tā, kā bija paredzēts. Mēs vēlamies pateikties Queue-Fair komandai par to, ka padarīja procesu nevainojamu, un par atbalstu, kas palīdzēja mums ar iestatīšanu. Kad mums būs līdzīgi pasākumi, mēs noteikti izmantosim Queue-Fair.’
‘Pieprasījums pēc mūsu pasākuma Totally Roarsome bija milzīgs! Esmu patiešām gandarīts, ka sazinājos ar Queue-Fair. Jūs bijāt neticami izpalīdzīgi. Pāri un ārpus pienākumiem. Viņi visu sakārtoja tik ātri - pilnībā zīmolota virtuālā uzgaidāmā telpa tika izveidota tikai vienas dienas laikā, un rinda darbojās perfekti. Bez Queue-Fair mūsu rezervēšanas sistēma būtu pilnībā pārslogota. Mūsu rindā bija vairāk nekā 16 000 cilvēku. Nevar noticēt, ka rinda mums izmaksāja mazāk nekā 150 £! Liels paldies!’
‘Lielisks produkts ar izcilu klientu apkalpošanu. Queue-Fair ir bijis lielisks risinājums, lai apmierinātu strauju pieprasījumu pēc biļetēm mūsu tīmekļa vietnē. Queue-Fair tiek galā ar tīmekļa datplūsmas lēcieniem, palīdz izvairīties no servera pārslodzes un ļauj mūsu klientiem viegli redzēt, ka viņi tiek godīgi sakārtoti rindā. Mūsu klienti var sekot līdzi rindas progresam reāllaikā. Queue-Fair produkts un pakalpojums pārsniedza mūsu cerības.’
Ja zināt, cik daudz vienlaicīgu lietotāju vienlaikus apstrādā tīmekļa serveris, un vidējo darījuma laiku jeb apmeklējuma ilgumu no pirmās lapas darījuma plūsmā līdz pasūtījuma apstiprinājuma lapai, varat to pārvērst rindas ātrumā, izmantojot Little's Law, dalot lietotāju skaitu ar ilgumu, piemēram, šādi:
rindas ātrums = vienlaicīgi lietotāji / darījuma laiks
Queue-Fair piegādās apmeklētājus uz jūsu vietni jūsu norādītajā ātrumā - mums ir visprecīzākais rindas mākslīgais intelekts šajā nozarē, lai nodrošinātu, ka katru minūti tiek saņemts tieši tāds apmeklētāju skaits, kādu vēlaties, automātiski ņemot vērā cilvēkus, kuri nav klāt, kad viņu kārta tiek pieprasīta, kā arī cilvēkus, kuri atgriežas novēloti.
Kā tas izpaužas kā vienlaicīgo lietotāju skaits? Protams, ne katrs apmeklētājs, kas apmeklē jūsu vietni, aizņems precīzu vidējo darījuma laiku, lai pabeigtu savu darījumu, taču, izmantojot Queue-Fair, jūs iegūsiet ļoti stabilu vienlaicīgo lietotāju skaitu, jo pastāv lielo skaitļu likums.
Piemēram, pieņemsim, ka rindas ātrums ir 100 apmeklētāji minūtē. Mēs nosūtīsim 100 apmeklētājus uz jūsu vietni katru minūti vienmērīgā plūsmā - tas ir tas, ko mēs darām, un mēs to darām satriecoši labi. Pieņemsim arī, ka cilvēki jūsu vietni izmanto vidēji (vidēji) piecas minūtes, no kurām 70 % aizņem no 4 līdz 6 minūtēm no brīža, kad viņi tiek palaisti garām rindai, līdz brīdim, kad viņi veic pēdējo lapas pieprasījumu (neatkarīgi no tā, vai viņi pabeidz darījumu vai nē). Standarta novirze ir viena minūte uz katru pusi no vidējā rādītāja. Statistiski tas nozīmē, ka uz katru apmeklētāju, kas aizņem piecas ar pusi minūtes, būs kāds cits, kas aizņems četras ar pusi minūtes, un tāpēc šīs individuālo apmeklējumu ilguma atšķirības vairākās sesijās mēdz savstarpēji izlīdzināties, ja jebkādā veidā tiek skaitīti daudzi apmeklētāji. Lielo skaitļu likums saka, ka šī izlīdzināšanās kļūst arvien precīzāka, jo lielāks ir iesaistīto cilvēku skaits.
Cik precīzi? To mēs varam noskaidrot, izmantojot nelielu statistiku. Izlases lielums ir 5 * 100 = 500, kas šeit ir lielais skaitlis. Tieši tik daudz cilvēku jūs saskaitāt. Tas nozīmē, ka vidējā standartkļūda attiecībā uz darījuma laiku ir 1 (standartnovirze, 1 minūte), kas dalīta ar izlases lieluma kvadrātsakni (tātad ar 500 kvadrātsakni) saskaņā ar statistisko formulu par vidējo standartkļūdu, kas dod vidējo standartkļūdu attiecībā uz darījuma laiku 0,044 minūtes jeb tikai 2,7 sekundes, kas ir mazāk par vienu procentu.
Tas nozīmē, ka, ja rindas ātrums ir 100 un katra atsevišķa apmeklētāja transakcijas laiks ir 5 minūtes plus vai mīnus minūte, aptuveni 70 % no laika jūsu vietnē ir 495 līdz 505 vienlaicīgie lietotāji, tātad matemātika liecina, ka, izmantojot rindas ātrumu, jūsu tīmekļa serveriem tiks nodrošināta ļoti vienmērīga slodze.
Bet vai aprēķini ir precīzi? Šeit ir dažas nianses - piemēram, izlases lielums, ko mēs jautri aprēķinām kvadrātu veidā, ne vienmēr ir precīzi 500 katru reizi, kad tiek skaitīti vienlaicīgi lietotāji (t. i., jebkurā konkrētā laika brīdī), un arī normāls (Gausa) sadalījums var dot negatīvu transakciju laiku, kas reālajā dzīvē nenotiek. Tāpēc mēs izmantojam apmeklētāju pēc apmeklētāja, sekundi pēc sekundes, simulatoru, lai veiktu mērījumus un pārbaudītu šāda veida aprēķinus, un tas mums parāda, ka, izmantojot iepriekš minētos skaitļus, 70 % gadījumu vajadzētu sagaidīt no 493 līdz 507 apmeklētājiem, tātad matemātika turas ļoti labi! Datu mērījumi arī liecina, ka jūsu vietnē vismaz 95 % no laika būs 500 ± 15 vienlaicīgie lietotāji.
Tas, iespējams, ir stabilāk nekā precizitāte, ar kādu jūsu tīmekļa serveris var noteikt, cik daudz cilvēku izmanto jūsu vietni! Pat vēl labāk, ka pat tad, ja jums nav ne jausmas, kāds ir jūsu apmeklētāju vidējais transakcijas laiks vai standarta novirze, šie matemātiskie lielumi pastāv neatkarīgi no tā, vai jūs tos zināt vai nezināt, un jūs jebkurā gadījumā iegūsiet stabilu slodzi.
Rezultātā Queue-Fair nodrošinās vēlamo apmeklētāju skaitu minūtē ar gandrīz nevainojamu precizitāti, tādējādi nodrošinot ļoti stabilu vienlaicīgu lietotāju skaitu jūsu vietnē un stabilu tīmekļa servera noslodzi, kuru jūs pilnībā kontrolējat.
Urā!
Un tagad brīdinājums. Ir vērts atzīmēt, ka vienlaicīgo lietotāju skaita stabilitāte jūsu vietnē - un līdz ar to arī servera slodzes stabilitāte - ir būtiski atkarīga no tā, cik precīzi jūsu virtuālās uzgaidāmās telpas pakalpojumu sniedzējs katru minūti nosūta jums vēlamo apmeklētāju skaitu, un tāpēc tas ir būtisks faktors, izvēloties virtuālās uzgaidāmās telpas platformu. Tā kā mēs piedāvājam visprecīzāko Virtuālo uzgaidāmo telpu pasaulē, neviens labāk par Queue-Fair neaptur jūsu serveru plūdi.
Ko darīt, ja nezināt, cik daudz vienlaicīgu lietotāju var apkalpot serveris vai cik ilgs ir transakcijas laiks? Jūs varat apskatīt lapu, kas, iespējams, ir jūsu vājākais punkts - parasti tā ir lapa, kurā tiek noklikšķināts uz pogas "Pirkt tagad". Izmantojiet Google Analytics, lai noskaidrotu šīs lapas ikmēneša unikālo apmeklētāju skaitu vai saskaitītu ikmēneša pasūtījumus. Sadaliet to ar 30 * 24 * 60 = 43 200, kas ir minūšu skaits mēnesī (aptuveni). Tas ir jūsu vidējais apmeklētāju skaits minūtē visā mēnesī. Reiziniet to ar trīs. Tas ir jūsu vidējais apmeklētāju skaits minūtē darba laikā (aptuveni). Divkāršojiet šo skaitli. Tas, iespējams, ir drošs skaitlis, ko izmantot rindas ātruma noteikšanai.
Piemēram, pieņemsim, ka mēnesī apstrādājat 100 000 pasūtījumu - tas ir 100 000 klikšķu uz pogas "Pirkt tagad". Tas ir 100 000 / 43 200 = 2,31 pasūtījums minūtē. Paredzams, ka lielākā daļa no šiem pasūtījumiem būs dienas laikā, un naktīs jūsu serveri būs klusāki, tāpēc reiziniet šo skaitli ar 3, un tas ir 7 pasūtījumi minūtē - aptuvens aprēķins, cik noslogots ir jūsu serveris darba laikā. Ja iegūtais skaitlis ir mazāks par 50: būs pieprasījuma maksimumi un kritumi, tāpēc, ja jūsu serveris nav ievērojami lēns pīķa stundās, reiziniet šo skaitli ar 2, lai iegūtu 14 aktīvo lietotāju minūtē. Ja šis skaitlis ir lielāks par 50: minūti pa minūtei maksimumi un kritumi būs mazāki salīdzinājumā, un nav droši to dubultot. Rezultātā iegūtais skaitlis, iespējams, ir drošs rindas ātruma skaitlis, ar ko sākt, un tas atbilst tam, cik daudz pieprasījumu sekundē jūs varat droši pārvaldīt; jūs vienmēr varat to palielināt, ja konstatējat, ka jūsu sistēmas joprojām reaģē uz galalietotāju veiktspēju ar šādu ātrumu.
Ja jūsu pasūtījumi tiek atzīmēti ar laika zīmēm, varat arī apskatīt maksimālo pasūtījumu skaitu, ko esat pieņēmis vienā minūtē pēdējā mēneša laikā, taču izmantojiet to piesardzīgi, jo nezināsiet, cik daudz pasūtījumu šajā minūtē, iespējams, ir samazinājušies serveru palēnināšanās dēļ, tāpēc samaziniet to par 20 %.
Pārējā šajā rakstā ir aprakstīti daži citi rindas ātruma noteikšanas veidi.
Ir vērts norādīt, ka vispārpieņemtajā lietojumā ir vismaz divas "vienlaicīgu lietotāju" definīcijas.
Mēs izmantojam definīciju "darījumu plūsmā iesaistīto cilvēku skaits jebkurā brīdī". Tas ir galvenais skaitlis, kas jāzina, lai iestatītu rindas ātrumu. Tas norāda, cik lietotāju tieši šobrīd aplūko jūsu vietni. Vienlaicīgo sesiju skaits parasti ir nedaudz lielāks nekā vienlaicīgo savienojumu vai vienlaicīgo lietotāju skaits, jo dažas no sesijām ir laika nobīdes procesā, palielinot vidējo sesijas ilgumu.
Salīdziniet to ar vienlaicīgu pieprasījumu skaitu, kas ir tīmekļa servera apstrādājamo HTTP pieprasījumu skaits vienā laikā. Ļoti mulsinoši ir tas, ka daudzi tehniskie darbinieki, sakot " cik daudz vienlaicīgu pieprasījumu", ar to saprot "cik daudz vienlaicīgu lietotāju".
Vēl ir arī vienlaicīgi savienojumi (jeb vienlaicīgi TCP savienojumi ar vienu un to pašu servera portu tīkla interfeisa kartē), kas ir TCP/IP ligzdu skaits, kas ir atvērts servera portā vai backend pakalpojumā jebkurā laikā. Veicot lapas pieprasījumus, pārlūkprogrammas pēc noklusējuma atstāj savienojumu atvērtu gadījumam, ja lapa veic turpmākus pieprasījumus vai ja lietotājs pāriet uz citu lapu. Tādējādi tiek samazināts pieprasījumu skaits sekundē, lai atvērtu jaunus TCP/IP savienojumus, padarot servera procesu efektīvāku. Šo vienlaicīgo savienojumu laika ierobežojumi atšķiras atkarībā no pārlūkprogrammas, sākot no 60 sekundēm līdz nekad nenovēršamam savienojumam. Jūsu serveris var automātiski slēgt savienojumus arī pēc tam, kad nav notikusi nekāda darbība. Linux tīmekļa serveros ar šo komandu var iegūt vienlaicīgo savienojumu skaitu uz vienu un to pašu servera portu: netstat -aenp | grep ":80 \|:443 " | wc -l
ko varat izmēģināt, ja esat ziņkārīgs. Atkal daži cilvēki to sauc arī par "vienlaicīgiem lietotājiem", lai gan patiesībā tas nozīmē vienlaicīgus savienojumus.
Patiešām, ja jūs lūgsiet savam hostinga pakalpojumu sniedzējam norādīt maksimālo vienlaicīgo lietotāju skaitu, ko apstrādā jūsu tīmekļa serveris (cik liela ir maksimālā datplūsma), viņš, visticamāk, jums norādīs vienlaicīgu sesiju, vienlaicīgu pieprasījumu vai vienlaicīgu savienojumu skaitu, jo nezina jūsu vidējo darījuma laiku, lapu skaitu darījuma plūsmā vai citu informāciju, kas ļautu noteikt, cik daudz lietotāju vienlaicīgi apstrādā jūsu tīmekļa serveris. Visiem šiem skaitļiem ir dažādas vērtības.
Ja lūdzat informāciju par maksimālo datplūsmas līmeni savam hostinga pakalpojumu sniedzējam vai tehniskajai komandai, ir ļoti svarīgi noskaidrot, vai tiek domāts par vienlaicīgiem lietotājiem, vienlaicīgām sesijām, vienlaicīgiem pieprasījumiem vai vienlaicīgiem savienojumiem.
Lūk, kāpēc. Katra lapa ir viens HTTP pieprasījums, bet visi no jūsu tīmekļa lietojumprogrammas saņemtie attēli, skripti un citi faili, kurus pārlūkprogramma izmanto lapas parādīšanai, arī ir HTTP pieprasījumi.
Iedomāsimies, ka jūsu tehniskā komanda jums ir teikusi, ka serveris atbalsta 500 vienlaicīgus lietotājus, bet patiesībā ir domāti 500 vienlaicīgi pieprasījumi. Izmantojot 5 minūšu transakcijas laiku, jūs izmantojat iepriekš minēto formulu un pieņemat, ka jūsu vietne var apkalpot 100 apmeklētājus minūtē.
Vai tas ir iespējams? Nē.
Kad cilvēki veic darījuma plūsmu, viņi faktiski veic tikai pieprasījumus no jūsu serveriem, kamēr tiek ielādēta katra lapa. Tas ietekmē to, cik lielu datplūsmu sekundē vai cik aktīvus lietotājus var apstrādāt jūsu serveris. No piecu minūšu transakcijas laika vidējam lietotājam tās ir tikai dažas sekundes. Tāpēc jūs varētu domāt, ka 500 vienlaicīgi pieprasījumi nozīmē, ka jūs varat apstrādāt daudz vairāk vienlaicīgu lietotāju, bet jūs varat kļūdīties. Vai tagad saprotat, cik sarežģīta ir izpratne par jūsu vietnes kapacitāti attiecībā uz to, cik liela ir datplūsma vai kopējais aktīvo lietotāju skaits?
Lai noteiktu maksimālo vienlaicīgo lietotāju skaitu no maksimālā vienlaicīgo pieprasījumu kopskaita, jums ir jāzina arī.
Jūs jau droši vien zināt 1) un 2) - mūsu piemērā tas ir 6 lappuses un 5 minūtes. Jūs varat viegli saskaitīt lapas, kuras redzat, veicot darījumu. Ja nezināt vidējo darījuma laiku, to var noskaidrot Google Analytics vai arī varat pārbaudīt tīmekļa servera žurnālus.
Attiecībā uz 3) un 4) var palīdzēt pārlūkprogramma Firefox. Ar peles labo pogu noklikšķiniet uz lapas savā vietnē, izvēlieties Inspect Element (Pārbaudīt elementu) un cilni Network (Tīkls). Pēc tam nospiediet CTRL-SHIFT-R, lai pilnībā atsvaidzinātu lapu. Sarakstā redzēsiet katra lapas elementa tīkla ielādes laiku. Vēlaties pārliecināties, ka slejā Pārsūtīts varat redzēt pārsūtīšanas lielumus, jo pretējā gadījumā faili var tikt apkalpoti no kešatmiņas, kas var izjaukt jūsu aprēķinus. Iespējams, redzēsiet, ka daži skripti un citi resursi nāk no serveriem, kas nav jūsu vietne, tāpēc filtrēšanas lodziņā kreisajā pusē varat ievadīt savas vietnes domēna nosaukumu. Lai skatītu kolonnu Ilgums, noklikšķiniet ar peles labo pogu uz jebkura kolonnas nosaukuma un izvēlnē izvēlieties Timings -> Duration (Laiks -> Ilgums). Jūsu ekrānam vajadzētu izskatīties šādi:
Šīs lapas Firefox tīkla cilne, kurā redzams ilgums un pieprasījumu skaits no queue-fair.com
Failus, kas tiek izmantoti jūsu lapu attēlošanā, var iegūt no dažādām vietnēm, tāpēc vēlaties arī izmantot filtru augšējā kreisajā stūrī, lai parādītu tikai tos failus, kas ir no jūsu vietnes, bet tikai tad, ja esat pārliecināts, ka šie faili no citām vietnēm nav iemesls lēnai lapu ielādei vai daļa no sastrēgumiem.
Firefox saskaita pieprasījumus displeja apakšējā kreisajā pusē un parāda 36 HTTP pieprasījumus tikai šai vienai lapai.
Tas jādara katrai transakciju plūsmas lapai - saskaitiet kopsummu un daliet ar lapu skaitu, lai noteiktu vidējo HTTP pieprasījumu skaitu katrai lapai (3) mūsu sarakstā. Tagad jūs varat saprast, kāpēc bērnu pieprasījumu skaits katrai HTML lapai ir tik svarīgs faktors, lai noteiktu, cik lielu datplūsmu var apstrādāt jūsu tīmekļa serveris.
Attiecībā uz 4. punktu jums jāskatās slejā Ilgums un jāatrod vidējā vērtība visiem HTTP pieprasījumiem visās jūsu lapās. Ja neesat pārliecināts, pieņemiet, ka tas ir puse sekundes - jebkurā gadījumā pastāv liela nenoteiktība (sk. tālāk).
Minēsim dažus piemērus. Mēs jau minējām, ka servera procesa plūsmā ir sešas dinamiskās lapas, kas ir 1), un ka vidējais darījuma laiks ir piecas minūtes, kas ir 2). Pieņemsim, ka katrā lapā ir 36 HTTP pieprasījumi (3), un servera apstrādes laiks katram HTTP pieprasījumam ir puse sekundes, kas ir 4).
Izmantojot šos skaitļus, serveris, kas var apstrādāt 500 vienlaicīgus pieprasījumus, var apstrādāt 500 / (0,5 sekundes) = 1000 HTTP pieprasījumus sekundē, kas ir 60 000 HTTP pieprasījumu minūtē, kad tas ir pilnībā noslogots.
Piecu minūšu transakcijas laikā tas var apstrādāt 5 * 60 000 = 300 000 HTTP pieprasījumu. Šķiet daudz, vai ne?
Taču katram apmeklētājam ir sešas lapas, no kurām katra vidēji saņem 36 HTTP pieprasījumus, tātad 6 * 36 = 216 pieprasījumi.
Tātad 300 000 HTTP pieprasījumu ietilpība teorētiski var nodrošināt 300 000 / 216 = 1 389 vienlaicīgus lietotājus.
Ei, tas ir lieliski! Mēs domājām, ka rindas ātrums var būt tikai 100, bet 1389 / 5 minūtes = 278 apmeklētāji minūtē, tāpēc mēs varam nodrošināt lielāku rindas ātrumu!
Droši vien nē. Pirmkārt, jūsu apmeklētāji nesūtīs pieprasījumus precīzi pussekundes intervālos, kā pieņemts iepriekš minētajā aprēķinā. Vēl svarīgāk ir tas, ka ievades datus mērīsiet tad, kad vietne nebūs aizņemta. Atkritumi iekšā, atkritumi ārā.
Kad vietne ir aizņemta, serverim ir nepieciešams ilgāks laiks, lai apstrādātu pieprasījumus - to esat novērojuši citās vietnēs, kad ir aizņemts laiks, jo lapas tiek gaidītas ilgāk. Tas palielina vidējo laiku, kas serverim nepieciešams, lai apstrādātu vienu HTTP pieprasījumu (4), tādējādi samazinot maksimālo caurlaides spēju. Tātad ņemiet 278 apmeklētājus minūtē un samaziniet to uz pusi. Pēc tam atkal samaziniet uz pusi. Iespējams, ka maksimālās slodzes apstākļos jūs reāli sagaidāt aptuveni 70 jaunus apmeklētājus minūtē.
Citi traucējoši faktori ir arī kešēšana, kas nozīmē, ka jūsu apmeklētāju pārlūkprogrammām var nebūt jāveic katrs pieprasījums katrai lapai - tas nozīmē, ka serverim ir nepieciešams mazāk resursu un var palielināt jaunu apmeklētāju skaitu minūtē, ko var apstrādāt jūsu serveris. Slodzes balansētāji, kas sadala slodzi starp vairākiem serveriem, un statiska satura, nevis dinamisku lapu apkalpošana arī var paātrināt jūsu servera procesu, jo katram serverim ir nepieciešams mazāk resursu.
Jūs arī redzēsiet, ka ne visām lapām ir nepieciešams vienāds laiks, lai tās pabeigtu, jo dažu lapu sagatavošanai un apkalpošanai ir nepieciešams mazāk resursu nekā citu. Datubāzes meklēšana, meklēšanas vaicājumi un atjauninājumi aizņem visilgāk, tāpēc kaut kur jūsu procesā būs sastrēgums, kur cilvēki uzkrājas, gaidot, kamēr tiks apstrādāti kredītkartes dati un saglabāti pasūtījumi, vai gaidot, kamēr tiks pārbaudīta pieejamība. Katrai darījumu plūsmai ir vislēnākais posms, tāpēc vienmēr kaut kur ir šaurākais punkts, un vienmēr ir atbilde uz jautājumu, cik daudz vienlaicīgu lietotāju tīmekļa serveris var apstrādāt, un var būt vairāki ierobežojumi. Tādā gadījumā vēlaties iestatīt rindas ātrumu pietiekami zemu, lai nodrošinātu, ka serverim ir CPU laika kapacitāte, lai vienlaicīgi apstrādātu pietiekami daudz cilvēku lēnākajā procesa solī, lai cilvēki tur neuzkrātos. Pretējā gadījumā jūsu tīmekļa serveris var burtiski apstāties.
Mūsu pieredze liecina, ka, uzsākot pirmo pārdošanu, visi pārvērtē savu serveru spēju tikt galā ar lielu datplūsmu.
Ikvienam.
Precīzi noteikt vidējo sesijas ilgumu un galalietotāja veiktspēju lēnas vai maksimālas datplūsmas laikā nav domāts vājprātīgajiem. Vislabāk ir veikt pienācīgu slodzes testu, kurā "viltus" klienti, veicot slodzes testēšanu, faktiski veic pasūtījumu procesu tieši tāpat kā reālajā dzīvē, veicot tos pašus HTTP pieprasījumus tādā pašā secībā, ar tādu pašu gaidīšanas laiku starp lapām slodzes testēšanas laikā, kā reālajā dzīvē, un, palielinot virtuālo apmeklētāju skaitu, sekot līdzi procesora noslodzei, IO caurlaidspējai un atbildes laikam. Šim nolūkam varat izmantot Apache JMeter (mums patīk arī K6, ja slodze ir mazāka vai mašīnas ir lēnākas), taču neatkarīgi no izmantotā rīka ir laikietilpīgi un sarežģīti precīzi atdarināt katra atsevišķa lietotāja uzvedību (īpaši ņemot vērā kešēšanas sarežģījumus). Pat tad ņemiet savu maksimālo skaitli un samaziniet to uz pusi.
Ja šādas informācijas nav, izvēlieties piesardzību.
Izmantojot Queue-Fair portālu, jebkurā laikā varat viegli mainīt rindas ātrumu jebkurai Queue-Fair rindai. Sāciet ar 10 apmeklētājiem minūtē vai ar savu darījumu skaitu parastākā dienā, paskatieties, kā tas darbojas kādu laiku pēc biļešu pārdošanas, un, ja viss izskatās labi, procesora slodze ir zema, sql datubāze ir kārtībā un (pats galvenais) lapas reaģē, kad nospiežat CTRL-SHIFT-R, palieliniet to ne vairāk kā par 20 procentiem, nedaudz pagaidiet un atkārtojiet. Šīs "slodzes līdzsvarošanas" (redzat, ko mēs te izdarījām?) laikā jūs drīz atradīsiet faktisko vajadzīgo ātrumu, un atcerieties, ka, raugoties no klientu pieredzes viedokļa, rindas ātruma paaugstināšana ir pieņemama, jo tas samazina paredzamo gaidīšanas laiku, ko redz rindā esošie klienti, un visi ir apmierināti, redzot atbildes laiku, kas nodrošina īsāku paredzamo gaidīšanas laiku.
Vēlaties izvairīties no tā, ka rindas ātrums tiek iestatīts pārāk augsts, lai pēc tam nāktos to samazināt, jo tas a) nozīmē, ka cilvēki, kas izmanto vietni, lēni ielādē lapas, un b) palielina paredzamo gaidīšanas laiku. Visi rindā esošie cilvēki nopūtīs!
Atcerieties, ka pasūtījumu procesā būs kāds sastrēgums - katrā darījumā ir lēnākais posms - un tur veidosies vairākas sesijas. Jūs nevēlaties, lai pēc minūtes, kad sākat biļešu pārdošanu, redzētu, ka servera procesora noslodze ir krietni zemāka par maksimālo skaitli, un paaugstinātu ātrumu. Jūsu apmeklētāji, iespējams, nav tikuši līdz pogai "Pirkt tagad". Jūs vēlaties pagaidīt, kamēr jūsu sql datubāze ziņos par jauniem pasūtījumiem ar tādu pašu vai līdzīgu ātrumu kā jūsu rindas ātrums, un tad veikt mērījumus un reakcijas testus. Atcerieties, ka katru reizi, kad palielināsiet ātrumu, papildu apmeklētājiem būs nepieciešams tikpat ilgs laiks, lai sasniegtu jūsu šauru vietu, tāpēc jūs nevarēsiet precīzi novērtēt, kā jūsu serveris darbojas ar jauno ātrumu, kamēr nav pagājis šis laiks .
Mēs jau esam runājuši par to, ka pēc rindas atvēršanas rindas ātrumu vislabāk ir palielināt pakāpeniski. Iespējams, jūs zināt, ka jūsu serveriem ir noteikts limits, kuru nevar pārsniegt bez sistēmas darbības traucējumiem, un, iespējams, pat zināt, kāds ir šis limits, taču, iespējams, nezināt, ka, slodzei tuvojoties šim limitam, parasti ir ļoti maz pazīmju - bieži vien tikai dažas kļūdas vai brīdinājumi vai procesora noslodze pārsniedz 80 %.
Ja tīmekļa pakalpojumi neizdodas, tie mēdz "aizķerties" vai ļoti ātri pārstāt darboties. Parasti tas notiek tāpēc, ka, kad sistēma vairs nespēj apstrādāt pieprasījumus tik ātri, cik ātri tie tiek saņemti, veidojas iekšējās apstrādes rindas. Tad jūsu sistēmai ir jāveic darbs, kas saistīts ar iekšējo rindu apstrādi, pārvaldību un uzglabāšanu, kā arī ar pieprasījumiem, un tas ir tas, kas novirza serverus no sliekšņa. Ļoti ātri. Kad tas notiek, jūsu serveri kādu laiku var reaģēt ar kļūdas lapu, taču tas jums nepalīdz, jo apmeklētāji, kas to redz, nekavējoties nospiež atsvaidzināt, tādējādi palielinot slodzi.
Vēl pirms tam, ja apmeklētājiem lapas tiek rādītas ilgāk par aptuveni sekundi, viņi nospiež atsvaidzināt. Kad apmeklētājs nospiež atsvaidzināt, jūsu tīmekļa serveris nezina, ka apmeklētājs vairs negaida atbildi uz sākotnējo pieprasījumu. Ja tiek saņemts gan sākotnējais, gan atsvaidzināšanas pieprasījums, tīmekļa serveris apstrādās abus. Tas nozīmē vairāk darba jūsu tīmekļa serverim, vēl lēnākas atbildes visiem apmeklētājiem un vairāk cilvēku, kas nospiež atsvaidzināšanas pieprasījumu, kā rezultātā veidojas apburtais loks, kas izslēdz jūsu tīmekļa serveri, pirms tas vēl sāk sūtīt kļūdas atbildes.
Tāpēc nespiežiet serverus vairāk, nekā nepieciešams. Parasti nav vērts riskēt, lai izmantotu pēdējos 20 % procesora laika jaudas. Ja Queue-Fair portālā parādītais rindas lielums (dzeltenais gaidīšanas skaitlis un līnija diagrammās) samazinās vai pat tikai lēnāk palielinās, minūti pēc minūtes, un parādītais gaidīšanas laiks ir 50 minūtes vai mazāk, tad jūs apstrādājat pasūtījumus pietiekami ātri un rinda galu galā iztukšojas un pārstāj rādīt rindas lapas automātiski, jums pašam neko nedarot un neprasot priekšniekam paziņot, ka jūs to pārāk spiežat un sabojājat. Galu galā jūs to sasniegsiet, ja vien rindas priekšējās daļas ātrums ir lielāks nekā pievienošanās gadījumu skaits katru minūti (abi šie rādītāji ir redzami Queue-Fair portālā) - pagrieziena punkts parasti ir vismaz dažas minūtes pēc katra pasākuma. Ja jūs pārdodat ierobežota daudzuma produktu, jūs, iespējams, to izpārdosiet, pirms tiks sasniegts pagrieziena punkts.
Labā ziņa ir tā, ka, ja nejauši iestatāt pārāk augstu rindas ātrumu un serveri aizķeras, Queue-Fair var palīdzēt ātri atjaunot darbību - vienkārši aizturiet rindu, līdz serveri atkal ir gatavi apkalpot apmeklētājus. Aizturēšanas režīmā rindā esošie cilvēki redz īpašu aizturēšanas lapu, ko varat izveidot pirms tiešsaistes pasākuma. Kad rinda ir aizturēta, neviens netiek izlaists no rindas priekšas, bet jauni interneta apmeklētāji joprojām var pievienoties rindas aizmugurē, lai pēc bloķēšanas novēršanas, kas notiks ļoti ātri, jo Queue-Fair aizsargā jūsu vietni no pieprasījuma, tiktu godīgi izlaisti rindā. Aizturēšanas lapa ir labāka lietotāja pieredze nekā rindas ātruma iestatīšana ļoti zemā līmenī, jo īpaši, ja jūs to atjaunināt, norādot apmeklētājiem, kad jūs sagaidāt rindas atkārtotu atvēršanu, ko ir viegli izdarīt ar portāla lapas redaktoru, pat ja rindā jau ir simtiem tūkstošu cilvēku - un aizturēšanas režīmā jūs pat varat tos izlaist pa vienam, izmantojot Queue-Fair unikālo pogu Admit One, ja nepieciešams, kamēr jūsu sistēma atgūstas no aizturēšanas.
Tātad, ja jūsu serveriem pasākuma laikā ir nepieciešams pārtraukums, aizturēšanas lapa ir tieši tas, kas jums ir nepieciešams, turklāt tā palīdzēs jūsu serveriem ātrāk atjaunoties.
Šajā rakstā mēs esam paskaidrojuši, kāpēc uz ātrumu balstīta rinda vienmēr ir pareizākais risinājums, un esam piedāvājuši divas metodes, kā aprēķināt nepieciešamo ātrumu, taču, ja vien neesat veicis pilnīgu un precīzu virtuālo apmeklētāju slodzes testēšanu visai darījumu plūsmai un neesat par to īpaši pārliecināts, mūsu padoms vienmēr ir viens un tas pats:
Ja pārdodat ierobežota daudzuma produktu, jums nav jāpievērš uzmanība arī 7. solim.
Tas attiecas uz pirmo rindu, ja nezināt, kādu maksimālo rindas ātrumu jūsu sistēma spēj nodrošināt. Nākamajām rindām, kad būsiet izmērījis rindas ātrumu, ko jūsu sistēma faktiski spēj apstrādāt, jūs varētu atkal izmantot šo skaitli, bet tikai tad, ja jūsu sistēmā nekas nav mainījies. Praksē jūsu sistēma, iespējams, tiek pastāvīgi pilnveidota un modificēta, un jūs, iespējams, nezināt, kā nesenās izmaiņas ir ietekmējušas maksimālo rindas ātrumu, tāpēc kāpēc gan nesākt ar pusi no iepriekš izmērītā rādītāja un neatkārtot iepriekš minēto procesu?
Lūk, kā izmantot Queue-Fair, lai padarītu savu pārdošanu skaistu un drošu, un atcerieties, ka vienmēr ir labāk būt drošam, nekā nožēlot.
2004. gadā izgudrotais un patentētais Queue-Fair ir oriģinālā virtuālā uzgaidāmā telpa, kas nodrošina tiešsaistes rindu pārvaldību aizņemtām vietnēm un lietotnēm.
2024 The Fair Queue People Ltd. - Visas tiesības aizsargātas.
Daļa no rindu risinājumu saimes Orderly - OrderlyQ - OrderlyStats - WeQ4U
