Debugning af ydelsesproblemer i produktionen kan være en smerte og i nogle tilfælde umuligt uden de rigtige værktøjer. Java-profilering har eksisteret i al evighed, men de java-profilere, som de fleste udviklere tænker på, er kun én type: standard JVM-profilere.
Det er imidlertid ikke nok at bruge én type profiler.
Sæt, at du skal analysere din applikations ydeevne. Der er flere profileringsaktiviteter, som du kan udføre. Generelt håndterer standardprofiler hukommelsesprofilering, CPU-profilering og trådprofilering.
Men selv med al denne dækning vil du ved at bruge en kombination af flere profilere finde flere ydelsesproblemer ved at bruge en kombination af flere profilere. Dette skyldes, at hver profiler er bedre i et bestemt aspekt til at jagte en ydelsesfejl.
I dette indlæg vil vi diskutere de tre typer af Java-profilere, og hvorfor vi har brug for dem alle, mens vi udvikler applikationen. Vi starter med typerne og dykker dybt ned i hver af dem.
Lad os tage et kig på de tre forskellige typer af Java-profilere:
- Standard JVM-profilere, der sporer alle detaljer i JVM’en (CPU, tråd, hukommelse, garbage collection osv.).
- Letvægtsprofilere, der fremhæver din applikation med en smule abstraktion.
- APM-værktøjer (Application Performance Management), der bruges til overvågning af applikationer, der lever i produktionsmiljøer.
Standard JVM-profilere
Produkter som VisualVM, JProfiler, YourKit og Java Mission Control.
En standard-Java-profiler giver helt sikkert flest data, men ikke nødvendigvis de mest nyttige oplysninger. Dette afhænger af typen af debuggingopgave.
JVM-profilere vil spore alle metodekald og hukommelsesforbrug. Dette giver en udvikler mulighed for at dykke ned i opkaldsstrukturen i den vinkel, han/hun ønsker.
Pros:
- Standardprofiler er gode til at opspore hukommelseslækager og beskriver detaljeret alt hukommelsesforbrug i JVM’en og hvilke klasser/objekter, der er ansvarlige. Muligheden for manuelt at køre garbage collection og derefter gennemgå hukommelsesforbruget kan nemt sætte spotlight på klasser og processer, der holder fast i hukommelse ved en fejl.
- Godt til at spore CPU-forbrug, en Java-profiler har normalt en CPU-sampling-funktion til at spore og aggregere CPU-tid efter klasse og metode for at hjælpe med at finde frem til hot spots.
Kontra:
- Kræver en direkte forbindelse til den overvågede JVM; dette ender med at begrænse brugen til udviklingsmiljøer i de fleste tilfælde. (Bemærk: Nogle profilere kan arbejde ud fra tråd- og hukommelsesdumps på en begrænset måde.)
- De gør din applikation langsommere; der kræves en god del processorkraft for den høje detaljeringsgrad, der leveres.
Lette Java-transaktionsprofilere
Produkter som XRebel og Stackify Prefix.
Lightweight-profilere har en anden tilgang til sporing af din applikation ved at injicere sig selv direkte ind i koden.
- Aspect-profilere bruger aspektorienteret programmering (AOP) til at injicere kode i starten og slutningen af bestemte metoder. Den injicerede kode kan starte en timer og derefter rapportere den forgangne tid, når metoden afsluttes. Disse profilere er enkle at opsætte, men du skal vide, hvad du skal profilere. Du kan se et eksempel i Spring AOP Method Profiling.
- Java Agent-profilere bruger Java Instrumentation API til at injicere kode i din applikation. Denne metode har større adgang til dit program, da koden bliver omskrevet på bytecode-niveau. Dette gør det muligt at instrumentere enhver kode, der kører i dit program, uanset om det er kode, du har skrevet, eller biblioteker fra tredjepart, som dit program er afhængigt af. Tjek denne introduktion til Java Agents for at se, hvordan det hele fungerer.
Aspect-profilere er ret nemme at opsætte, men de er begrænsede med hensyn til, hvad de kan overvåge, og de er besværet af at skulle beskrive alt det, som du ønsker at få sporet. Java Agents har en stor fordel i deres sporingsdybde, men de er meget mere komplicerede at skrive.
Stackify Prefix er en udviklerorienteret Java-profiler, der bruger Java Agent-profileringsmetoden bag kulisserne.
Det smarte er, at Prefix allerede kender de mest ønskede klasser og 3. partsbiblioteker, som udviklere ønsker at instrumentere – så du behøver ikke at specificere dem alle sammen. Plus, det tager alle statistikker fra instrumenteringen og viser dem på en enkel og forståelig måde.
Som et eksempel, når du kører en applikation ved hjælp af Hibernate, vil Prefix ikke kun give detaljerede oplysninger om den tid, der er gået for forespørgsler, men også vise parameterværdier for den genererede SQL. Når din app kalder til en SOAP/REST API, leverer Prefix indholdet af forespørgsel og svar.
Low Overhead, Java JVM Profiling in Production (APM)
Alle profilere indtil videre har været gode til udvikling, men det er afgørende at spore, hvordan dit system fungerer i produktion.
Produktion er altid et andet landskab – udviklings- og stagingopsætninger har typisk ikke de samme datasæt og belastning.
Java APM-værktøjer bruger typisk Java Agent-profileringsmetoden, men med forskellige instrumenteringsregler, så de kan køre uden at påvirke ydeevnen i produktioner. Tricket med disse profilere er at levere de rigtige oplysninger på en smart måde, så de ikke optager CPU-cyklusser.
Stackify’s Retrace er et APM-værktøj, der bruger den samme teknologi som Stackify Prefix med nogle få justeringer for at køre problemfrit i staging- og produktionsmiljøer.
Dette gøres ved at aggregere timingstatistik og sampling af spor. Dette giver dig synlighed på metode-niveau til din applikations kode, der kører i produktion.
Så når du har en langsom webanmodning, vil det oversættes til et spor, der vises i Retrace. Derfra kan du dykke ned og se, hvilke metoder der er synderen.
Retrace Screenshot: Web Request Aggregation over 4 timer
Hvorfor har du brug for alle 3 profilere til din applikation?
Standardprofilere er gode til at finde præstationsproblemer i udviklingsfasen. Men produktion er et andet scenarie. Din app’s adfærd kan ændre sig baseret på indgående trafik, serverforespørgsel, svar og mange andre ting.
Så, hvad er løsningen til produktionsmiljøet? APM-værktøjer er svaret. APM-værktøjer er rettet mod produktionsmiljøet og giver en rapport om din app’s ydeevne.
Så standardprofiler hjælper i udviklingen og APM-værktøjer hjælper i produktionen. Du undrer dig måske over, hvad behovet er for letvægtsprofilere til transaktioner.
Jamen, letvægtsprofilere følger en anden tilgang til kodeprofilering. De injicerer sig selv direkte i koden – især i starten og slutningen af en metode.
De er også nemme at opsætte og bruger relativt færre ressourcer. Dette er meget nyttigt for programmer, der bruger hardware transaktionshukommelse. Disse programmer kræver raffinerede analyseværktøjer, der påpeger præcis, hvilken metode eller funktion der forårsager problemer med ydeevnen.
Og utvivlsomt kan vi sige, at hvis du udvikler et komplekst program, har du brug for alle tre profilere. Hver profiler-type har en unik tilgang til at kontrollere en applikation for performanceproblemer.
RebelLabs undersøgelse viste også, at de fleste virksomheder bruger flere kodeprofilere til at finde performanceproblemer i deres applikation.
Hvorfor er nogle Java-profilere så dyre?
XRebel er et fedt værktøj, men det koster 365 dollars om året. Stackify Prefix er gratis og giver meget af den samme funktionalitet.
Det største problem med APM-løsninger er helt klart deres prisfastsættelse. De har traditionelt set været så dyre, at kun de største virksomheder havde råd til dem.
Det giver ikke meget mening at bruge ca. 100 dollars om måneden på en server hos Azure eller AWS og derefter bruge næsten 200 dollars om måneden for et produkt som New Relic.
Overvågningsværktøjer bør ikke koste mere end serverne!
Læs mere: APM-priserne er nu overkommelige for alle udviklere, og hvorfor de bør bekymre sig om det
Fuldstændig afklaring
Nu, hvor du har lært om de tre typer Java-kodeprofiler, er det tid til at beslutte, om du virkelig har brug for dem alle.
Svaret ligger i din applikations karakter.
Hvis den er lille som en lokal virksomhed eller et udgiftsstyringssystem til en butik, er profilering meget enkel. En standardprofiler vil gøre arbejdet.
Hvis du udvikler en webapplikation som f.eks. et kureranlægs sporingssystem, kan din applikation blive tilgået af tusindvis af brugere. I det tilfælde har du også brug for APM-værktøjer til produktionsmiljøet.
Sidst, hvis din applikation er til indlejrede systemer, har du brug for dem alle tre.
Vælg godt, og hav det sjovt med at udvikle en applikation, der leverer optimal ydeevne.