Ce este testarea de sarcină? Sub Încărcare maximă: O prezentare generală a programelor de testare a sarcinii serverului web. Determinarea vitezei maxime de răspuns

Noi software și alte produse de înaltă tehnologie apar în mod regulat pe piața IT modernă. Determinarea gradului de comparabilitate pentru rezolvarea unor probleme specifice, în ce măsură și dacă acestea sunt suficient de sigure pentru a fi utilizate este posibilă numai în modul de testare a sarcinii - un serviciu furnizat de Compania de inginerie Getbug.

Testare stresanta(Engleză) Testare de sarcină) - procesul de încărcare deliberată a unui sistem prin transmiterea multor solicitări către sistemul sau dispozitivul însuși, pentru a determina indicatorii de performanță, timpul de răspuns și pentru a verifica conformitatea cu cerințele care au fost prezentate acestui sistem sau dispozitiv individual

Etape de testare a sarcinii

Dezvoltarea și aprobarea modelelor de sarcină. Pentru model se selectează operațiunile critice pentru acest tip de testare și se determină intensitatea executării lor în test. Profilurile de încărcare sunt determinate dacă aplicația testată are modele de comportament diferite. Punctele de încărcare sunt calculate.
Pentru operațiunile simulate, sunt dezvoltate scripturi de încărcare și sunt create pool-urile de date necesare.
Sunt dezvoltate scenarii de execuție a scripturilor care corespund profilurilor modelului de încărcare.
Se verifică funcționarea scripturilor în scenarii. Este necesar să se execute fiecare script inclus în script folosind cel puțin mai mulți utilizatori virtuali din grup pentru a elimina erorile de influență reciprocă a scripturilor unul asupra celuilalt. Scripturi cu corelație insuficient de bine realizată pot fi găsite și aici.

Testarea de încărcare online

De ce aveți nevoie de testarea încărcării site-ului? Încărcarea pe găzduirea sau serverul site-ului dvs. este în creștere și poate crea o încărcare care va fi critică pentru funcționarea site-ului. Efectuăm teste de stres pentru a preveni astfel de probleme folosind un test de stres cuprinzător. Activitatea principală a companiei vizează monitorizarea calității produselor de înaltă tehnologie dezvoltate pe tot parcursul ciclului de viață al dezvoltării acestora. Serviciile solicitate sunt probleme de studii de testare a interacțiunii dintre o persoană și un produs software, testarea sarcinii funcționale și testarea securității software.

C ate testul de sarcină:

Evaluarea performanței și operabilității aplicației în stadiul de dezvoltare și transfer în exploatare;
Evaluarea performanței și funcționalității aplicației în etapa de lansare a noilor versiuni;
Optimizarea performanței aplicațiilor, reglarea serverelor și optimizarea codului
Selectarea hardware-ului (platformă software) și a configurației serverului adecvate pentru o anumită aplicație

Echipamentul bancului de testare trebuie să se potrivească cât mai bine cu configurația de producție. Mai ales dacă deciziile de afaceri sunt luate pe baza timpilor de funcționare obținuți în urma testării. Dacă vorbim de optimizarea unei aplicații, atunci potrivirea configurațiilor bancului de testare și a celei industriale nu mai este atât de relevantă. Pentru a monitoriza serverele de testare, trebuie să aveți acces la serverele cu drepturi pentru a utiliza utilitățile necesare, de exemplu, MS Windows Performance pentru MS Windows sau sar, iostat, vmstat pentru sistemul de operare Unix.

Încărcați instrumente și scenarii de testare

Primele execuții de teste sunt execuții de probă și vă permit să înțelegeți comportamentul sistemului în ansamblu: funcționarea aplicației și a hardware-ului. Este necesar să începeți testarea din punctele de încărcare cu o sarcină mai mică, mișcându-se pe măsură ce sarcina crește de la mai jos la mai mare. În timpul testării, numărul de puncte de încărcare se poate modifica și numărul de utilizatori virtuali care intră într-un anumit punct de încărcare se poate modifica. Rezultatele testelor trebuie să fie consecvente din punct de vedere logic și pe măsură ce sarcina crește, rezultatele timpului de execuție a operațiunilor și sarcina echipamentului de testare trebuie să se modifice în mod corespunzător. Dacă rezultatele sunt mai bune la un punct de încărcare cu o sarcină mai mare, atunci un astfel de experiment trebuie efectuat din nou pentru a înțelege motivele unei astfel de „denivelări”. Este posibil ca punctele de încărcare să nu fi fost proiectate corect și ar putea fi necesar să măriți dimensiunea „treptei” pentru a simți cu adevărat creșterea sarcinii. Setul de experimente și rezultate ar trebui să fie suficient pentru a permite o analiză a blocajelor și a trage concluzii despre performanța și stabilitatea aplicației testate.

Test de performanta(Test de performanta)

Scopul testării performanței este de a determina scalabilitatea aplicației sub sarcină:

