Cum se previne, prin utilizarea cozii noastre online, blocarea unui site și a unui site web - câți utilizatori simultani poate suporta un server web?

De ce să folosiți o sală de așteptare virtuală bazată pe rată?

Pe bază de rată sau unul afară, unul înăuntru? Noi analizăm avantajele și dezavantajele.

De fapt, nu am putut găsi argumente pro la "unu la ieșire, unu la intrare". Pe scurt, problema cu această abordare este că, atunci când utilizatorii sunt vizitatori ai site-urilor de comerț electronic, serverul web nu știe câți utilizatori simultani are la un moment dat. Este un obstacol în calea spectacolului. Iată de ce.

Mai târziu în acest articol, vă vom spune și cum să utilizați o cameră virtuală bazată pe rată pentru a vă proteja și site-ul.



Cea mai bine cotată sală de așteptare virtuală de pe G2
G2 este cel mai vizitat site de recenzii SaaS din lume, unde avem un scor perfect de 5.0 / 5 stele.

Ce spun clienții noștri despre Queue-Fair


test de încărcare http cât de multe cereri poate face un server web fără resurse suplimentare de server

Câți utilizatori simultani poate gestiona un server web?

Dacă știți câți utilizatori concomitenți gestionează un server web și durata medie a tranzacției sau durata medie a vizitei, de la prima pagină din fluxul de tranzacție până la pagina de confirmare a comenzii, puteți converti aceste date într-o rată de așteptare folosind legea lui Little, împărțind numărul de utilizatori la durată, astfel:

Rata de așteptare = Utilizatori simultani / Timp de tranzacție

Cât de precis este un sistem de coadă de așteptare bazat pe tarif?

Queue-Fair va livra vizitatori pe site-ul dvs. web în ritmul specificat de dvs. - avem de departe cea mai precisă inteligență artificială a cozilor din domeniu pentru a ne asigura că numărul de vizitatori pe care îl doriți în fiecare minut este numărul de vizitatori pe care îl primiți în fiecare minut, ținând cont automat de persoanele care nu sunt prezente atunci când li se solicită rândul, precum și de persoanele care se întorc târziu.

Cum se traduce acest lucru în numărul de utilizatori simultani? Desigur, nu fiecare vizitator care ajunge pe site-ul dvs. va avea nevoie de exact timpul mediu de tranzacție pentru a-și finaliza tranzacția, dar veți obține un număr foarte constant de utilizatori simultani cu Queue-Fair, datorită Legii numerelor mari.

De exemplu, să spunem că aveți o rată de așteptare de 100 de vizitatori pe minut. Vom trimite 100 de vizitatori pe site-ul dvs. în fiecare minut, într-un flux constant - asta facem și suntem extraordinar de buni la asta. Să spunem, de asemenea, că oamenii folosesc site-ul dvs. timp de cinci minute în medie (medie), iar 70% dintre ei au nevoie de între 4 și 6 minute din momentul în care sunt trecuți prin coada de așteptare și până în momentul în care fac ultima lor cerere pe pagină (indiferent dacă finalizează sau nu o tranzacție). Aceasta reprezintă o deviație standard de un minut de o parte și de alta a mediei. Din punct de vedere statistic, aceasta înseamnă că pentru fiecare vizitator care durează cinci minute și jumătate, va exista un altul care va dura patru minute și jumătate, iar aceste variații ale duratei vizitelor individuale pe parcursul mai multor sesiuni tind, prin urmare, să se anuleze reciproc atunci când numărați mai multe dintre ele în orice fel. Legea numerelor mari spune că această anulare devine din ce în ce mai exactă cu cât numărul persoanelor implicate este mai mare.

sistemul de operare numărul maxim de resurse ale serverului web
calcularea cifrei medii pentru utilizatorii simultani cu interval de încredere

