Articles

ladda testa din app med Siege

juli 2019

tagg(er): rails_performance • rails • programmering
lästid: 8 minuter
  • dumpning unika webbadresser i en textfil
  • besöker alla dessa sidor i Siege ett Belägringstest
  • ytterligare resurser

förra gången grävde jag in med Apache benchmark för att göra prestandatestning på en sida som kräver autentisering för åtkomst.

idag ska vi ta reda på hur du använder siege för att besöka många unika webbadresser på vår sida och för att få riktmärken på den processen. Jag ska nästa räkna ut prestanda profilering i Datadog, och med dessa tre verktyg tillsammans, vi bör vara redo att göra några meningsfulla förbättringar av vår ansökan.

denna serie inlägg är ett direkt resultat av Nate Berkopecs The Complete Guide to Rails-prestanda, med hjälp av hans screencasts, liksom Steve Grossis Lasttestnings Rails-appar med Apache Bench, Siege och JMeter. Beväpnad med dessa resurser, och står på jättarnas axlar, av går vi.

Belägringens beskrivning:

Siege är en http belastning testning och benchmarking verktyg. Den var utformad för att låta webbutvecklare mäta sin kod under tvång, för att se hur det kommer att stå upp för att ladda på internet. Siege stöder grundläggande autentisering, cookies, HTTP, HTTPS och FTP-protokoll. Det låter användaren träffa en server med ett konfigurerbart antal simulerade klienter. Dessa kunder placerar servern ” under belägring.”

du kan få belägring med brew install siege.

jag använder den eftersom den kan köra en lista med webbadresser du ger den. Föreställ dig att din app är en butik, och den listar några tusen produkter. Varje produkt ska ha en unik URL, något som , eller kanske . Det product-guid ser till att du kan ha unika webbadresser, även om det finns två objekt med samma Produktnamn.

att veta vad som finns i din databas kan du enkelt sammanfoga product-guid och product-name, hålla den till slutet av och komma med en lista med hundra eller tusen eller tiotusen unika Produktadresser i din ansökan. Om du sparade dessa till en textfil och hade Siege besök varenda en av dessa sidor så snabbt som möjligt… detta kan se ut som ett slags bra stresstest, va?

dumpning unika webbadresser i en textfil #

du kommer förmodligen börja arbeta i en rails console session, att räkna ut hur man får tillgång till URL-systemet precis rätt.

jag sparkade upp konsolen och skrev in:

jag tittade i vår dev-databas för att hitta ett konto med mycket data; konto med id 4887 är ett konto som är associerat med QA-automatisering och har mycket data i den.

campaign.to_param är hur vi bygger webbadresser ur våra kampanjer – det sammanfogar bara guid med title strängen, som tillhandahålls av kunden, och kallar .parameterize på den. För denna grupp av kampanjer genereras de programmatiskt av vår automatiserade QA-testsvit.

när du är klar kan du se något liknande i all_campaign_urls.txt:

besöker alla dessa sidor i ett Belägringstest #

så kan du siege --help och se en flagga för att passera i en fil:

redan vet jag att vi kommer att behöva --file och --header, eftersom vi måste förfalska autentiserade sessioner genom att skicka in några cookies, den process som jag skisserade förra gången

--get flaggan ser användbar ut:

hämta, dra ner HTTP-rubriker och visa transaktionen. Perfekt för applikationsfelsökning.

så, låt oss Logga in som vårt QA-konto. Eftersom jag kör allt detta lokalt kan jag hitta den tillhörande e-postadressen i vår DB. Jag vet naturligtvis inte lösenordet, men jag kan tvinga en lokal återställning av lösenord, ta tag i e-postmeddelandet i Mailcatcher och ställa in det till vilket lösenord jag vill ha.

låter få dessa rubriker i.

vi kan göra en cURL test begäran med våra cookies. När jag gör

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

jag förväntar mig att se sidan komma tillbaka, inte en omdirigering till /users/sign_in

vad jag förväntar mig att en misslyckad autentisering ska se ut:

cookies:

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

och vi är i affärer:

Lägg märke till dessa statuskoder för 200? Jag kan tail -f log/development.log och se all aktivitet, vilket indikerar att de inlämnade kakorna är associerade med en autentiserad användare.

det första jag märker är att det verkar som om det här är extremt långa sidladdningstider.

jag har belägring belastning om 162 olika webbadresser. När du kör siege med standardkonfigurationen körs 20 samtidiga användare. Detta verkade vara lite mycket för vad min localhost kunde hantera, så jag försökte släppa antalet samtidiga användare först till två användare, sedan till en.

för att ställa in antalet samtidiga användare, lägg bara till flaggan --concurrent=NUM. Jag var fortfarande översvämmad med utgång, så jag tappade samtidiga användare till 1 och tog bort alla utom 20 sidor från listan över sidor att ladda upp. Jag gav den en time flagga på 60 sekunder, också: -t 60s

när allt är sagt och gjort ser du siege göra en massa tidsbestämda GET – förfrågningar, som så:

så småningom kommer allt att lösa sig, och du får en sammanfattning av lasttestet:

Ja, okej, det här är coolt, Josh, men hur ska jag göra något användbart med det här?

stor fråga! Det är dags att se var vår app tillbringar större delen av sin tid, ute i den verkliga världen. Vi skulle kunna göra mer benchmarking lokalt, men uppenbarligen verkliga data, som samlats in från verkliga människor interagerar med din verkliga app i produktionen är den mest användbara datakällan.

därför kommer jag snart att skriva Jag har skrivit om hur man får användbar data från en Rails-app till DataDog!

Lämna ett svar

Din e-postadress kommer inte publiceras.