timpul de executare a operațiunilor este măsurat la anumite rate de execuție
se determină numărul de utilizatori care lucrează simultan cu aplicația
limitele performanței acceptabile sunt determinate atunci când sarcina crește
cercetarea performanței este efectuată la sarcini mari, extreme și stresante

Testare de stabilitate (Testare de stabilitate/fiabilitate)

Testarea de stabilitate (fiabilitate) verifică funcționalitatea aplicației în timpul testării pe termen lung (multe ore) cu un nivel mediu de încărcare. Timpul de execuție al operațiunilor joacă un rol secundar, iar primul loc este ocupat de absența scurgerilor de memorie, repornirea serverului sub sarcină și alte aspecte care afectează în mod specific stabilitatea funcționării.

Testare stresanta (Testare stresanta)

Testarea la stres testează performanța unei aplicații sau a unui sistem în ansamblu în condiții de stres. Ajută la evaluarea capacității sistemului de a reveni la normal după ce sarcina este îndepărtată. Sarcina poate fi o creștere a intensității operațiunilor la valori foarte mari sau o schimbare de urgență a configurației serverului. O sarcină specială a testării de stres poate fi evaluarea degradării performanței.

Testarea volumului (Testarea volumului)

Testarea volumului vă permite să evaluați performanța pe măsură ce crește volumul de date din baza de date a aplicației:

timpul de executare a operaţiilor este măsurat în timpul execuţiei intensive simultane
determina numărul de utilizatori care lucrează simultan cu aplicația

Conform prevederilor ingineriei sistemelor moderne, procedura de testare nu ar trebui să fie etapa finală în procesul de creare a software-ului. Erorile în procesul de creare a unor astfel de produse care nu sunt identificate în stadiul apariției lor se vor acumula, prin urmare, detectarea și eliminarea lor în timp util este atât de importantă. Procesul de testare în sine trebuie aplicat nu numai programelor, ci și interfețelor sau echipamentelor electronice.

Testarea funcționalității interfeței utilizator are ca scop stabilirea gradului de adaptare a acesteia la cerințele stabilite de dezvoltatori. Acest lucru se aplică în mod egal aplicațiilor de Internet și paginilor web. Testul este supus ergonomiei, care determină interacțiunea om-calculator, simplitatea și receptivitatea controlului și viteza de familiarizare cu funcțiile noului produs software. Acestea sunt principalele caracteristici, a căror valoare determină economia de timp și ușurința în utilizare.

Compania efectuează teste în mai multe etape, care constau în:
analiza cerințelor care au fost prezentate de dezvoltatori pentru produsul lor și corectitudinea acestora;
elaborarea unei liste de verificare pentru testare;
efectuarea procedurilor de testare;
determinarea caracterului complet al conformității cu cerințele stabilite pentru rezultatele testării;
generarea unui raport fie asupra succesului testului, fie asupra încălcărilor identificate în funcționarea produsului software.

Scopul verificării nivelului de securitate al unui produs este de a determina vulnerabilitatea acestuia la viruși sau la atacurile hackerilor externi. Corectitudinea și fiabilitatea funcționării atât a programelor, cât și a echipamentelor depind direct de acest indicator. Utilizatorul final trebuie să fie asigurat că instalarea unui produs nou nu va reduce performanța sau nu va compromite integritatea sistemului. Securitatea este, de asemenea, despre confidențialitate și disponibilitate scăzută. Integritatea sistemului este evaluată prin capacitatea sa de a se autovindeca după penetrarea externă sau influența neautorizată.

Efectuăm o serie de lucrări de orice complexitate și avem un laborator, specialiști calificați și instrumente proprii pentru dezvoltarea și efectuarea lucrărilor de testare.

Testare stresanta(eng. testing load) - un subtip de testare a performanței, colectarea indicatorilor și determinarea performanței și a timpului de răspuns al unui sistem software și hardware sau dispozitiv ca răspuns la o solicitare externă pentru a stabili conformitatea cu cerințele pentru un anumit sistem (dispozitiv ).

Pentru a studia timpul de răspuns al sistemului la sarcini mari sau de vârf, se efectuează teste de stres, în care sarcina creată asupra sistemului depășește scenariile normale de utilizare a acestuia. Nu există o graniță clară între testarea la sarcină și testarea stresului, dar aceste concepte nu trebuie confundate, deoarece aceste tipuri de testare răspund la diferite întrebări de afaceri și folosesc metodologii diferite.

Testare de încărcare software

Termen Testare stresanta poate fi folosit în diverse sensuri într-un mediu profesional de testare a software-ului. În general, se referă la practica de simulare a utilizării așteptate a unei aplicații prin emularea mai multor utilizatori în același timp. Astfel, o astfel de testare este cea mai potrivită pentru sistemele multi-utilizator, cel mai adesea folosind arhitectura client-server (de exemplu, servere web). Cu toate acestea, alte tipuri de sisteme software pot fi testate într-un mod similar. De exemplu, un editor de text sau grafică poate fi făcut să citească un document foarte mare; și pachetul financiar - generați un raport bazat pe date pe mai mulți ani. Testul de sarcină cel mai adecvat proiectat va produce rezultate mai precise.