Cât de exact, mai exact? Ne putem da seama de acest lucru cu ajutorul unor mici statistici. Există o dimensiune a eșantionului de 5 * 100 = 500, care este numărul mare implicat aici. Acesta este numărul de oameni pe care îi numeri. Aceasta înseamnă că eroarea standard în medie pentru timpul de tranzacție este 1 (abaterea standard, 1 minut) împărțită la rădăcina pătrată a mărimii eșantionului (deci rădăcina pătrată a 500), conform formulei statistice pentru eroarea standard în medie, ceea ce dă o eroare standard în medie pentru timpul de tranzacție de 0,044 minute, sau doar 2,7 secunde, ceea ce înseamnă mai puțin de un procent.

Acest lucru înseamnă că, cu o rată de așteptare de 100 și un timp de tranzacție de 5 minute pentru fiecare vizitator în parte, ar trebui să vă așteptați la 495 - 505 utilizatori simultani pe site-ul dvs. în aproximativ 70% din timp, astfel încât, conform calculelor matematice, utilizarea unei cozi de așteptare bazate pe rata de așteptare va asigura o încărcare constantă a serverelor dvs. web.

Dar este matematica exactă? Există câteva subtilități aici - de exemplu, dimensiunea eșantionului pe care îl ridicăm cu plăcere la pătrat nu este întotdeauna exact 500 de fiecare dată când sunt numărați utilizatorii simultani (adică în orice moment dat) și, de asemenea, o distribuție normală (gaussiană) poate da timpi de tranzacție negativi care nu apar în viața reală. Așadar, folosim un simulator vizitator cu vizitator, secundă cu secundă, pentru a face măsurători care să verifice aceste tipuri de calcule, iar acesta ne spune că, cu cifrele de mai sus, ar trebui să vă așteptați la un număr de vizitatori cuprins între 493 și 507 în 70% din timp, deci calculele rezistă remarcabil de bine! Măsurarea datelor ne spune, de asemenea, că site-ul dvs. va avea 500 ± 15 utilizatori simultani cel puțin 95% din timp.

Acest lucru este probabil mai stabil decât acuratețea cu care serverul dvs. web poate măsura numărul de persoane care vă folosesc site-ul! Chiar mai bine, ceea ce este cu adevărat interesant aici este că, chiar dacă nu aveți idee care este timpul mediu de tranzacție sau abaterea standard pentru vizitatorii dvs., aceste cantități matematice există, indiferent dacă le cunoașteți sau nu, și veți obține oricum o încărcare stabilă.

Rezultatul este că Queue-Fair vă va oferi numărul de vizitatori pe minut pe care îl doriți cu o precizie aproape perfectă, ceea ce duce la un număr foarte constant de utilizatori simultani pe site-ul dvs. și la o sarcină stabilă a serverului web asupra căreia aveți control total.

Ura!


servers capacity can be exceeced with inaccurate queues Și acum un avertisment. Merită să rețineți că stabilitatea numărului de utilizatori simultani de pe site-ul dvs. și, prin urmare, stabilitatea încărcăturii serverului dvs. depinde în mod critic de cât de precis vă trimite furnizorul de săli de așteptare virtuale numărul de vizitatori pe care îl doriți în fiecare minut și, prin urmare, acesta este un factor cheie atunci când alegeți o platformă de săli de așteptare virtuale. Pentru că oferim cea mai precisă Cameră de Așteptare Virtuală din lume, nimeni nu oprește mai bine decât Queue-Fair inundațiile serverelor dumneavoastră.

O modalitate ușoară de a calcula rata de așteptare

Ce se întâmplă dacă nu știți câți utilizatori simultani poate gestiona un server sau timpul de tranzacție? Vă puteți uita la pagina care este probabil să fie gâtul de gâtul de la intrare - de obicei cea care este rezultatul unui click pe un buton "Cumpără acum". Folosiți Google Analytics pentru a afla numărul lunar de vizitatori unici ai acelei pagini sau numărați comenzile lunare. Împărțiți acest rezultat la 30 * 24 * 60 = 43 200, care reprezintă numărul de minute dintr-o lună (aproximativ). Aceasta este media vizitatorilor dvs. pe minut pe întreaga lună. Înmulțiți acest lucru cu trei. Aceasta este media vizitatorilor dvs. pe minut în timpul orelor de lucru (aproximativ). Dublați această valoare. Aceasta este, probabil, o cifră sigură pentru rata de așteptare care trebuie utilizată.

