Articles

Load Testing din app med Siege

juli 2019

tag(er): rails_performance • rails • programmering
Læsetid: 8 minutter
  • Dumping unikke URL ‘ er i en tekstfil
  • besøg alle disse sider i en belejringstest
  • yderligere ressourcer

sidste gang gravede jeg ind i at bruge Apache benchmark til at udføre ydelsestest på en side, der kræver godkendelse for at få adgang.

i dag finder vi ud af, hvordan du bruger siege til at besøge mange unikke URL ‘ er på vores side og få benchmarks for den proces. Jeg vil næste finde ud af ydeevne profilering i Datadog, og med disse tre værktøjer sat sammen, bør vi være klar til at gøre nogle meningsfulde forbedringer af vores ansøgning.

denne serie af indlæg er et direkte resultat af Nate Berkopec ‘s The Complete Guide to Rails Performance, med hjælp fra hans screencasts, samt Steve Grossi’ s Load Testing Rails Apps med Apache Bench, Siege og JMeter. Bevæbnet med disse ressourcer, og stående på skuldrene af giganter, off vi går.

Siege ‘ s beskrivelse:

Siege er en http belastning test og benchmarking nytte. Det var designet til at lade internetudviklere måle deres kode under tvang for at se, hvordan det vil stå op for at indlæse på internettet. Siege understøtter grundlæggende autentificering, cookies, HTTP, HTTPS og FTP protokoller. Det lader brugeren ramme en server med et konfigurerbart antal simulerede klienter. Disse klienter placerer serveren ” under belejring.”

du kan få belejring med brew install siege.

jeg bruger det, fordi det kan køre en liste over URL ‘ er, du giver det. Forestil dig, at din app er en butik, og den viser et par tusinde produkter. Hvert produkt skal have en unik URL, noget som , eller måske . At product-guid sørger for, at du kan have unikke URL ‘ er, selvom der er to elementer med samme Produktnavn.

når du ved, hvad der er i din database, kan du nemt sammenkæde product-guid og product-name, holde den til slutningen af og komme med en liste over hundrede eller tusind eller ti tusind unikke produkt-URL ‘ er i din ansøgning. Hvis du gemte disse i en tekstfil og havde Siege besøg hver eneste af disse sider så hurtigt som muligt… kan det se ud som en slags god stresstest, ikke?

Dumping unikke URL ‘ er i en tekstfil #

du vil sandsynligvis begynde at arbejde i en rails console session for at finde ud af, hvordan du får adgang til URL-ordningen helt rigtigt.

jeg fyrede konsollen op og indtastede:

jeg kiggede i vores dev-database for at finde en konto med en masse data; konto med id 4887 er en konto tilknyttet KVALITETSSIKRINGSAUTOMATISERING og har masser af data i den.

campaign.to_param er, hvordan vi bygger URL ‘ er ud af vores kampagner – det sammenkæder bare guid med title – strengen, som leveret af kunden, og kalder .parameterize på den. Til dette parti af kampagner genereres de programmatisk af vores automatiserede KVALITETSTESTPAKKE.

når du er færdig, kan du se noget som dette i all_campaign_urls.txt:

besøger alle disse sider i en Belejringstest #

så du kan siege --help og se et flag for at passere i en fil:

allerede ved jeg, at vi får brug for --file og --header, da vi bliver nødt til at falske godkendte sessioner ved at indsende nogle cookies, den proces, som jeg skitserede sidste gang

--get flag ser nyttigt ud:

Hent, træk HTTP-overskrifter ned og vis transaktionen. Great for ansøgning debugging.

så lad os logge ind som vores KVALITETSSIKRINGSKONTO. Da jeg kører alt dette lokalt, kan jeg finde den tilknyttede e-mail-adresse i vores DB. Jeg kender selvfølgelig ikke adgangskoden, men jeg kan tvinge en lokal nulstilling af adgangskode, få fat i e-mailen i Mailcatcher og indstille den til den adgangskode, Jeg vil have.

lad os få disse overskrifter ind.

vi kan lave en cURL test anmodning med vores cookies. Når jeg gør

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

jeg forventer at se siden komme tilbage, ikke en omdirigering til /users/sign_in

hvad jeg forventer, at en mislykket godkendelse skal se ud:

cookies:

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

og vi er i forretning:

Bemærk Disse statuskoder på 200? Jeg kan tail -f log/development.log og se al aktiviteten, hvilket indikerer, at de indsendte cookies er forbundet med en godkendt bruger.

første ting jeg bemærker er, at det ser ud til, at disse er ekstremt lange sideindlæsningstider.

jeg har belejring belastning omkring 162 forskellige URL ‘ er. Når du kører siege med standardkonfigurationen, kører den 20 samtidige brugere. Dette syntes at være lidt meget for hvad min localhost kunne håndtere, så jeg forsøgte at droppe antallet af samtidige brugere først til to brugere, så til en.

for at indstille antallet af samtidige brugere skal du blot tilføje --concurrent=NUM flag. Jeg blev stadig oversvømmet med output, så jeg faldt samtidige brugere til 1 og fjernede alt undtagen 20 sider fra listen over sider, der skal indlæses. Jeg gav det også et time flag på 60 sekunder: -t 60s

når alt er sagt og gjort, vil du se siege lave en masse tidsbestemte GET anmodninger, som sådan:

til sidst vil alt slå sig ud, og du får en oversigt over belastningstesten:

Ja, okay, det er sejt, Josh, men hvordan pokker skal jeg gøre noget nyttigt med dette?

store spørgsmål! Det er tid til at se, hvor vores app bruger det meste af sin tid, ude i den virkelige verden. Vi kunne gøre mere benchmarking lokalt, men naturligvis data fra den virkelige verden, indsamlet fra rigtige mennesker, der interagerer med din rigtige app i produktionen, er den mest nyttige datakilde.

Derfor skriver jeg snart, jeg har skrevet om, hvordan man får nyttige data fra en Rails-app til DataDog!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.