Scopul principal al testării de încărcare este de a crea o anumită încărcare așteptată pe sistem (de exemplu, prin intermediul utilizatorilor virtuali) și, de obicei, folosind software și hardware identic, pentru a observa performanța sistemului.

Exemplul 1:

Un serviciu web cu funcționalitate coș de cumpărături este conceput pentru 100 de utilizatori concurenți care urmează un anumit scenariu (acțiuni specificate în proporții specificate):

25 de utilizatori vizualizează un articol și se deconectează.
25 de utilizatori adaugă un articol în coș, verifică și deconectează-te din sistem.
25 de utilizatori folosesc funcția de returnare a produsului și se deconectează.
25 de utilizatori se conectează și nu arată nicio activitate.

În acest caz, testarea de încărcare ar trebui să emuleze scenariul tipic de lucru cu un serviciu web descris mai sus pentru a vă asigura că sistemul este gata să intre în producție. În acest caz, indicatorii de performanță ai sistemului în ansamblu sau a fiecărui nod al sistemului în particular pot fi luați pentru analiză.

În mod ideal, criteriile pentru succesul testării la sarcină sunt cerințele de performanță a sistemului, care sunt formulate și documentate în etapa de dezvoltare a cerințelor funcționale pentru sistem înainte de programarea principalelor soluții arhitecturale. Cu toate acestea, se întâmplă adesea ca astfel de cerințe să nu fie formulate clar sau să nu fie formulate deloc. În acest caz, va fi primul test de sarcină proces(eng. testarea de încărcare exploratorie) și să se bazeze pe ipoteze rezonabile cu privire la sarcina așteptată și consumul de resurse hardware.

Una dintre abordările optime pentru utilizarea testării de încărcare pentru a măsura performanța sistemului este testarea în stadiul incipient de dezvoltare. Testarea de încărcare în primele etape de pregătire a unei soluții arhitecturale pentru a determina viabilitatea acesteia se numește testare „dovadă de concept”.

Principii de bază ale încercării de sarcină

Mai jos sunt câteva fapte experimentale, principii generale utilizate în testarea performanței în general și aplicabile oricărui tip de testare a performanței (în special, testarea la sarcină).

1. Unicitatea cererilor

Chiar și după ce am creat un scenariu realist pentru lucrul cu sistemul pe baza statisticilor de utilizare a acestuia, este necesar să înțelegem că vor exista întotdeauna excepții de la acest scenariu.

Când Exemplul 1 acesta ar putea fi un utilizator care accesează pagini unice ale unui serviciu web care sunt diferite de toate celelalte.

2. Timpul de răspuns al sistemului

În general, timpul de răspuns al unui sistem urmează o funcție de distribuție normală.

În special, aceasta înseamnă că, având un număr suficient de măsurători, este posibil să se determine probabilitatea cu care răspunsul sistemului la o solicitare se va încadra într-un anumit interval de timp.

3. Dependența timpului de răspuns al sistemului de gradul de distribuție al acestui sistem.

DE	Numele producatorului	Comentarii
OpenSTA	„Arhitectura de testare a sistemului deschis”	Software gratuit pentru testarea de încărcare/stres, licențiat sub GNU GPL. Utilizează o arhitectură de aplicație distribuită bazată pe CORBA. Este disponibilă o versiune Windows, deși există probleme de compatibilitate cu Windows Vista. Sprijinul s-a încheiat în 2007.
IBM Rational Performance Tester	IBM	Software bazat pe mediul de dezvoltare Eclipse care vă permite să creați încărcări mari și să măsurați timpul de răspuns pentru aplicațiile cu arhitectură client-server. Necesită licență.
JMeter	Proiectul Apache Jakarta cu sursă deschisă	Setul de instrumente multiplatformă bazat pe Java, care vă permite să efectuați teste de încărcare utilizând conexiuni JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP. Face posibilă crearea unui număr mare de solicitări de la diferite computere și controlul procesului de la unul dintre ele.
HP LoadRunner	HP	Un instrument de testare a sarcinii conceput inițial pentru a emula munca unui număr mare de utilizatori concurenți. Poate fi folosit și pentru testarea unitară sau de integrare.
LoadComplete	SmartBear	Un produs proprietar care vă permite să efectuați testarea de încărcare a aplicațiilor web
SilkPerformer	Micro Focus (Borland)
Asediu	Joe Dog Software	Siege este un utilitar de testare a încărcării pentru servere web.
Sistemul de echipă Visual Studio	Microsoft	Visual Studio oferă instrumente de testare a performanței, inclusiv testarea încărcării/unității
QTest	Cota
HTTPerf
QALload	Compuware Ltd.
(Mașoara).
Încărcare web	Software-ul RadView	Încărcați instrumentul de testare pentru aplicații web și mobile, inclusiv panouri web pentru testarea analizei performanței. Folosit pentru sarcini de lucru la scară largă care pot fi generate și din cloud. licenţiat.
Yandex.Tank	Yandex	Un instrument modular și extensibil care vă permite să utilizați diferite generatoare în interior, în special, familiarul JMeter. Acesta este un proiect open-source publicat de Yandex în 2012.