De exemplu, să presupunem că procesați 100 000 de comenzi pe lună, ceea ce înseamnă 100 000 de clicuri pe butonul "Cumpără acum". Asta înseamnă 100.000 / 43.200 = 2,31 comenzi pe minut. V-ați aștepta ca majoritatea acestor comenzi să fie în timpul zilei, iar serverele dvs. să fie mai liniștite noaptea, așa că înmulțiți acest lucru cu 3 și rezultă 7 comenzi pe minut ca o estimare aproximativă a cât de ocupat este serverul dvs. în timpul orelor de lucru. În cazul în care cifra rezultată este mai mică de 50: vor exista vârfuri și minime ale cererii, astfel încât, dacă serverul dvs. nu este vizibil lent în orele de vârf, înmulțiți această cifră cu 2 pentru a obține 14 utilizatori activi pe minut. În cazul în care cifra este mai mare de 50: vârfurile și depresiunile de la minut la minut vor fi mai mici în comparație și nu este sigur să dublați această cifră. Cifra cu care ajungeți la final este probabil o cifră sigură pentru rata de așteptare la coadă pentru început și corespunde numărului de solicitări pe secundă pe care le puteți gestiona în siguranță; puteți oricând să o măriți dacă descoperiți că sistemele dvs. sunt încă receptive pentru performanța utilizatorilor finali la această rată.

calcularea nivelurilor maxime de utilizatori activi pentru aplicația dvs. web

Dacă comenzile dvs. sunt marcate în timp, puteți, de asemenea, să vă uitați la numărul maxim de comenzi pe care le-ați luat într-un singur minut în ultima lună - dar folosiți-o cu prudență, deoarece nu veți ști câte comenzi ați pierdut în acest minut din cauza încetinirii serverelor dvs., așa că reduceți acest număr cu 20%.

În restul articolului sunt discutate alte modalități de calculare a ratei de așteptare.

confuzie cu privire la utilizatorii simultani conexiuni simultane sesiuni simultane și durata medie a sesiunii

Te-am prins #1: Utilizatori concomitenți vs Solicitări concomitente vs Conexiuni concomitente vs Sesiuni concomitente

Merită subliniat faptul că există cel puțin două definiții ale termenului "utilizatori simultani" în uzul comun.

Noi folosim definiția "numărul de persoane implicate într-un flux de tranzacții la un moment dat". Acesta este numărul cheie pe care trebuie să îl cunoașteți pentru a seta rata de așteptare. Acesta este numărul de utilizatori care vizualizează site-ul dvs. în acest moment. Numărul de sesiuni concurente este, de obicei, ceva mai mare decât numărul de conexiuni concurente sau de utilizatori concurențiali, deoarece unele dintre sesiuni sunt în curs de expirare, ceea ce mărește durata medie a sesiunii.

Comparați acest lucru cu numărul de cereri concurente, care reprezintă numărul de cereri HTTP procesate de serverul dvs. web la un moment dat. În mod foarte confuz, mulți tehnicieni se referă la numărul de cereri concurente atunci când spun numărul de utilizatori concurențiali.

Apoi, există Conexiuni concurente (sau conexiuni TCP concurente la același port de server de pe placa de interfață de rețea), care reprezintă numărul de Socket-uri TCP/IP deschise pe portul serverului sau pe serviciul backend la un moment dat. Atunci când fac cereri de pagină, browserele vor lăsa implicit conexiunea deschisă în cazul în care pagina face alte cereri sau utilizatorul trece la o altă pagină. Acest lucru reduce numărul de solicitări pe secundă pentru deschiderea de noi conexiuni TCP/IP, făcând procesul serverului mai eficient. Timpul de așteptare pentru aceste conexiuni concurente variază în funcție de browser, de la 60 de secunde până la "never-close". De asemenea, serverul dvs. poate închide automat conexiunile după o perioadă de neactivitate. Pe serverele web Linux, puteți obține o numărătoare a conexiunilor concurente la același port al serverului cu această comandă:

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

pe care îl puteți încerca dacă sunteți curios. Din nou, unii oameni numesc acest lucru și "utilizatori simultani", când de fapt înseamnă conexiuni simultane.

