Share
Etterfulgt av de store innledende artiklene som ble omtalt nylig på Nettuts +, ser denne artikkelen ut hvordan du kan ta New Relic til neste nivå. Som et ytelsesovervåkingsverktøy er New Relic fantastisk, men hva med ytelse testing, før du går live. Det er der JMeter kommer inn for å spille. I denne opplæringen vil du se hvordan vi kan stresse teste applikasjonen vår under realistisk belastning, og kombinere utdataene fra JMeter og New Relic for å gi deg tillit til programytelsen din, før du slipper ut i et produksjonsmiljø.
Sponset innholdDette innholdet ble bestilt av NewRelic og ble skrevet og / eller redigert av Tuts + -laget. Vårt mål med sponset innhold er å publisere relevante og objektive opplæringsprogrammer, casestudier og inspirerende intervjuer som gir ekte pedagogisk verdi til våre lesere og gjør det mulig for oss å finansiere etableringen av mer nyttig innhold.
Hvorfor vente til distribusjon for å se hvordan søknaden din kommer til å koste mot ekte verdenstrafikk. Hvis det er en flaskehals i koden din som ødelegger brukeropplevelsen, vil du virkelig at det skal gå live? Hva om vi kunne finne disse flaskehalsene tidlig, forbedre ytelsen og levere en god applikasjon til våre sluttbrukere første gang, og opprettholde det som foregår med vanlig benchmarking. JMeter og New Relic sammen kan gi deg denne perfekte ytelsen test suite.
Før vi kan begynne å bruke New Relic og JMeter trenger vi en enkel app for å gjøre noen ytelsestesting på! Så, la oss skrive en enkel Ruby Sinatra app som har en tjeneste vi kan teste. Jeg vil ikke gå inn i etableringen av denne søknaden for mye, som du kan lese om Sinatra i andre artikler på Nettuts+.
Søknaden blir faked litt, slik at vi kan se noen interessante resultater i tråd med hva vi ser i ulike applikasjoner. Vi vil skrive en tjeneste som tar et ID, og avhengig av at ID returnerer en verdi enten med en gang eller med en forsinkelse. Dette vil vise oss hva som kan skje hvis forespørsler håndteres raskt eller sakte, og hvilken innvirkning dette har på appens generelle ytelse, slik mange brukere stiller forespørsler.
Her er koden som definerer tjenestene:
krever 'sinatra' krever 'puma' krever 'newrelic_rpm' modul Eksempel klasse App < Sinatra::Base get '/example/:id' do |id| result = id if id == '1' result = "This is our id: #id" end if id == '2' sleep 3 result = "We waited for id: #id" end result end end end
Som du kan se er dette tydeligvis et utprøvd eksempel, men ideen er at vi har noen raske svarende tjenester og en med en liten forsinkelse. Vi kan nå bruke denne appen og begynne å skrive vår ytelsesprøveplan i JMeter. La oss først få JMeter installert på vår maskin.
Å få søknaden din rapportering til New Relic er en veldig enkel prosess. New Relic støtter Ruby, Python, PHP, Java og andre plattformer, med lett å følge guider for alle. I tilfelle av Ruby en Sinatra er det bokstavelig talt en fire trinns prosess:
Når du har fulgt disse enkle trinnene, bør du begynne å se noen data som kommer til New Relic når du treffer appen din med litt trafikk. Du vet at det fungerer når appen er oppført og blir grønn.
For fullstendig skyld skal jeg bare oppgi en kort oversikt over hovedvisningen New Relic sørger for dine applikasjoner. Designet på New Relic er hovedsakelig å overvåke applikasjoner som er i produksjonsmiljøer med levende trafikk. Oversiktsskjermbildet gir et raskt oversikt over den nåværende statusen til søknaden din og hvordan den svarer på kundens forespørsler.
Skjermen kan brytes ned på følgende måte:
JMeter er et Java-program som lar deg bygge opp testplaner som kan stresse testen din. Du kan angi alt fra mengden samtidige brukere av tjenesten, til antall forespørsler de gjør et sekund. Du kan til og med rampe opp forespørgene for å se hvordan appen din behandler endring av belastning, akkurat som det kunne i real-world distribusjon.
Som en del av denne opplæringen vil jeg vise grunnleggende om å få en testplan som kjører mot programmene dine, men med et vell av plugins og dokumentasjon er det mange verktøy for å håndtere alle typer ytelsestest du trenger.
Installasjonen er ganske enkel og her vil vi vise instruksjoner for Mac og Linux.
På en Mac kan JMeter installeres veldig enkelt via Brew. Når du har Brew, prøv
Følgende kommando:
bryginstallasjon jmeter
På en Linux-maskin, bare last ned fra JMeter nedlastingssiden. Deretter følger du bare instruksjonene som følger med.
Når du har den viktigste JMeter-pakken, må vi også installere standard sett med plugins. Vi bruker senere en plugin, derfor må vi legge til disse for å kunne bruke den. Standard plugin-settet kan hentes fra denne linken: http://jmeter-plugins.org/downloads/file/JMeterPlugins-1.0.0.zip Når du har hentet utdrag til JMeter-pakken som ligger på: "/ usr / local / Kjeller / jmeter / "på en Mac, og hvor du installerte den på Linux.
Så nå har vi JMeter installert og vår enkle applikasjon, la oss teste denne appen og se hvordan den oppfører seg. Når du slår opp JMeter får du denne skjermen:
La oss nå angi nettadressen for våre forespørsler. Høyreklikk på "Testplan" i venstre rute, og velg 'Add -> Config Element -> HTTP Request Default'. Vi kan nå angi vår baseadresse her, slik som det.
Vi kan nå legge til antall tråder eller "brukere" av systemet vårt. For å gjøre dette, høyreklikk på "Testplan" igjen og velg 'Legg til -> Tråder (Brukere) -> Trådgruppe'. Vi kan da gå inn i brukerne, i dette tilfellet 20. Pass på å velge loop count forever-alternativet, da dette vil tillate oss å kontrollere tid og antall forespørsler via et plugin senere.
Når vi har trådgruppen, kan vi nå definere forespørsler vi ønsker å gjøre til vår søknad om at vi skal oppnå prestasjonstest. For å gjøre dette vil vi legge til "HTTP-forespørsel" til vår "Testplan". Dette kan du finne ved å høyreklikke på "Trådgruppe" og velge "Legg til -> Sampler -> HTTP-forespørsel". Vi kan da definere forespørselen om å lage i ruten som nedenfor.
Du kan se hvordan vi ikke trenger å definere basen URL, som vi gjorde det tidligere, og i stedet trenger bare å legge til banen for forespørselen. I dette tilfellet er banen til vårt eksempel / 1-svar. Du vil også legge merke til at jeg har gått videre og lagt til de to andre forespørslene sammen med resultatet og grafer, som vi skal bruke for å analysere resultatene av testene. Nå bør du få tak i å legge til elementer, og de kan lett bli funnet i menyen fra navnene sine. De viktigste to av interesse er "Throughput Shaping Timer" og "Composite Graph".
Shaping Timer gjør det mulig for oss å kartlegge hvordan vi ønsker at forespørslene skal gjøres til vår søknad over tid. For eksempel kan vi konfigurere en forespørsel per sekund i 60 sekunder, og deretter vil rampe opptil fem be om et sekund i 60 sekunder og se effekten dette har på våre svartider. La oss se hvordan vi konfigurerer det i Shaping Timer-ruten.
Så, ved å gå inn og legge til hver rad, kan du definere mengden forespørsel å lage og hvor lenge den skal gjøre dette for. Vi kan deretter se våre resultater ved hjelp av "Composite Graph", som viser transaksjonene som er gjort per sekund mot responstidspunktet for våre forespørsler. Dette krever minimal konfigurasjon, bare å legge til de to grafene vi vil kombinere, og deretter i innstillingene for komposittgrafen, legg til i grafene vi trenger slik:
Det er det! Vi kan nå kjøre vår testplan og begynne å se noen resultater. Hit spill mot toppen av skjermen, og klikk deretter på komposittgrafen. Det vil begynne å slå ut resultatene etter hvert som de kommer inn, og du kan få et bilde av hvordan søknaden din svarer. La oss se på resultatene våre.
Vi kan tydelig se hoppet i forespørsler om ett minutt har en ganske stor innvirkning på vår søknad. For første minuttet er forespørgene stabile på en per sekund og gir responstider på rundt to / tre ms. Men når vi øker til fem, øker responstidene litt og rammer fem og fem m / s. Det er åpenbart at disse er veldig raske responstider i den virkelige verden, men vi viser bare her hvordan vi kan øke belastningen og se påvirkningen, hvis noe, dette vil ha.
La oss sammenligne disse resultatene med tjenesten som har en forsinkelse på tre sekunder. Hvordan vil det takle økningen i belastningen? For å bytte til eksempel to, høyreklikk på eksempel ett og velg veksle. Dette vil deaktivere denne forespørselen, og deretter gjøre et veksle på eksempel to og det vil aktivere det. Pass på å klikke på "Slett alt" (Feilbørste) -ikonet øverst for å fjerne resultatene fra den siste runden, og deretter treffe spill.
Selv med den tre sekunders forsinkelsen, klarte serveren forespørsler ganske bra, og vi ser mye det samme i form av resultater for denne tjenesten. Bare noen få millisekunder øker ettersom forespørgene øker. Med en så enkel service, kan dette forventes.
Den virkelige kraften kommer nå med å kombinere disse dataene med New Relic. Vi kan for eksempel sette JMeter til å kjøre i en halv time med forskjellige variasjoner av belastning, og bruk deretter New Relic til å analysere resultatene og bruke dens borefunksjonalitet til å lete etter flaskehalser i applikasjonen. Disse kan deretter finjusteres, og øker ytelsen din før du leverer til kundene dine.
Igjen, jeg vil ikke gå inn i oppsettet av New Relic, da dette er dekket i andre nyere artikler på Nettuts + (Se her). Men når søknaden din er tilkoblet, er det bare et tilfelle av å generere lasten gjennom JMeter og logge inn på New Relic for å se resultatene. For dette løp har jeg satt opp Shaping Timer for å kjøre lasten vår i 30 minutter, og oppfordrer forespørsler fra fem til 10 og deretter 15 per sekund. Dette burde gi oss litt fornuftig trafikk til å se på i New Relic.
Når JMeter-testen har løpt, kan vi ta en titt på New Relic som vi nå kan se har stat på trafikken som følger gjennom appen.
Dette viser tydelig at rammene på forespørslene er høyest og treffer rundt 400 forespørsler per minutt (RPM), og responstidene forblir stabile på tre sekunder. Vi kan dype dypere inn i statistikken og se på transaksjonen vi lager. Hvis vi klikker til webtransaksjonsvisningen, kan vi se analysen New Relic har gjort på denne delen av programmet. Hvis koden som håndterte forespørselen hadde flere lag til den, for eksempel metoder for å ringe andre systemer for å få data før du presenterer tilbake til brukeren, ville vi se mer av en sammenbrudd.
For eksempel viser det til venstre at vi brukte 100% av forespørselstiden, i samtalen. Hvis vi hadde flere scener, for eksempel en samtale til en database, kan vi se en høy prosentandel der, og vi ville vite for å optimalisere spørringen til databasen for å øke ytelsen.
New Relic gir også en flott rapporteringsvisning på programdataene dine, kalt skalerbarhet. Denne rapporten kan være veldig nyttig for å overvåke programmene dine evne til å håndtere økt belastning. Grafen viser responstid mot forespørsler per minutt, og du kan tydelig se om det er noen nedbrytning i responstid som de øker. Dette er flott verktøy, og man bør ofte henvise til prestasjonstester som dette, men også i resultatovervåking av produksjonsprogrammet.
I vårt eksempel nedenfor er det klart at søknaden er i stand til å opprettholde en tre sekunders svartid, selv ettersom RPM øker.
New Relic gir også en annen visning, nemlig kapasitet. Dette gjør at vi kan se på hvor mye av de tilgjengelige ressursene vår søknad bruker. Det indikerer til utvikleren om antall forekomster som serverer søknaden din, er nok til å håndtere den typen last du får. Dette er viktig for å sikre at du ikke kjører i nærheten av kapasitet og har evnen til å håndtere eventuelle pigger i trafikk som kan oppstå utenfor din normale trafikkstrøm. New Relic oppsummerer siden godt, ved siden av analysen av vår søknad her, som vi kan se, er rettferdig bra, selv i denne enkelt forekomsten.
Målet med denne opplæringen var å vise deg hvordan du raskt konfigurerer JMeter-testplaner for søknaden din, slik at du kan teste kjøre ytelsen til søknaden din før du leverer til kundene dine. Denne tilnærmingen kan brukes i nye prosjekter, slik at søknaden du skal levere, er klar for ekte verdenstrafikk. Den kan også brukes på eldre applikasjoner, noe som gir deg en baseline ytelsesindikator, slik at når du gjør endringer fremover, kan du se om programmets ytelse forbedrer eller minker.
Ved å utnytte de gode verktøyene som tilbys av New Relic, kan du både overvåke søknaden din online i sanntid, men også ta sin verktøysett og bruke den til din egen offlineanalyse. Dette vil gi deg utvikleren, tillit til produktet ditt, både når det blir utviklet og når det slippes ut i naturen.
Accentsconagua