Articles

încărcați testarea aplicației cu Siege

iulie 2019

etichetă(e): rails_performance • rails • programare
timp de citire: 8 minute
  • Dumping URL-uri unice într-un fișier text
  • vizitarea tuturor acestor pagini în un test de asediu
  • resurse suplimentare

ultima dată, am săpat în utilizarea Apache benchmark pentru a face testarea performanței pe o pagină care necesită autentificare pentru a accesa.

astăzi, ne vom da seama cum să folosim siege pentru a vizita multe adrese URL unice pe pagina noastră și pentru a obține repere în acest proces. Voi figura următoare profilare de performanță în Datadog, și cu aceste trei instrumente puse împreună, ar trebui să fim gata să facă unele îmbunătățiri semnificative la cererea noastră.

această serie de postări este un rezultat direct al Nate Berkopec Ghidul complet pentru performanța șinelor, cu ajutorul ecranelor sale, precum și al aplicațiilor de testare a încărcării lui Steve Grossi cu Apache Bench, Siege și JMeter. Înarmați cu aceste resurse și stând pe umerii giganților, plecăm.

descrierea asediului:

Siege este o testare de sarcină http și benchmarking utilitate. Acesta a fost conceput pentru a permite dezvoltatorilor web să-și măsoare codul sub presiune, pentru a vedea cum se va ridica pentru a se încărca pe internet. Siege acceptă autentificarea de bază, cookie-urile, protocoalele HTTP, HTTPS și FTP. Acesta permite utilizatorului să atingă un server cu un număr configurabil de clienți simulați. Acei clienți plasează serverul ” sub asediu.”

puteți obține asediu cu brew install siege.

îl folosesc pentru că poate rula o listă de adrese URL pe care le dați. Imaginați-vă că aplicația dvs. este un magazin și listează câteva mii de produse. Fiecare produs ar trebui să aibă o adresă URL unică, ceva de genul sau poate . Acest product-guid vă asigură că puteți avea adrese URL unice, chiar dacă există două elemente cu același nume de produs.

știind ce este în baza de date, puteți concat cu ușurință product-guid și product-name, stick-l la sfârșitul , și să vină cu o listă de o sută sau o mie sau zece mii de URL-uri unice de produse în cererea dumneavoastră. Dacă ați salvat aceste într-un fișier text și a avut asediu vizita fiecare dintre aceste pagini cât mai repede posibil… acest lucru ar putea arata ca un fel de test de stres bun, nu-i asa?

Dumping URL-uri unice într-un fișier text #

probabil veți începe să lucrați într-o sesiune rails console, pentru a afla cum să accesați schema URL corect.

am pornit consola, și a intrat:

m-am uitat în Baza noastră de date dev pentru a găsi un cont cu o mulțime de date; cont cu id-ul 4887 este un cont asociat cu automatizare QA, și are o mulțime de date în ea.

campaign.to_param este modul în care construim URL – uri din campaniile noastre-doar concats guid cu șirul title, așa cum este furnizat de client, și apeluri .parameterize pe ea. Pentru acest lot de campanii, acestea sunt generate programatic de suita noastră automată de testare QA.

când ați terminat, s-ar putea vedea ceva de genul asta în all_campaign_urls.txt:

vizitând toate aceste pagini într-un test de asediu #

Deci, puteți siege --help și puteți vedea un steag pentru trecerea într-un fișier:

deja știu că vom avea nevoie de --file și --header, deoarece va trebui să falsificăm sesiunile autentificate prin trimiterea unor cookie – uri, procesul pentru care am subliniat ultima dată

steagul --get pare util:

obțineți, trageți în jos anteturile HTTP și afișați tranzacția. Mare pentru depanare aplicație.

deci, vă permite să vă conectați ca contul nostru QA. Din moment ce rulez toate acestea la nivel local, pot găsi adresa de e-mail asociată în DB-ul nostru. Nu știu parola, desigur, dar pot forța o resetare a parolei locale, apuca e-mail în Mailcatcher, și setați-l la orice parolă vreau.

vă permite să obțineți aceste anteturi în.

putem face o cerere de testare cURL cu cookie-urile noastre. Când o fac

$ curl -v http://localhost:3000/account/campaigns/dd4dfb48aa-dec-05-drive-by-test

mă aștept să văd pagina revenind, nu o redirecționare către /users/sign_in

cum mă aștept să arate o autentificare eșuată:

cookie-uri:

_ts_session_id: c86fd1fe38d7a6c56ce1ef5990045057fd827a2c5655094bcce3748d6ee6d3e4: ImRhMDY1YjdjYjMwNGNjNWUxNzFkNDhjOGQ0YzA0OTIwIg%3D%3D--98c228cb35af1a269ee894c22540b81848e2ed09

și suntem în afaceri:

observați aceste coduri de stare de 200? Pot tail -f log/development.log și să văd toată activitatea, indicând faptul că cookie-urile trimise sunt asociate cu un utilizator autentificat.

primul lucru pe care îl observ este că se pare că acestea sunt timpi extrem de lungi de încărcare a paginii.

am sarcină asediu despre 162 URL-uri diferite. Când executați siege cu configurația implicită, rulează 20 de utilizatori simultani. Acest lucru părea să fie un pic cam mult pentru ceea ce ar putea face localhost, așa că am încercat să scad Numărul de utilizatori concurenți mai întâi la doi utilizatori, apoi la unul.

pentru a seta numărul de utilizatori simultani, trebuie doar să adăugați steagul --concurrent=NUM. Am fost încă inundat de ieșire, așa că am renunțat la utilizatorii concurenți la 1 și am eliminat toate paginile 20 din lista de pagini de încărcat. I-am dat un time pavilion de 60 de secunde, precum și: -t 60s

când totul este spus și făcut, veți vedea siege făcând o grămadă de Cereri temporizate GET, așa:

în cele din urmă, totul se va rezolva și veți obține un rezumat al testului de încărcare:

da, ok, acest lucru este rece, Josh, dar cum naiba ar trebui să fac ceva util cu asta?

Marea întrebare! Este timpul să vedem unde își petrece cea mai mare parte a timpului aplicația noastră, în lumea reală. Am putea face mai multe analize comparative la nivel local, dar, evident, datele din lumea reală, colectate de la oameni reali care interacționează cu aplicația dvs. reală în producție sunt cea mai utilă sursă de date.

prin urmare, voi scrie în curând am scris despre cum să obțineți date utile dintr-o aplicație Rails în DataDog!

Lasă un răspuns

Adresa ta de email nu va fi publicată.