Într-adevăr, dacă îi cereți furnizorului dvs. de servicii de găzduire să vă spună numărul maxim de utilizatori simultani pe care îl gestionează serverul dvs. web (cât de mult trafic de vârf), probabil că vă va da de fapt o cifră pentru sesiuni simultane, cereri simultane sau conexiuni simultane, pentru simplul motiv că nu cunoaște timpul mediu de tranzacție, numărul de pagini din fluxul de tranzacții sau orice alte informații care i-ar permite să vă spună câți utilizatori simultani gestionează serverul dvs. web. Toate aceste numere au valori diferite.

Dacă solicitați furnizorului de găzduire sau echipei tehnice informații despre nivelurile maxime de trafic, este foarte important să clarificați dacă se referă la utilizatori simultani, sesiuni simultane, cereri simultane sau conexiuni simultane.

Dacă greșești acest lucru, site-ul tău web se poate prăbuși!

Iată de ce. Fiecare pagină este o singură cerere HTTP, dar toate imaginile, scripturile și alte fișiere care provin din aplicația dvs. web și pe care browserul le utilizează pentru a afișa pagina sunt, de asemenea, cereri HTTP.

Să ne imaginăm că echipa de tehnicieni v-a spus că serverul acceptă 500 de utilizatori simultani, dar de fapt se referă la 500 de cereri simultane. Având în vedere timpul de tranzacție de 5 minute, utilizați formula de mai sus și presupuneți că site-ul dvs. poate suporta 100 de vizitatori pe minut.

Se poate? Nu.

Pe măsură ce oamenii parcurg fluxul de tranzacție, aceștia fac doar cereri de la serverele dvs. în timp ce se încarcă fiecare pagină. Acest lucru afectează traficul pe secundă sau numărul de utilizatori activi pe care îl poate gestiona serverul dvs. Din timpul de tranzacție de cinci minute, asta înseamnă doar câteva secunde pentru un utilizator mediu. Prin urmare, ați putea crede că 500 de cereri concurente înseamnă că puteți gestiona mult mai mulți utilizatori concurențiali, dar s-ar putea să vă înșelați. Puteți vedea acum cum înțelegerea capacității site-ului dvs. web în termeni de trafic sau de număr total de utilizatori activi este o afacere atât de complicată?

siguranța în primul rând pentru resursele serverului dvs. atunci când calculați câte solicitări pot primi paginile dvs. web pentru o experiență bună pentru fiecare utilizator în parte.

Conversia cererilor concurente în utilizatori concurențiali

Pentru a calcula numărul maxim de utilizatori concurențiali din numărul total maxim de cereri concurente, trebuie să știți și următoarele

  1. Numărul de pagini din fluxul de tranzacții
  2. Timpul mediu de tranzacție al vizitatorilor de la prima la ultima pagină din fluxul dvs.
  3. Câte cereri compun fiecare pagină, în medie
  4. Timpul mediu necesar pentru ca serverul dvs. să proceseze o singură cerere HTTP

Probabil că știți deja 1) și 2) - în exemplul nostru sunt 6 pagini și 5 minute. Puteți număra cu ușurință paginile pe care le vedeți în timpul unei tranzacții. Dacă nu cunoașteți durata medie a tranzacției, Google Analytics vă poate spune sau puteți verifica jurnalele serverului dvs. web.

Pentru punctele 3) și 4), browserul Firefox vă poate ajuta. Faceți clic dreapta pe o pagină de pe site-ul dvs., alegeți Inspect Element și fila Network (Rețea). Apoi apăsați CTRL-SHIFT-R pentru a reîmprospăta complet pagina. Veți vedea în listă timpii de încărcare a rețelei pentru fiecare element al paginii. Trebuie să vă asigurați că puteți vedea dimensiunile de transfer în coloana Transferred (Transferat), deoarece, în caz contrar, este posibil ca fișierele să fie servite dintr-o memorie cache, ceea ce vă poate încurca calculele. S-ar putea să vedeți că unele scripturi și alte resurse provin de pe alte servere decât site-ul dumneavoastră, așa că puteți introduce numele de domeniu al site-ului dumneavoastră în caseta de filtrare din stânga. Pentru a vedea coloana Duration (Durata), faceți clic dreapta pe orice antet de coloană și selectați Timings -> Duration (Timpi -> Durată) din meniul pop-up. Ecranul dvs. ar trebui să arate astfel:

google procesează un nginx configurat corespunzător cu google analytics pentru încărcarea imaginilor

Fila Firefox Network pentru această pagină, care arată durata și numărul de cereri de la queue-fair.com

Fișierele utilizate în afișarea paginilor dvs. pot proveni de pe mai multe site-uri diferite, așa că doriți să utilizați și filtrul din stânga sus pentru a le afișa doar pe cele de pe site-ul dvs. - dar numai dacă sunteți sigur că acele fișiere de pe alte site-uri nu sunt motivul încărcării lente a paginilor sau nu fac parte din blocajul dvs.

Firefox numără solicitările în partea din stânga jos a ecranului și arată 36 de solicitări HTTP doar pentru această pagină.

Trebuie să faceți acest lucru pentru fiecare pagină din fluxul de tranzacții - numărați totalul și împărțiți-l la numărul de pagini pentru a afla numărul mediu de solicitări HTTP pentru fiecare pagină, numărul 3) din lista noastră. Puteți vedea acum de ce numărul de cereri copil pentru fiecare pagină HTML este un factor cheie pentru cât de mult trafic poate suporta serverul dvs. web.

Pentru numărul 4), trebuie să vă uitați la coloana Durata și să găsiți media tuturor cererilor HTTP pentru toate paginile dvs. Dacă nu sunteți sigur, presupuneți o jumătate de secundă - există oricum o mare incertitudine în acest sens (a se vedea mai jos).

efectuarea calculelor matematice pentru a calcula câte sesiuni în același timp, câți utilizatori și câte cereri pe secundă pe aplicația dvs. web, fie că este vorba de un singur server sau de conținut static.

Făcând calculele

Să dăm câteva exemple de cifre. Am spus deja că există șase pagini dinamice în fluxul de proces al serverului de exemplu, ceea ce înseamnă 1), și că timpul mediu de tranzacție este de cinci minute, ceea ce înseamnă 2). Să presupunem 36 de solicitări HTTP pe pagină pentru 3) și o jumătate de secundă pentru timpul de procesare a serverului pentru fiecare solicitare HTTP, ceea ce reprezintă 4).

Cu aceste cifre, un server care poate gestiona 500 de solicitări concurente poate gestiona 500 / (0,5 secunde) = 1000 de solicitări HTTP pe secundă, ceea ce înseamnă 60.000 de solicitări HTTP pe minut, atunci când este complet la maxim.

În timpul unei tranzacții de cinci minute, acesta poate gestiona 5 * 60 000 = 300 000 de cereri HTTP. Pare mult, nu-i așa?

Dar, pentru fiecare vizitator, există șase pagini cu o medie de 36 de solicitări HTTP fiecare, deci 6 * 36 = 216 solicitări.

Deci, capacitatea de 300.000 de cereri HTTP poate , în teorie, să gestioneze 300.000 / 216 = 1.389 de utilizatori simultani.

Te-am prins #2: Serverele Web devin mai lente cu încărcare

Hei, asta e grozav! Am crezut că putem avea o rată de așteptare de doar 100, dar 1.389 / 5 minute = 278 de vizitatori pe minut, deci putem avea o rată de așteptare mai mare!

Ei bine, probabil că nu. În primul rând, vizitatorii dvs. nu vor trimite cereri la intervale de exact o jumătate de secundă, așa cum presupune calculul de mai sus. Mai important, veți fi măsurat datele de intrare atunci când site-ul nu este ocupat. Gunoiul intră, gunoiul iese.

Atunci când site-ul este ocupat, serverul are nevoie de mai mult timp pentru a procesa cererile - ați observat acest lucru pe alte site-uri atunci când lucrurile sunt ocupate, că așteptați mai mult timp pentru pagini. Acest lucru mărește timpul mediu de care are nevoie serverul pentru a procesa o singură solicitare HTTP (4), ceea ce diminuează debitul maxim. Așadar, luați cei 278 de vizitatori pe minut și înjumătățiți-i. Apoi înjumătățiți-l din nou. Probabil că, în mod realist, aveți în vedere aproximativ 70 de vizitatori noi pe minut la încărcare maximă.

