juli 2019

• Dumping unike Nettadresser i en tekstfil
• Besøker alle disse sidene i en Siege test
• Ekstra Ressurser

sist gang gravd jeg inn i å bruke apache benchmark for å gjøre ytelsestesting på en side som krever godkjenning for å få tilgang.

I Dag finner vi ut hvordan du bruker siege for å besøke mange unike Nettadresser på siden vår, og for å få referanser på den prosessen. Jeg skal neste finne ut ytelsesprofilering I Datadog, og med disse tre verktøyene satt sammen, bør vi være klare til å gjøre noen meningsfulle forbedringer i søknaden vår.

denne serien av innlegg er et direkte resultat Av Nate Berkopecs The Complete Guide To Rails Performance, med hjelp fra hans screencasts, Samt Steve Grossis Load Testing Rails Apps Med Apache Bench, Siege og JMeter. Bevæpnet med disse ressursene, og står på skuldrene til kjemper, av vi går.

Beleiringens beskrivelse:

Siege er en http belastning testing og benchmarking verktøyet. Den ble designet for å la webutviklere måle koden sin under tvang, for å se hvordan den vil stå opp for å laste på internett. Siege støtter grunnleggende autentisering, cookies, HTTP, HTTPS og FTP protokoller. Den lar brukeren treffe en server med et konfigurerbart antall simulerte klienter. Disse klientene plasserer serveren » under beleiring.»

du kan få beleiring med brew install siege.

jeg bruker det fordi det kan kjøre en liste Over Nettadresser du gir den. Tenk deg at appen din er en butikk, og den viser noen få tusen produkter. Hvert produkt skal ha en unik URL, noe som , eller kanskje . At product-guid sørger for at du kan ha unike Nettadresser, selv om det er to elementer med samme produktnavn.

Å Vite hva som er i databasen din, kan du enkelt sette sammen product-guid og product-name, holde den til slutten av , og komme opp med en liste over hundre eller tusen eller ti tusen unike produktadresser i søknaden din. Hvis du lagret disse til en tekstfil og Hadde Siege besøk hver eneste av disse sidene så raskt som mulig … dette kan se ut som en slags god stresstest,va?

Dumping unike Nettadresser i en tekstfil #

du vil sannsynligvis begynne å jobbe i en rails console økt, for å finne ut hvordan DU får tilgang TIL URL-skjemaet akkurat.

jeg sparket opp konsollen og skrev inn:

jeg så i vår dev-database for å finne en konto med mye data; konto med id 4887 er en konto knyttet TIL qa-automatisering, og har mye data i den.

campaign.to_param er hvordan vi bygger Nettadresser ut av kampanjene våre – det setter bare sammen guid med title – strengen, som levert av kunden, og kaller .parameterize på den. For denne gruppen av kampanjer genereres de programmatisk av vår automatiserte qa-testpakke.

når du er ferdig, kan du se noe slikt i all_campaign_urls.txt:

Besøker alle disse sidene i En Beleiringstest #

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

allerede vet jeg at vi kommer til å trenge --file, og --header, da vi må forfalske godkjente økter ved å sende inn noen informasjonskapsler, ser prosessen som jeg skisserte forrige gang

flagget --get ser nyttig ut:

HENT, dra NED HTTP-overskrifter og vis transaksjonen. Flott for søknad debugging.

Så, la oss logge inn som VÅR qa-konto. Siden jeg kjører alt dette lokalt, kan jeg finne den tilknyttede e-postadressen i VÅR DB. Jeg vet ikke passordet, selvfølgelig, men jeg kan tvinge en lokal tilbakestilling av passord, ta tak i e-posten I Mailcatcher, og sett den til det passordet jeg vil ha.

La oss få disse overskriftene inn.

Vi kan lage en cURL test forespørsel med våre cookies. Når jeg gjør

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

jeg forventer å se siden komme tilbake, ikke en viderekobling til /users/sign_in

hva jeg forventer at en mislykket godkjenning skal se ut:

informasjonskapsler:

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

Og vi er i virksomhet:

Legg merke til disse statuskodene 200? Jeg kan tail -f log/development.log og se all aktivitet, som indikerer at de innsendte informasjonskapslene er knyttet til en godkjent bruker.

Første jeg legger merke til er at det virker som om disse er ekstremt lange sidelastetider.

jeg Har Beleiringsbelastning om 162 forskjellige Nettadresser. Når du kjører siege med standardkonfigurasjonen, kjører den 20 samtidige brukere. Dette syntes å være litt mye for hva min localhost kunne håndtere, så jeg prøvde å slippe antall samtidige brukere først til to brukere, deretter til en.

for å angi antall samtidige brukere, legg bare til flagget --concurrent=NUM. Jeg var fortsatt oversvømmet med utgang, så jeg droppet samtidige brukere til 1 og fjernet alle, men 20 sider fra listen over sider for å laste opp. Jeg ga det et time flagg på 60 sekunder, også: -t 60s

Når alt er sagt og gjort, vil du se siege lage en haug med tidsbestemte GET forespørsler, som så:

Til Slutt vil alt slå seg ut, og du får et sammendrag av belastningstesten:

ja, ok, dette er kult, Josh, men hvordan skal jeg gjøre noe nyttig med dette?

Flott spørsmål! Det er på tide å se hvor vår app tilbringer mesteparten av sin tid, ute i den virkelige verden. Vi kunne gjøre mer benchmarking lokalt, men åpenbart virkelige data, samlet fra virkelige mennesker som samhandler med din virkelige app i produksjon, er den mest nyttige datakilden.

Derfor skriver jeg snart jeg har skrevet om hvordan jeg får nyttige data fra En Rails-app Til DataDog!