Indicatori cheie de performanță (metrici)

Unul dintre rezultatele obținute în timpul testării de sarcină și utilizat pentru analize ulterioare sunt indicatorii de performanță a aplicației. Cele principale sunt discutate mai jos.

1. Consumul de resurse CPU, %

O valoare care arată cât de mult timp dintr-un anumit interval a fost petrecut de procesor pentru calculele pentru procesul selectat. În sistemele moderne, un factor important este capacitatea unui proces de a rula în mai multe fire, astfel încât procesorul să poată efectua calcule în paralel. Analiza istoricului consumului de resurse ale procesorului poate explica impactul asupra performanței generale a sistemului al fluxurilor de date procesate, al configurațiilor aplicațiilor și ale sistemului de operare, al calculului cu mai multe fire și al altor factori.

2. Consum RAM, MB

O valoare care arată cantitatea de memorie utilizată de o aplicație. Memoria folosită este împărțită în mai multe categorii:

Virtual - cantitatea de spațiu de adrese virtuale pe care o folosește procesul. Acest volum implică atât utilizarea spațiului adecvat pe disc, cât și a memoriei RAM. Sistemul de memorie virtuală asigură că firele dintr-un proces nu pot accesa memoria deținută de alt proces.
Privat - cantitatea de spațiu de adrese ocupată de un proces și care nu este partajată cu alte procese.
Set de lucru - un set de pagini de memorie utilizate recent de proces. Când există suficientă memorie liberă, paginile rămân în set chiar dacă nu sunt utilizate. Când rămâne puțină memorie liberă, paginile utilizate sunt mutate de pe RAM pe hard disk (sau alt dispozitiv de stocare, cum ar fi memoria Flash), eliberând memoria RAM pentru a încărca alte pagini de memorie activă.
Partajat - cantitatea de memorie fizică utilizată de proces, care poate fi partajată cu alte procese. Deși memoria alocată unui proces ar trebui să fie izolată, procesele trebuie uneori să poată face schimb de informații. Memoria partajată este cea mai rapidă modalitate de comunicare între procese.

Când rulează o aplicație, memoria este umplută cu referințe la obiecte, care, dacă nu sunt utilizate, pot fi curățate printr-un proces automat special numit colector de gunoi. Timpul necesar procesorului pentru a șterge memoria în acest mod poate fi semnificativ atunci când un proces a ocupat toată memoria disponibilă (în Java, așa-numitul „GC persistent complet”) sau când unui proces are alocate cantități mari de memorie care trebuie să fi curăţat. În timpul necesar pentru ștergerea memoriei, accesul unui proces la paginile memoriei alocate poate fi blocat, ceea ce poate afecta timpul final de procesare a procesului respectiv.

3. Consumul de resurse de rețea

Această măsurătoare nu este direct legată de performanța aplicației, dar poate indica limitele de performanță ale sistemului în ansamblu.

Exemplul 3:

Aplicația server, procesând cererea utilizatorului, îi returnează fluxul video folosind un canal de rețea de 2 megabiți. Cerința prevede că serverul trebuie să proceseze 5 cereri de utilizator simultan.

Testarea de încărcare a arătat că serverul poate furniza în mod eficient date doar 4 utilizatori în același timp, deoarece fluxul multimedia are o rată de biți de 500 de kilobiți. Evident, furnizarea acestui flux către 5 utilizatori în același timp este imposibilă din cauza depășirii lățimii de bandă a canalului de rețea, ceea ce înseamnă că sistemul nu îndeplinește cerințele de performanță specificate, deși consumul său de resurse de procesor și memorie poate fi scăzut.

4. Lucrul cu subsistemul disc (timpul de așteptare I/O)

Lucrul cu subsistemul de disc poate afecta semnificativ performanța sistemului, astfel încât colectarea de statistici despre lucrul pe disc poate ajuta la identificarea blocajelor în acest domeniu. Un număr mare de citiri sau scrieri poate duce la oprirea procesorului în așteptarea procesării datelor de pe disc, ceea ce duce la un consum crescut de CPU și timpi de răspuns mai lenți.

5. Timp de execuție a interogării, ms

Timpul de execuție a interogării aplicației rămâne unul dintre cei mai importanți indicatori ai performanței sistemului sau a aplicației. Acest timp poate fi măsurat pe partea de server ca o măsură a timpului necesar pentru ca back-end să proceseze cererea; iar pe partea clientului, ca indicator al timpului total necesar serializării/deserializării, transmiterii și procesării cererii.