cu cât încărcătura mai mare din cauza vârfurilor de trafic este mai mare, cu atât mașinile devin mai lente.

Alți factori de confuzie includ memoria cache, ceea ce înseamnă că browserele vizitatorilor dvs. nu trebuie să facă fiecare cerere pentru fiecare pagină în parte - acest lucru înseamnă că serverul are nevoie de mai puține resurse și poate crește numărul de vizitatori noi pe minut pe care serverul dvs. îl poate gestiona. Balansatoarele de sarcină care distribuie sarcina pe mai multe servere și servirea de conținut static mai degrabă decât de pagini dinamice pot, de asemenea, să accelereze procesul serverului dumneavoastră, deoarece fiecare server necesită mai puține resurse.

De asemenea, veți constata că nu toate paginile necesită același timp pentru a fi completate, deoarece unele necesită mai puține resurse decât altele pentru a fi produse și servite. Căutările în bazele de date, interogările de căutare și actualizările durează cel mai mult, așa că veți avea un blocaj undeva în procesul dumneavoastră, unde oamenii se îngrămădesc, așteptând ca detaliile cardului de credit să fie procesate și comenzile stocate sau așteptând să fie verificată disponibilitatea. Fiecare flux de tranzacție are o etapă cea mai lentă, astfel încât există întotdeauna un gât de gâtul de gâtul undeva, și există întotdeauna un răspuns la întrebarea câți utilizatori simultani poate gestiona un server web - și pot exista mai multe limite implicate. În acest caz, trebuie să setați rata de așteptare suficient de mică pentru a vă asigura că serverul dumneavoastră are capacitatea de timp cpu pentru a procesa suficient de mulți utilizatori concomitent pentru cea mai lentă etapă a procesului, astfel încât oamenii să nu se îngrămădească acolo. În caz contrar, serverul dvs. web se poate bloca literalmente.

incert cum să estimeze capacitatea serverelor resursele serverului pentru fiecare utilizator în parte

Deci, ce fac?

Experiența noastră este că, la prima vânzare, toată lumea supraestimează capacitatea serverelor lor de a face față unor volume mari de trafic.

Toată lumea.

Identificarea precisă a duratei medii a sesiunii și a performanței utilizatorului final în timpul unui trafic lent sau de vârf nu este pentru cei slabi de inimă. Cel mai bine este să efectuați un test de încărcare adecvat, cu clienți "falși" care trec prin procesul de comandă în timpul testului de încărcare exact ca în viața reală, efectuând aceleași cereri HTTP în aceeași ordine, cu aceleași așteptări între pagini în timpul testului de încărcare ca în viața reală, și să urmăriți sarcina procesorului, debitul IO și timpii de răspuns pe măsură ce creșteți numărul de vizitatori virtuali. Puteți folosi Apache JMeter pentru acest lucru (ne place și K6 pentru sarcini mai ușoare sau pentru mașini mai lente), dar indiferent de instrumentul pe care îl folosiți, este consumator de timp și complicat să imitați comportamentul fiecărui utilizator în mod exact (mai ales cu complexitatea memoriei cache). Chiar și așa, luați numărul maxim și înjumătățițiți-l.

În absența acestor informații, alegeți să fiți mai prudent.

Puteți modifica cu ușurință rata de așteptare pentru orice coadă Queue-Fair în orice moment, utilizând portalul Queue-Fair. Începeți cu 10 vizitatori pe minut sau cu rata de tranzacționare într-o zi mai normală, vedeți cum merge pentru o perioadă de timp după ce biletele dvs. au fost puse în vânzare și, dacă totul arată bine, încărcătura procesorului dvs. este scăzută, baza de date sql este bună și (mai presus de toate) paginile dvs. sunt receptive atunci când apăsați CTRL-SHIFT-R, dublați-o, așteptați puțin și repetați. În curând veți găsi rata reală de care aveți nevoie în timpul acestei "echilibrări a încărcăturii" (vedeți ce am făcut acolo?) și nu uitați că, din punctul de vedere al experienței clienților, este bine să creșteți rata de așteptare, deoarece acest lucru determină reducerea așteptărilor estimate pe care le văd clienții din coadă, iar toată lumea este fericită să vadă un timp de răspuns care oferă o așteptare estimată mai scurtă.

