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.
În mod tradițional, serverele de comerț electronic sunt dotate pentru a suporta un număr maxim de utilizatori simultani, iar sarcina este adesea definită în acest mod. Există o problemă în utilizarea acestei abordări pentru a rula o coadă de așteptare pentru un site web - o problemă pe care o rezolvăm cu rate.
Problema apare deoarece vizitatorii folosesc efectiv serverul web doar în timp ce browserul lor încarcă fiecare pagină web.
De exemplu, să spunem că un site de comerț electronic vinde bilete. De la începutul și până la sfârșitul călătoriei vizitatorului (sesiunea utilizatorului), există șase pagini, deoarece vizitatorul
Întregul proces de tranzacție durează în medie cinci minute.
Să presupunem, tot ca exemplu, că 100 de vizitatori sosesc în fiecare minut pentru a cumpăra bilete, iar timpul mediu de finalizare a procesului este de cinci minute. La un moment dat, există 500 de persoane care se află în același timp în procesul de tranzacționare, iar serverul trebuie să fie echipat pentru a suporta 500 de utilizatori simultani.
S-ar putea crede că se poate crea un contor de utilizatori simultani care este mărit de fiecare dată când un nou vizitator ajunge pe pagina de pornire și decrementat de fiecare dată când un vizitator finalizează tranzacția, iar acest lucru vă va spune câți utilizatori gestionează un singur server la un moment dat, dar acest lucru nu va funcționa.
Nu va funcționa pentru că nu toți vizitatorii finalizează tranzacția. Oamenii se răzgândesc, sau sunt distrași, sau pleacă și se întorc mai târziu. Deoarece serverul web interacționează cu vizitatorii doar atunci când browserele lor încarcă paginile, serverul web nu are cum să știe când s-a întâmplat acest lucru sau cui.
În schimb, pentru a determina că un vizitator nu mai face parte din procesul de tranzacție, serverul unic trebuie să aștepte să vadă dacă nu mai sosesc alte cereri de pagină din partea acelui vizitator și apoi să încheie sesiunea vizitatorului. Timeout-urile trebuie să fie întotdeauna setate la o durată mult mai mare decât durata medie a tranzacției (să zicem 20 de minute în acest exemplu), deoarece unii vizitatori au nevoie de mult mai mult timp decât alții pentru a-și finaliza tranzacția.
S-ar putea adăuga posibilitatea de a scădea contorul de utilizatori simultani fictiv de fiecare dată când o sesiune de vizitatori se termină în acest fel, dar acest lucru dă rezultate foarte slabe.
Dacă 10% din cei 100 de vizitatori care sosesc în fiecare minut nu își finalizează tranzacția, cei care o finalizează vor fi activi în medie timp de cinci minute, iar cei care nu o finalizează vor fi considerați activi cel puțin 20 de minute (de fapt, durata de expirare a sesiunii plus durata medie a sesiunii este mai probabilă atunci când se iau în considerare sesiunile multiple).
Asta înseamnă 90 * 5 + 10 * 20 = 650, iar serverul va raporta 650 de utilizatori simultani, chiar dacă este de fapt mai puțin ocupat!
În plus, 10 * 20 = 200 dintre acești utilizatori simultani nu folosesc de fapt site-ul și sunt în curs de a ieși din timp, ceea ce reprezintă peste 30% dintre utilizatorii simultani raportați, chiar dacă doar 10% dintre vizitatori nu reușesc să finalizeze tranzacția.
Să presupunem acum că cineva dorește să adauge o coadă la acest site web, controlată de contorul nostru de utilizatori simultani. Odată ce site-ul este la capacitate maximă, atunci o persoană care se află în fruntea cozii va fi trecută pe site numai după ce contorul va scădea. Acest lucru se numește coadă de tip "unu-la-unu-in". Ceea ce se va întâmpla este că, în 30% din timp, o persoană aflată în fruntea cozii va aștepta ca cineva care nu își va finaliza tranzacția să termine de finalizat tranzacția.
Există, de asemenea, munca suplimentară de integrare tehnică și sarcina suplimentară pe site-ul web pentru crearea și funcționarea contorului, precum și schimbul de informații cu sistemul de coadă. În cazul în care mecanismul de partajare sau de numărare nu funcționează sau se întrerupe, coada de așteptare rămâne blocată. Chiar mai rău, dacă serverul unic este atât de ocupat încât nu poate actualiza serverul de coadă pentru a-i spune acestuia să lase următoarea persoană să intre, atunci și coada rămâne blocată.
Toate aceste probleme sunt ușor și simplu de rezolvat prin trimiterea vizitatorilor din fața cozii de așteptare la o rată constantă, fixă - în acest caz 100 de vizitatori pe minut.
În acest fel, nu este nevoie să se măsoare numărul real de utilizatori simultani, nu este nevoie de o integrare complexă cu site-ul web de vânzare de bilete și nu există riscul ca coada de așteptare să se blocheze.
De aceea am inventat și patentat în 2004 Sala de așteptare virtuală bazată pe tarife pentru site-uri web aglomerate.
‘Site-ul și serviciile noastre nu au putut satisface cererea de vârf a ofertelor noastre. Queue-Fair ne-a salvat pielea! Simplu de înțeles și ușor de implementat, cu un suport excelent pe tot parcursul procesului. Acum putem să ne desfășurăm campaniile în mod fiabil, având încredere că site-ul nostru va face față.’
‘Mare platformă! Queue-Fair este foarte ușor de utilizat, cu un suport pentru clienți excelent - răspunde întotdeauna rapid și clar. Rapoartele live excelente ne-au ajutat să monitorizăm cu exactitate traficul în timpul lansărilor de evenimente și, de asemenea, a fost ușor de integrat și de marcat. Queue-Fair se asigură că toată lumea are o șansă echitabilă de a participa la evenimentele noastre, ceea ce apreciem foarte mult.’
‘Queue-Fair este sincer un produs uimitor - foarte recomandat. Îmi doresc să fi trecut mai devreme! Întregul proces până la implementare a fost unul dintre cele mai ușoare procese pe care le-am experimentat vreodată. Queue-Fair are funcții suplimentare pe care furnizorul nostru anterior nu le-a putut realiza, astfel încât schimbarea a fost ușoară. Oricine caută un produs de coadă de așteptare nu ar trebui să caute mai departe. Ne place la nebunie!’
‘Simplu și ușor de utilizat, cu un serviciu clienți excelent. Este ușor să personalizați Queue-Fair în marca dvs. Queue-Fair protejează evenimentele clienților noștri de un stampeed în timpul perioadei de vânzare.’
‘Un instrument ușor de utilizat și o echipă receptivă. În fiecare sâmbătă oferim un număr limitat de produse pentru precomandă, creând o supraîncărcare masivă și rapidă a serverului. A trebuit să găsim o soluție pentru a absorbi traficul și a fluidiza experiența de cumpărare a clienților noștri. Instrumentul a fost ușor de configurat pe site-ul meu. Documentația lor este completă și precisă.’
‘Totul a funcționat perfect! O voi folosi de fiecare dată când vom avea un vârf de trafic pentru a nu pierde niciun vizitator. Queue-Fair este cea mai ieftină soluție de pe piață. Literalmente câteva minute pentru instalare. Suport excelent și reactivitate foarte bună. Pagini ușor de editat. Cel mai bun bang pentru dolarii pe care îi puteți obține pentru a vă gestiona evenimentul critic, am fost capabil să gestionez mai mult de 10.000 de vizitatori de trafic vârf de la emisiunea TV fără cusur.’
‘Cererea pentru evenimentul nostru "Totally Roarsome" a fost peste așteptări! Mă bucur foarte mult că am apelat la Queue-Fair. Ați fost de un ajutor incredibil. Deasupra și dincolo de ceea ce vă cere datoria. Au configurat totul atât de repede - o sală de așteptare virtuală cu un brand complet în doar o zi, iar coada a funcționat perfect. Sistemul nostru de rezervare ar fi fost complet copleșit fără Queue-Fair. Am avut peste 16.000 de persoane la coadă. Nu-mi vine să cred că coada ne-a costat mai puțin de 150 de lire sterline! Vă mulțumim foarte mult!’
‘Îmi place când lucrurile funcționează pur și simplu. Totul trebuie să fie bine de prima dată - și cu Queue-Fair a fost așa! Face ceea ce am vrut să facă și a făcut-o bine. A însemnat un lucru mai puțin de care să ne facem griji într-o zi care până atunci era stresantă, iar acest lucru a meritat doar prețul de intrare. Am contactat o companie din afara Marii Britanii și m-au bombardat cu telefoane, dar Queue-Fair ne-a făcut să trecem de la contactul inițial până la implementarea completă în mai puțin de două ore - într-o sâmbătă! Sunt foarte impresionat - delirant de fericit și extaziat. Interacțiunile noastre în social media au crescut cu 800%. Perfect. Excelent. Persoana care a inventat acest lucru este un geniu!’
‘O soluție excelentă pentru coada de așteptare eficientă, susținută de profesioniști competenți și uimitori. Queue-Fair este foarte ușor de utilizat și simplu de integrat. Echipa lor ne-a ajutat la fiecare pas. Datorită Queue-Fair am reușit să le oferim utilizatorilor noștri o coadă automată care arată bine și funcționează. Ei au un tablou de bord administrativ frumos. Ne bucurăm că am găsit Queue-Fair și că ne putem baza pe ei pentru nevoile noastre de afaceri. Ne place serviciul!’
‘Queue-Fair a fost exact ceea ce aveam nevoie pentru a gestiona traficul și serviciul de asistență este minunat!. Sistemul a funcționat foarte bine! Am căutat mai multe companii și, fără îndoială, am găsit cea mai bună! Vă mulțumim foarte mult, Queue-Fair!’
‘Produs extrem de bun pentru controlul traficului. Aveam nevoie de o experiență de utilizare fără probleme în primele zile de la lansare, ceea ce a fost realizabil doar prin adăugarea Queue-Fair. Ne-a plăcut cât de ușor a fost de configurat Queue Fair în mai multe limbi. Posibilitățile de personalizare a codului au fost mari, iar noi am aliniat sala de așteptare la sistemul nostru de proiectare. Asistența a fost, de asemenea, extrem de utilă pe parcurs. Foarte recomandat. Queue-Fair și-a făcut treaba foarte bine.’
‘Exact ceea ce aveam nevoie! Feedback-ul a fost foarte bun și Queue-Fair a funcționat așa cum am avut nevoie. Dacă ai mii de oameni care apasă pe refresh la o vânzare de bilete mari, ai nevoie de o plasă de siguranță! Costurile de a avea Queue-Fair în comparație cu costurile legate de problemele cu bazele de date sau de a avea de-a face cu clienți furioși înseamnă că este un lucru de la sine înțeles. Suntem foarte mulțumiți de el!’
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
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.
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!
Ș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ă.
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ă.
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.
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.
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ă?
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
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:
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).
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.
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ă.
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.
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ă punerea în vânzare a biletelor și, dacă totul pare în regulă, încărcătura procesorului 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, creșteți-o cu cel mult 20 %, așteptați puțin și repetați. Veți găsi în curând 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 face ca așteptările estimate pe care le văd clienții din coadă să se reducă, 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!
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.
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.
Chiar și înainte de aceasta, dacă vizitatorilor le ia mai mult de o secundă să vadă paginile dvs., ei apasă Refresh. Atunci când un vizitator apasă refresh, serverul dvs. web nu știe că vizitatorul nu mai așteaptă răspunsul la cererea inițială. Dacă se primesc atât cererea originală, cât și cea de reîmprospătare, serverul dvs. web le va procesa pe amândouă. Acest lucru înseamnă mai multă muncă pentru serverul dvs. web, răspunsuri și mai lente pentru toți vizitatorii dvs. și mai mulți oameni care apasă pe refresh, ceea ce duce la un cerc vicios care distruge serverul web înainte ca acesta să înceapă să trimită răspunsuri de eroare.
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.
Î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:
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?
Deci, iată cum să folosești Queue-Fair pentru a face ca vânzarea ta să fie plăcută și sigură, și nu uita, este întotdeauna mai bine să fii în siguranță decât să-ți pară rău.
Inventat și patentat în 2004, Queue-Fair este prima sală de așteptare virtuală, care asigură gestionarea online a cozilor de așteptare pentru site-urile și aplicațiile aglomerate.
2024 The Fair Queue People Ltd. - Toate drepturile rezervate.
Face parte din familia de soluții pentru cozi Orderly - OrderlyQ - OrderlyStats - WeQ4U