Echipa noastră s-a confruntat cu deficiențele instrumentelor de testare a sarcinii și, în final, s-a decis să ne dezvoltăm propriul serviciu. Principalele dificultati:

Dacă acesta este un serviciu, prețul este prea mare pentru o sarcină serioasă
Dacă acesta este un utilitar, rezultatul depinde de viteza computerului/canalului serverului de pe care a fost efectuat testul
Interogările repetate nu reflectă viteza reală, deoarece memorarea în cache are loc la diferite niveluri de la CPU la baza de date

Sper că „bicicleta” va fi interesantă pentru alții - mai întâi voi descrie ceea ce funcționează deja, apoi putem discuta despre alte caracteristici.

Ce s-a făcut deja?

Puteți testa sarcini din lista de adrese URL, până la 20 de bucăți
Fiecare URL poate conține unul sau mai mulți parametri aleatori specificați folosind funcția $RND
Testul este rulat de pe mai multe servere, fiecare rulând doar 8 fire
Testarea poate fi efectuată din 5 regiuni AWS - Dublin, Frankfurt, Est/Vest SUA, Tokyo
Suntem gata să oferim teste pentru până la 200 de fire gratuit

Pentru test, deschideți formularul, unde indicăm e-mailul, completăm adresa URL, selectați numărul de fire de testare, regiunea și începem testul.

*** ACTUALIZAȚI ***
Văd o mulțime de locuitori curajoși din Khabra care stabilesc o sarcină pentru 200 de fire. Dacă presupunem că o pagină este redată într-o secundă, atunci aceasta corespunde unui trafic de >100.000 de vizitatori pe oră. Proiectele obișnuite, inclusiv ale noastre, mor din cauza unor astfel de teste.

Într-un minut, rezultatul tău va fi gata (de exemplu, vezi rezultatul excelent - testing example.net). După cum puteți vedea, 200 de fire vă permit să generați mai mult de 1000 de solicitări pe secundă - totul depinde de viteza de comunicare cu serviciul testat etc. de fapt, viteza de răspuns.

Dacă sunteți gata să vă prezentați rezultatul pe site-ul nostru web, puteți face clic pe butonul Rezultat public. Pentru a le arăta colegilor, trimiteți un link.

Ce să testez?
Resursele statice, imaginile, scripturile trebuie servite de la un CDN. Nu are sens să le testați viteza de încărcare, IMHO; trebuie doar să testați viteza generală de încărcare a paginii, de exemplu folosind vechiul http://tools.pingdom.com/fpt/

Loadme se concentrează pe testarea codului paginii / metodelor API, etc... Desigur, este posibil să testați nginx care servește 1x1.gif folosind acest instrument, dar nu există niciun beneficiu practic și nginx nici măcar nu se va încălzi din acest lucru.

Pentru a determina ce pagini reprezintă blocajul, cel mai bine este să utilizați newrelic. Spre deosebire de popularul google analytics, vă permite, de asemenea, să urmăriți statisticile solicitărilor de bot și să construiți interogări pe baza numărului de operațiuni pe pagină, precum și a paginii care a stricat cel mai mult experiența utilizatorului conform indexului apdex.
După cum știți, o muscă în unguent strica un butoi de miere și, dacă aplicarea dvs. încetinește la unele acțiuni chiar relativ rare, acest lucru poate afecta foarte bine operațiunile ușoare populare.

Cum funcționează redirecționările?
Redirecționările sunt executate; Le folosim în mod activ pentru a testa unul dintre site-urile noastre, wikiart.org, prin implementarea funcției „mergi la o imagine aleatorie” pe acesta.

De ce este important să testați mai multe adrese URL?
Pentru a testa influența reciprocă a paginilor populare rapide și a celor lente (de exemplu, căutare)

De ce este necesar $RND?
Sintaxa este $RND(de la, până la).
De exemplu, http://someshop.com/search?from=$RND(0,1000)&to=$RND(1000,10000) va genera interogări arbitrare pentru a căuta produse cu prețuri cuprinse între 0 și 1000 și care se termină de la 1000 la 10000. Acest lucru face posibilă estimarea puterii reale de căutare.
De exemplu, popularul magazin ucrainean Rozetka petrece în medie 5 secunde căutând smartphone-uri la un preț aleatoriu:
http://loadme.socialtalents.com/Result/ViewById/56108a645b5f1700481cc21d, care este un rezultat foarte departe de ideal.
Amazon face față acestei sarcini fundamental mai bine - un număr semnificativ de erori, ca urmare, sunt cel mai probabil protecția DDOS

Planuri de viitor

Postați, puneți, ștergeți cereri
Lucrul necesar este cu siguranță în planuri.

Autorizare
Suportul cookie-urilor va fi suficient pentru ca prima solicitare să înregistreze testul sub un utilizator aleatoriu (care va necesita asistență de la server) și vor avea loc lucrări ulterioare în numele acestui utilizator?