Ceea ce doriți să evitați este să setați rata de așteptare prea mare și apoi să vă aflați în situația de a o reduce, deoarece acest lucru a) înseamnă că persoanele care utilizează site-ul se confruntă cu încărcări lente ale paginilor și b) determină creșterea așteptărilor estimate. Toate persoanele din coada de așteptare vor suspina!

Te-am prins #3: Creșterea prea rapidă a ratei după deschiderea unei cozi de așteptare

Nu uitați că veți avea un blocaj undeva în procesul de comandă - fiecare tranzacție are un pas mai lent - și veți avea mai multe sesiuni care se vor acumula acolo. Ceea ce nu vreți să faceți este să ajungeți la un minut de la începerea vânzării biletelor, să vedeți că sarcina procesorului serverului dvs. este mult sub numărul său maxim și să măriți rata. Vizitatorii dvs. probabil că nu au ajuns până la butonul "Cumpără acum". Vreți să așteptați până când baza de date sql raportează comenzi noi la o rată egală sau similară cu rata de așteptare și faceți măsurătorile și testele de răspuns atunci. Nu uitați că, de fiecare dată când creșteți rata, vizitatorilor suplimentari le va lua același timp pentru a ajunge la gâtul de îmbulzeală, astfel încât nu veți putea evalua cu exactitate modul în care serverul dvs. funcționează la noua rată decât după ce acest timp s-a scurs.

încetinește decizia de a consuma resursele serverului
serverele se deschid atunci când capacitatea serverelor este depășită

Te-am prins #4: Snapping serverele dvs.

Am discutat deja despre cum este cel mai bine să creșteți treptat rata de așteptare după deschiderea cozii. Probabil că știți că serverele dvs. au o limită care nu poate fi depășită fără ca sistemul să se blocheze și poate chiar știți care este această limită - dar ceea ce poate nu știți este că, pe măsură ce sarcina se apropie de această limită, există de obicei foarte puține semne - adesea doar câteva erori sau avertismente, sau o sarcină a procesorului de peste 80%.

Atunci când serviciile web nu reușesc, acestea au tendința de a "ceda" sau de a se bloca foarte repede. În mod normal, acest lucru se datorează faptului că, odată ce sistemul dvs. nu mai poate procesa cererile la fel de repede cum vin, se formează cozi interne de procesare. Sistemul dvs. trebuie apoi să facă munca de procesare, gestionare și stocare a cozilor interne, precum și a cererilor, iar acest lucru face ca serverele să se prăbușească. Foarte rapid. Odată ce se întâmplă acest lucru, serverele dvs. pot răspunde pentru o perioadă de timp cu o pagină de eroare, dar acest lucru nu vă ajută, deoarece vizitatorii care o văd vor apăsa imediat butonul Refresh, ceea ce va agrava sarcina.

Așadar, nu vă forțați serverele mai mult decât este necesar. De obicei, nu merită să riscați să obțineți acel ultim 20% din capacitatea de timp de procesare. Dacă dimensiunea cozii de așteptare afișată în portalul Queue-Fair (cifra și linia galbenă de așteptare din diagrame) scade sau chiar crește mai încet, minut cu minut, iar timpul de așteptare afișat este de 50 de minute sau mai puțin, atunci procesați comenzi suficient de repede și coada se va goli în cele din urmă și nu va mai afișa automat Queue Pages, fără ca dumneavoastră să trebuiască să faceți ceva și fără ca dumneavoastră să îi spuneți șefului dumneavoastră că ați forțat prea tare și ați stricat-o. Veți ajunge acolo în cele din urmă, atât timp cât viteza Front of the Queue este mai mare decât numărul de Join-uri la fiecare minut (ambele fiind afișate în Portalul Queue-Fair) - punctul de cotitură este, de obicei, după cel puțin câteva minute de la fiecare eveniment. Dacă vindeți un produs în cantitate limitată, probabil că veți vinde toate produsele înainte de a fi atins punctul de cotitură.

