Kāpēc izmantot uz tarifiem balstītu virtuālo uzgaidāmo telpu?

Cik daudz vienlaicīgu lietotāju var apkalpot tīmekļa serveris?

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

Cik precīza ir uz likmēm balstīta rindu sistēma?

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.

Vienkāršs veids, kā aprēķināt rindas ātrumu

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.

Gotcha #1: Vienlaicīgi lietotāji vs Vienlaicīgi pieprasījumi vs Vienlaicīgi savienojumi vs Vienlaicīgi sesijas

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.

Ja to izdarīsiet nepareizi, jūsu tīmekļa vietne var sabrukt!

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?

Vienlaicīgu pieprasījumu pārveidošana par vienlaicīgiem lietotājiem

Lai noteiktu maksimālo vienlaicīgo lietotāju skaitu no maksimālā vienlaicīgo pieprasījumu kopskaita, jums ir jāzina arī.

1. Darījuma plūsmas lapu skaits
2. Vidējais apmeklētāja transakcijas laiks no pirmās lapas līdz pēdējai jūsu plūsmas lapai.
3. Cik pieprasījumu vidēji veido katru lapu
4. Vidējais laiks, kas serverim nepieciešams, lai apstrādātu vienu HTTP pieprasījumu.

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

Matemātikas aprēķināšana

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.

Gotcha #2: Tīmekļa serveri kļūst lēnāki ar slodzi

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.

Ko man darīt?

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!

Gotcha #3: Pārāk ātra likmes palielināšana pēc rindas atvēršanas

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 .

Gotcha #4: Serveru pieslēgšana

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.

Secinājums

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

1. Sāciet ar rindas likmi, kas iestatīta uz 10, vai ar savu darījumu likmi parastākā dienā.
2. Uzmanieties par procesora slodzi un citiem veiktspējas rādītājiem.
3. Pagaidiet, līdz jauni pasūtījumi tiek reģistrēti jūsu sql datubāzē ar tādu pašu vai līdzīgu ātrumu kā rindas ātrums.
4. Nospiediet CTRL-SHIFT-R uz lapām, lai pārbaudītu reaģēšanas spēju.
5. Palieliniet rindas ātrumu ne vairāk kā par 20%.
6. Atgriezieties pie 2. soļa un vēlreiz pagaidiet.
7. Tiklīdz rindas lielums samazinās vai pakāpeniski palielinās mazāk strauji katru minūti un norādītais gaidīšanas laiks ir mazāks par 50 minūtēm, nav nepieciešams to paātrināt.
8. Atpūtieties un atpūtieties! Queue-Fair ir par jums parūpējies.

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.