Teste de pas
Să spunem, rulați o serie de teste: 25%, 50%, 75% și 100% și vedeți diferența de viteză.

În loc de numărul de fire, lăsați utilizatorul să aleagă câte operații pe secundă dorește să inițieze.

Test regulat programat
Repetați testul în fiecare zi/săptămână și trimiteți un raport prin e-mail.
De asemenea, puteți furniza un fel de webhook pentru a declanșa un test existent din cod (de exemplu, după o actualizare)

Vizualizare îmbunătățită a debitului
Este posibil ca serverul să se fi comportat neregulat. Intenționăm să adăugăm vizualizarea debitului serverului în secunde.

Confirmarea proprietății domeniului
Limita de cel mult 200 de agenți pe domeniu există tocmai pentru a se asigura că nimeni nu aruncă site-ul altcuiva în ddos. Puteți crea un alt subdomeniu pentru site-ul dvs. și îl puteți testa din nou.
În viitor, însă, va fi necesară verificarea domeniilor folosind o înregistrare CNAME sau un fișier cu un nume specific.

Concurenți existenți

Loadimpact.com - pentru un test de încărcare normal, vor fi necesare cel puțin 100 de solicitări pe secundă, 1500 așa-numiți „utilizatori virtuali” - fiecare dintre ei încarcă pagina o dată la 15 secunde. Acest pachet costă în prezent 299 USD pe lună.

Loader.io este un serviciu excelent, pachetul plătit este de doar 99 USD pe lună. Setări URL foarte flexibile - puteți seta metode, cookie-uri, antete, dar nu am avut suficientă randomizare de testare.

Atunci când o aplicație web (site, serviciu) este încă destul de tânără, dar destinată unui public larg, este foarte greu de înțeles cât de puternic este necesar un server hardware. Deci, cea mai bună soluție ar fi simularea fluxului utilizatorului folosind teste sintetice.

Apache Bench

Probabil unul dintre cele mai ușor de utilizat și mai populare teste pentru verificarea încărcării pe un site web. Utilitarul este potrivit atât pentru testarea simplă, cât și pentru cea avansată:

Ab -c 50 -n 10000 -f TLS1.2 -H „Accept-Encoding: gzip,deflate” https://somesite.com/

# Verificați numărul maxim de solicitări cu TLS

Echipa a executat 10.000 de solicitări în 50 de fire și, printre altele, a arătat viteza și numărul de solicitări procesate:

Total transferați: 59560000 de octeți HTML transferați: 52160000 de octeți Solicitări pe secundă: 816,77 [#/sec] (medie) Timp per solicitare: 122,434 (medie) Timp per solicitare: 2,449 (medie, pentru toate solicitările concurente) Rata de transfer: 2375 primite.

# Jurnalul de testare oferă mult mai multe informații

Din acest raport, cele mai importante date vor fi:

Cereri pe secundă- numărul de cereri pe secundă. De exemplu, dacă o pagină este formată din 20 de părți (CSS, imagini și HTML), atunci în exemplul nostru serverul este capabil să proceseze aproximativ 40 de utilizatori simultan pe secundă.
Timp pe cerere (medie)- timpul mediu de executare a unui grup de cereri paralele (în cazul nostru 50);
Timp per solicitare (în medie, pentru toate solicitările concurente)- timpul mediu pentru finalizarea unei cereri.

AB este util pentru evaluarea rapidă și aproximativă a performanței unui server web, așa că dacă aveți nevoie să apropiați datele de realitate, va trebui să utilizați utilități suplimentare.

Httperf

Acest benchmark open source a fost dezvoltat de HP pentru a măsura performanța serverului web. Instrumentul nu a fost actualizat de câțiva ani, dar este încă foarte relevant.

Utilitarul, ca și ab, este ușor de utilizat și are o gamă destul de largă de funcționalități. Este lansat la fel de simplu ca ab:

Httperf --hog --server 192.168.122.10 --wsess=100000,5,2 --rate 1000 --timeout 5

# Creați 100.000 de sesiuni (5 apeluri la fiecare 2 s) la o viteză de 1000

Și jurnalul va arăta astfel:

Total: conexiuni 117557 solicitări 219121 răspunsuri 116697 durată test 111.423 s Rata conexiunii: 1055.0 conn/s (0.9 ms/conn,<=1022 concurrent connections) Connection time : min 0.3 avg 865.9 max 7912.5 median 459.5 stddev 993.1 Connection time : connect 31.1 Connection length : 1.000 Request rate: 1966.6 req/s (0.5 ms/req) Request size [B]: 91.0 Reply rate : min 59.4 avg 1060.3 max 1639.7 stddev 475.2 (22 samples) Reply time : response 56.3 transfer 0.0 Reply size [B]: header 267.0 content 18.0 footer 0.0 (total 285.0) Reply status: 1xx=0 2xx=116697 3xx=0 4xx=0 5xx=0 CPU time [s]: user 9.68 system 101.72 (user 8.7% system 91.3% total 100.0%) Net I/O: 467.5 KB/s (3.8*10^6 bps)

# Printre altele, performanța este afișată de rata de solicitare

Acest raport ar trebui să se concentreze pe:

Rata de conectare- viteza reală de creare de noi conexiuni. Acesta arată capacitatea serverului de a procesa conexiuni, adică, în cazul nostru, până la 1055 conexiuni/s, dar nu mai mult de 1022 conexiuni simultane.
Timp de conectare- durata de viață a conexiunilor de succes între inițializare și închidere. Din nou, arată performanța serverului atunci când procesează un număr mare de conexiuni.
Rata de solicitare- viteza de procesare a cererilor. Adică, numărul de solicitări pe care serverul este capabil să le efectueze pe secundă arată capacitatea de răspuns a aplicației web.

Dar pentru o verificare mai profundă și o sarcină semnificativă, va trebui să utilizați instrumente și mai avansate.

Tsung

Este un utilitar puternic, avansat, multi-tasking și multi-threaded. Instrumentul poate fi folosit pentru a încărca servere HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP și Jabber/XMPP. Suportă SSL, monitorizarea resurselor de sistem și agenții SNMP, Munin sau Erlang pe servere la distanță, simularea comportamentului utilizatorului și raportarea avansată.

Instrumentul este scris în Erlang, așa că mai întâi trebuie să instalați depozitele necesare, apoi să descărcați și să instalați Tsung:

Wget http://tsung.erlang-projects.org/dist/tsung-1.6.0.tar.gz tar zxfv tsung-1.6.0.tar.gz cd tsung-1.6.0 ./configure && make && make install

# Despachetarea și compilarea utilitarului

Toate setările instrumentului trebuie specificate în fișierul său de configurare:

Cp /usr/share/doc/tsung/examples/http_simple.xml /root/.tsung/tsung.xml

# Copierea șablonului fișierului de configurare în directorul Tsung

După care trebuie să îl editați setând parametrii necesari:

# Puteți specifica opțiuni suplimentare (de exemplu, browsere pentru utilizatori), mai multe noduri pentru simularea utilizatorilor

Acum puteți rula tsung:

Tsung -f tsung.xml start Pornirea Tsung „Directorul de jurnal este: /root/.tsung/log/20160428-1117”

# Pentru a rula din mai multe noduri, trebuie mai întâi să le specificați în setări

Când utilitarul și-a încheiat activitatea, puteți vizualiza raportul:

Mkdir report_output cd report_output /usr/lib/tsung/bin/tsung_stats.pl --stats /root/.tsung/log/20160428-1117/tsung.log chromium graph.html

# Specifică browserul preferat

Raportul va consta din grafice și informații suplimentare importante. Merită să acordați atenție:

Sesiune- numărul total de utilizatori și numărul de sesiuni simultane pe secundă pe care le-a procesat serverul web.
Cerere- timpul de răspuns al serverului web, capacitatea și viteza acestuia de procesare a cererilor simultane. De exemplu, 200 de solicitări/e înseamnă că în medie 10 utilizatori pot accesa simultan o pagină web formată dintr-un total de 20 de componente (CSS, imagini și HTML). Și asta înseamnă mai mult de 400.000 de vizitatori în 12 ore.
Conectați- timpul necesar pentru conectare, adică capacitatea de răspuns a serverului web.

Graficele suplimentare vă vor permite să evaluați încărcarea de pe serverul web pe întreaga perioadă de testare, să urmăriți erorile și dinamica.

Alte utilitati

Desigur, lista de instrumente pentru verificarea performanței serverului web și testarea încărcării site-ului nu se limitează la cele prezentate în acest material. Există un număr mare de astfel de utilități, atât plătite, cât și gratuite. Există site-uri pentru generarea de încărcări, cum ar fi LoadImpact, utilitare pentru rularea din linia de comandă și programe complete cu o interfață grafică. Unul dintre cele mai populare cu o interfață de utilizator, apropo, este Apache JMeter - puternic, avansat și destul de complex.

Cel mai important

Apache Bench, Httperf și Tsung sunt excelente pentru testarea încărcării pe site-uri mari și mici. Dar numai tsung va putea să stoarcă toată sucul dintr-un server web și să arate de ce este capabil în condiții apropiate de realitate. Nu uitați că toate testele trebuie rulate mai întâi pe un singur utilizator pentru a urmări dependența și pentru a avea un punct de referință.

Poate că cineva va fi interesat de cum să efectueze „rapid” testarea de încărcare a aplicației sale web.
Detalii sub croiala

În loc de prefață

La stand-up-ul de astăzi, Marek (un programator din Polonia care participă la proiectul EmForge) a spus că a vorbit cu un număr de prieteni care în trecut au avut multă experiență de lucru cu Liferay (pe care îl folosim în mod activ) - și experiența s-a dovedit a fi foarte negativ, în primul rând din cauza problemelor de viteză. Unele proiecte au fost închise prost din cauza faptului că aceste probleme nu au putut fi rezolvate.

Nu - desigur, urma să efectuăm teste de încărcare, dar nu acum, puțin mai târziu, când vor exista mai multe funcționalități, și apoi pur și simplu pentru a ne asigura că totul este în regulă sau „nu este ok” în anumite locuri. - si sa le corecteze.
Dar aici a apărut întrebarea: dacă totul este atât de rău, atunci unele decizii trebuie luate acum - înainte de a fi prea târziu. Există o singură concluzie - testarea încărcării primește o prioritate mai mare în comparație cu alte sarcini

Nu "repede"

Inițial, a fost planificat să se parcurgă calea standard - luați JMeter, scrieți un script simplu pentru accesarea cu crawlere a paginilor principale cu funcționalitatea principală de către un utilizator anonim - apoi îmbunătățiți-l puțin câte puțin, rezolvând simultan problemele legate de modul de a rula acest lucru în mod competent. lucruri pe mai multe mașini client.

În general, sarcina nu este de o oră

Ce zici de unul rapid?

Dar apoi mi-am amintit că era un articol pe Habr (din păcate nu am găsit articolul - aș fi postat linkul), în care o persoană se plângea că oamenii nu rulează teste de încărcare pe site-ul lor, trimit un link către Habr, și apoi, când trebuie să îndepărteze „crema” „Este dureros să ridici site-ul de la Habraeffect (și utilizatorii nu văd decât mesaje de eroare).
Deci, cineva de acolo a recomandat mai multe servicii care efectuează astfel de teste de încărcare.

În general, cel mai util link pe tema testării de încărcare s-a dovedit a fi acesta - atât utilități precum JMeter, cât și servicii pentru organizarea testării sunt enumerate aici. Mă voi opri asupra primelor trei mai detaliat.

Chiar repede?

Pentru a spune foarte repede, acesta este Load Impact - nu este necesară înregistrarea - intrați - dați URL-ul - și în 10-15 minute 50 de utilizatori virtuali vă terorizează pagina. Prost, simplu - dar cel puțin îți va permite să vezi că la primul aflux aplicația ta nu va eșua. Nu te-ai culcat? Daţi-i drumul

Testare de încărcare în 1,5 ore

Mi-a plăcut foarte mult LoadStorm. Lucrul cu acesta este structurat după cum urmează:
1. înregistrare
2. Creați un test - care indică site-ul pe care îl vom tortura
3. Înainte de a începe tortura, este necesară verificarea (ce se întâmplă dacă doriți să instalați site-ul unui concurent????). trebuie să puneți un anumit text cu un cod pe pagina principală - sau un fișier cu un anumit nume în rădăcină
4. În continuare, creăm un scenariu - atunci când creăm un scenariu, descriem modul în care utilizatorul navighează pe site-ul dvs., pe ce linkuri face clic, puteți trimite formulare. Totul este destul de intuitiv și clar
5. apoi spunem când să lansăm
6. La ora stabilită, începe testul, așteptați 30 de minute până când până la 50 de utilizatori se plimbă pe site-ul dvs. conform instrucțiunilor dvs. - și primim un raport.

Da, 50 de utilizatori simultani nu este în întregime serios - nu este nici măcar aproape de efectul habro - dar este ceva. Dacă aveți nevoie de mai mult, există un abonament plătit (da, am uitat să spun că totul este gratuit). În cazul meu, 50 de utilizatori simultani este o sarcină la care nici măcar nu pot visa în următoarele câteva luni - așa că a fost suficient pentru mine.

În general, a durat aproximativ o oră și jumătate pentru a descrie un scenariu de 15 pagini consecutive, așteptați să ruleze testul și așteptați rezultatele în sine, drept urmare am primit grafice precum

Acest grafic arată cum a fost chinuit sistemul - în cazul meu au fost maxim 47 de utilizatori - și puțin mai mult de 3 solicitări pe secundă
Ei bine, cel mai interesant

Din care rezultă că dacă excludem vârful maxim de 5 secunde (în acest moment Garbage Collector a decis să se pornească) - altfel aplicația s-a comportat bine - și indiferent de numărul de utilizatori - adică o încărcare de 50 de utilizatori nu încărcați site-ul - există, de asemenea, stocul este bun.

Este clar că o astfel de testare nu este în întregime „serioasă” în ceea ce privește rezultatele produse, iar 50 de utilizatori simultani nu pot fi numiți o sarcină serioasă, dar având în vedere timpul petrecut (o oră și jumătate) și banii (0 ruble), rezultatul este destul de adecvat. Cel puțin suntem convinși că dacă există probleme cu performanța, tot nu o vom vedea în lunile următoare.

Puțin mai lung și mai scump

Dacă vrei ceva mai serios, poți să încerci