Vestea bună este că, dacă din greșeală setați rata de așteptare prea mare și serverele dvs. se blochează, Queue-Fair vă poate ajuta să vă reveniți rapid - doar puneți coada în așteptare până când serverele dvs. sunt gata să primească din nou vizitatori. În modul Hold, persoanele din coadă văd o pagină specială Hold pe care o puteți proiecta înainte de evenimentul dvs. online. Nimeni nu este lăsat să treacă din fața cozii atunci când aceasta este în Hold, dar noii vizitatori de pe internet se pot înscrie în continuare la coadă în spate, pentru a fi plasați la coadă în mod echitabil odată ce blocajul este eliminat, ceea ce se va întâmpla foarte repede, deoarece Queue-Fair vă protejează site-ul de cerere. Pagina de așteptare este o experiență de utilizare superioară setării ratei de așteptare foarte scăzută, mai ales dacă o actualizați pentru a le spune vizitatorilor la ce oră vă așteptați să se redeschidă coada, ceea ce este ușor de făcut cu editorul paginii Portal, chiar și atunci când sute de mii de oameni sunt deja în coadă - iar în modul Hold puteți chiar să-i lăsați să treacă pe rând cu butonul unic Admit One al Queue-Fair, dacă este nevoie, până când sistemul dumneavoastră își revine din blocaj.

Așadar, dacă serverele dvs. au nevoie de o pauză în timpul evenimentului, pagina de așteptare este exact ceea ce aveți nevoie și, în plus, vă va ajuta serverele să își revină mai repede.

Concluzie

În acest articol am explicat de ce o coadă de așteptare bazată pe rată este întotdeauna calea de urmat și am oferit două metode de calculare a ratei de care aveți nevoie, dar dacă nu ați efectuat teste complete și precise de încărcare a vizitatorilor virtuali pe întregul flux de tranzacții și nu sunteți foarte foarte foarte foarte sigur de acest lucru, sfatul nostru este același:

  1. Începeți cu o rată de așteptare setată la 10, sau rata de tranzacționare într-o zi normală.
  2. Urmăriți încărcarea procesorului și alți indicatori de performanță.
  3. Așteptați până când comenzile noi sunt înregistrate în baza de date SQL la o rată egală sau similară cu rata de așteptare.
  4. Apăsați CTRL-SHIFT-R pe paginile dvs. pentru a verifica capacitatea de răspuns.
  5. Creșteți rata de așteptare cu cel mult 20%.
  6. Reveniți la pasul 2 și așteptați din nou.
  7. Odată ce dimensiunea cozii de așteptare scade sau crește în mod constant și mai puțin rapid în fiecare minut, iar timpul de așteptare afișat este mai mic de 50 de minute, nu este nevoie să se accelereze.
  8. Stați jos și relaxați-vă! Queue-Fair vă acoperă.

Dacă vindeți un produs în cantități limitate, nu trebuie să acordați atenție nici pasului 7.

Aceasta este pentru prima coadă de așteptare, atunci când nu cunoașteți rata maximă reală a cozii de așteptare pe care o poate suporta sistemul dumneavoastră. Pentru cozile de așteptare ulterioare, odată ce ați măsurat rata de așteptare pe care sistemul dvs. o poate suporta, ați putea utiliza din nou aceeași cifră - dar numai dacă nu s-a schimbat nimic în sistem. În practică, sistemul dvs. este probabil în continuă dezvoltare și modificare și este posibil să nu știți cum au afectat modificările recente rata maximă a cozii de așteptare - așa că de ce nu începeți cu jumătate din cifra măsurată anterior și repetați procesul de mai sus?

Nu uitați, este întotdeauna mai bine să fii în siguranță decât să-ți pară rău.


Sute de organizații de top au încredere în
soluțiile
noastre pentru
cozi de așteptare

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

Soluția simplă la creșterile de trafic pe internet

Începeți