Articles

načíst testování aplikace s Siege

červenec 2019

tag(y): rails_performance • rails • programování
doba čtení: 8 minut
  • Dumping jedinečných adres URL do textového souboru
  • návštěva všech těchto stránek v testu Siege
  • další zdroje

poslední čas, vykopal jsem se pomocí Apache Benchmark k testování výkonu na stránce, která vyžaduje přístup k ověření.

dnes zjistíme, jak použít siege k návštěvě mnoha jedinečných adres URL na naší stránce a získání referenčních hodnot v tomto procesu. Dále zjistím profilování výkonu v Datadogu a s těmito třemi nástroji dohromady bychom měli být připraveni provést některá smysluplná vylepšení naší aplikace.

tato řada příspěvků je přímým důsledkem Nate Berkopec je kompletní průvodce po výkonu Rails, s pomocí jeho screencasts, stejně jako Steve Grossi je testování zatížení Rails aplikace s Apache Bench, Siege, a JMeter. Vyzbrojeni těmito zdroji, a stojící na ramenou obrů, jdeme.

popis obléhání:

Siege je http zatížení testování a benchmarking nástroj. Byl navržen tak, aby weboví vývojáři změřili svůj kód pod nátlakem, aby viděli, jak se postaví na načtení na internetu. Siege podporuje základní autentizaci, soubory cookie, protokoly HTTP, HTTPS a FTP. Umožňuje uživateli zasáhnout server s konfigurovatelným počtem simulovaných klientů. Tito klienti umístí server “ v obležení.“

můžete získat obléhání s brew install siege.

používám jej, protože může spustit seznam adres URL, které mu dáte. Představte si, že vaše aplikace je obchod, a uvádí několik tisíc produktů. Každý produkt by měl mít jedinečnou adresu URL, něco jako nebo možná . product-guid zajišťuje, že můžete mít jedinečné adresy URL, i když existují dvě položky se stejným názvem produktu.

vědět, co je ve vaší databázi, můžete snadno concat product-guid a product-name, držet ji na konci , a přijít se seznamem sto nebo tisíc nebo deset tisíc unikátních adres URL produktu ve vaší aplikaci. Pokud jste je uložili do textového souboru a obléhali jste každou z těchto stránek co nejrychleji … mohlo by to vypadat jako nějaký dobrý zátěžový test, co?

Dumping jedinečných adres URL do textového souboru #

pravděpodobně začnete pracovat v relaci rails console, abyste zjistili, jak správně přistupovat k schématu URL.

spustil jsem konzolu a zadal:

podíval jsem se do naší databáze dev, abych našel účet se spoustou dat; účet s id 4887 je účet spojený s automatizací QA a má v sobě spoustu dat.

campaign.to_param je způsob, jakým vytváříme adresy URL z našich kampaní – pouze spojuje guid s řetězcem title, jak je poskytl zákazník, a volá na něj .parameterize. Pro tuto dávku kampaní jsou generovány programově naší automatizovanou testovací sadou QA.

po dokončení můžete vidět něco takového v all_campaign_urls.txt:

návštěva všech těchto stránek v testu obléhání #

takže můžete siege --help a vidět příznak pro předání v souboru:

už vím, že budeme potřebovat --file a --header, protože budeme muset předstírat ověřené relace odesláním některých souborů cookie, Proces, pro který jsem naposledy nastínil

příznak --get vypadá užitečně:

získejte, stáhněte záhlaví HTTP a zobrazte transakci. Skvělé pro ladění aplikací.

takže se můžete přihlásit jako náš QA účet. Vzhledem k tomu, že to všechno provozuji lokálně, najdu přidruženou e-mailovou adresu v naší DB. Neznám heslo, samozřejmě, ale mohu vynutit místní reset hesla, chytit e-mail v Mailcatcher a nastavit jej na jakékoli heslo, které chci.

umožňuje získat tyto záhlaví.

s našimi cookies můžeme podat žádost o cURL test. Když to udělám

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

očekávám, že se stránka vrátí, ne přesměrování na /users/sign_in

co očekávám, že bude vypadat neúspěšná autentizace:

cookies:

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

a jsme v podnikání:

Všimněte si těchto stavových kódů 200? Mohu tail -f log/development.log a vidět veškerou aktivitu, což naznačuje, že odeslané soubory cookie jsou spojeny s ověřeným uživatelem.

první věc, kterou si všimnu, je, že se zdá, že se jedná o extrémně dlouhé časy načítání stránky.

mám Siege load o 162 různých adresách URL. Když spustíte siege s výchozí konfigurací, spustí se 20 současných uživatelů. Zdálo se, že to bylo trochu moc pro to, co můj localhost zvládl, takže jsem se pokusil snížit počet souběžných uživatelů nejprve na dva uživatele, pak na jednoho.

Chcete-li nastavit počet souběžných uživatelů, stačí přidat příznak --concurrent=NUM. Byl jsem stále zaplaven výstupem, takže jsem upustil souběžné uživatele na 1 a odstranil všechny stránky kromě 20 ze seznamu stránek, které se mají načíst. Dal jsem mu time vlajku 60 sekund, stejně: -t 60s

když je vše řečeno a hotovo, uvidíte siege dělat spoustu časovaných GET požadavků, jako je tak:

nakonec se vše usadí a získáte shrnutí zátěžového testu:

Jo, OK, to je v pohodě, Joshi, ale jak s tím mám sakra udělat něco užitečného?

skvělá otázka! Je čas zjistit, kde naše aplikace tráví většinu času, v reálném světě. Mohli bychom udělat více benchmarkingu lokálně, ale zjevně reálná data, shromážděná od skutečných lidí, kteří interagují s vaší skutečnou aplikací ve výrobě, jsou nejužitečnějším zdrojem dat.

Proto budu brzy psát napsal jsem o tom, jak získat užitečná data z aplikace Rails do Datadogu!

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.