Debuggning av prestandaproblem i produktionen kan vara jobbigt och i vissa fall omöjligt utan rätt verktyg. Java-profilering har funnits i evigheter, men de javaprofilers som de flesta utvecklare tänker på är bara en typ: standard JVM-profilers.
Det räcker dock inte med att använda en typ av profiler.
Antag att du ska analysera din applikations prestanda. Det finns flera profileringsaktiviteter som du kan utföra. Generellt sett hanterar standardprofiler minnesprofilering, CPU-profilering och trådprofilering.
Men även med all denna täckning kommer du att hitta fler prestandaproblem genom att använda en kombination av flera profilers. Detta beror på att varje profiler är bättre i en viss aspekt för att jaga ett prestandafel.
I det här inlägget kommer vi att diskutera de tre typerna av Java-profiler och varför vi behöver dem alla när vi utvecklar applikationen. Vi börjar med typerna och dyker sedan djupt ner i var och en av dem.
Låt oss ta en titt på de tre olika typerna av Java-profiler:
- Standard JVM-profiler som spårar varje detalj i JVM:n (CPU, tråd, minne, sophämtning etc.).
- Lättvikts-profiler som lyfter fram din applikation med en viss abstraktion.
- APM-verktyg (Application Performance Management) som används för att övervaka applikationer som lever i produktionsmiljöer.
Standard JVM-profiler
Produkter som VisualVM, JProfiler, YourKit och Java Mission Control.
En standard-Java-profilering ger förvisso mest data, men inte nödvändigtvis den mest användbara informationen. Detta beror på typen av felsökningsuppgift.
JVM-profiler spårar alla metodanrop och minnesanvändning. Detta gör det möjligt för en utvecklare att dyka ner i anropsstrukturen i vilken vinkel som helst.
Pros:
- Stor för att spåra minnesläckor, standardprofiler beskriver i detalj all minnesanvändning av JVM och vilka klasser/objekt som är ansvariga. Möjligheten att manuellt köra garbage collection och sedan granska minnesförbrukningen kan lätt sätta strålkastarljuset på klasser och processer som håller fast vid minne i misstag.
- Bra för att spåra CPU-användning, en Java-profilering tillhandahåller vanligtvis en CPU-samplingsfunktion för att spåra och aggregera CPU-tid per klass och metod för att hjälpa till att nollställa hot spots.
Minus:
- Kräver en direktanslutning till den övervakade JVM:n; detta slutar med att begränsa användningen till utvecklingsmiljöer i de flesta fall. (Observera: vissa profilers kan arbeta med tråd- och minnesdumpar på ett begränsat sätt.)
- De saktar ner din applikation; det krävs en hel del processorkraft för den höga detaljnivå som tillhandahålls.
Lättviktiga Java Transaction Profilers
Produkter som XRebel och Stackify Prefix.
Lättvikts-profilers tar ett annat tillvägagångssätt för att spåra din applikation genom att injicera sig själva direkt i koden.
- Aspect Profilers använder aspektorienterad programmering (AOP) för att injicera kod i början och slutet av specificerade metoder. Den injicerade koden kan starta en timer och sedan rapportera den förflutna tiden när metoden avslutas. Dessa profilerare är enkla att konfigurera, men du måste veta vad du ska profilera. Ett exempel finns i Spring AOP Method Profiling.
- Java Agent-profiler använder Java Instrumentation API för att injicera kod i din applikation. Den här metoden har större tillgång till din applikation eftersom koden skrivs om på bytecode-nivå. Detta gör det möjligt att instrumentera all kod som körs i din applikation, oavsett om det är kod som du har skrivit eller bibliotek från tredje part som din applikation är beroende av. Kolla in denna introduktion till Java Agents för att se hur allt detta fungerar.
Aspect-profiler är ganska enkla att sätta upp, men de är begränsade i vad de kan övervaka och är behäftade med detaljer om allt du vill att det ska spåras. Java Agents har en stor fördel i sitt spårningsdjup men är mycket mer komplicerade att skriva.
Stackify Prefix är en utvecklarorienterad Java-profilering som använder Java Agent-profileringsmetoden bakom kulisserna.
Det häftiga är att Prefix redan känner till de mest önskade klasserna och biblioteken från tredje part som utvecklare vill att de ska instrumenteras – så att du inte behöver beskriva allt i detalj. Dessutom tar Prefix all statistik från instrumenteringen och visar dem på ett enkelt och begripligt sätt.
Som exempel kan nämnas att när du kör en applikation med Hibernate kommer Prefix inte bara att ange den förflutna tiden för frågor utan även visa parametervärden för den genererade SQL:en. När din applikation anropar ett SOAP/REST API tillhandahåller Prefix innehållet i begäran och svar.
Low Overhead, Java JVM Profiling in Production (APM)
Alla profilerare hittills har varit bra för utveckling, men det är viktigt att spåra hur ditt system presterar i produktion.
Produktion är alltid ett annat landskap – utvecklings- och staginguppsättningar har vanligtvis inte samma datamängder och belastning.
Java APM-verktyg använder vanligtvis Java Agent-profileringsmetoden men med olika instrumenteringsregler för att de ska kunna köras utan att påverka prestandan i produktioner. Tricket med dessa profilerare är att ge rätt information på ett smart sätt för att inte ta upp CPU-cykler.
Stackify’s Retrace är ett APM-verktyg som använder samma teknik som Stackify Prefix med några justeringar för att kunna köras smidigt i staging- och produktionsmiljöer.
Detta görs genom att aggregera timingstatistik och sampling av spår. Detta ger dig insyn på metodnivå i din applikations kod som körs i produktionen.
Så när du har en långsam webbförfrågan kommer det att översättas till ett spår som visas i Retrace. Därifrån kan du dyka in och se vilka metoder som är boven i dramat.
Retrace Screenshot: Web Request Aggregation over 4 hours
Varför behöver du alla tre profilerna för din applikation?
Standardprofiler är bra på att hitta prestandaproblem i utvecklingsstadiet. Men produktion är ett annat scenario. Din applikations beteende kan förändras baserat på inkommande trafik, serverförfrågan, svar och många andra saker.
Så, vad är lösningen för produktionsmiljön? APM-verktyg är svaret. APM-verktyg är inriktade på produktionsmiljön och ger en rapport om appens prestanda.
Så, standardprofiler hjälper till i utvecklingen och APM-verktyg hjälper till i produktionen. Du kanske undrar vad behovet av lättviktiga transaktionsprofiler är.
Ja, lättviktiga profiler följer ett annat tillvägagångssätt för kodprofilering. De injicerar sig själva direkt i koden – särskilt i början och slutet av en metod.
De är också lätta att installera och förbrukar relativt få resurser. Detta är mycket användbart för tillämpningar som använder maskinvarutransaktionsminne. Dessa applikationer kräver förfinade analysverktyg som pekar ut exakt vilken metod eller funktion som orsakar prestandaproblem.
Om du utvecklar en komplex applikation kan vi utan tvekan säga att du kommer att behöva alla tre profilers. Varje profilertyp har ett unikt tillvägagångssätt för att kontrollera en applikation för prestandaproblem.
RebelLabs undersökning visade också att de flesta företag använder flera kodprofiler för att hitta prestandaproblem i sin applikation.
Varför är vissa Java-profilers så dyra?
XRebel är ett häftigt verktyg, men det kostar 365 dollar per år. Stackify Prefix är gratis och ger mycket av samma funktionalitet.
Det största problemet med APM-lösningar är definitivt deras prissättning. De har traditionellt varit så dyra att endast de största företagen haft råd med dem.
Det är inte särskilt vettigt att spendera cirka 100 dollar i månaden på en server hos Azure eller AWS och sedan spendera nästan 200 dollar i månaden för en produkt som New Relic.
Övervakningsverktyg bör inte kosta mer än servrarna!
Läs mer: APM Pricing Is Now Affordable for All Developers, and Why They Should Care
Wrapping It Up
Nu när du har lärt dig mer om de tre typerna av Java-kodprofiler är det dags att avgöra om du verkligen behöver dem alla.
Svaret ligger i applikationens karaktär.
Om det är en liten applikation, som ett lokalt företag eller en butiks utgiftshanteringssystem, är det mycket enkelt att göra profileringen. En standardprofiler klarar jobbet.
Om du utvecklar en webbapplikation som ett spårningssystem för en kurirfirma kan din applikation nås av tusentals användare. I det fallet behöver du också APM-verktyg för produktionsmiljön.
Till sist, om din applikation är avsedd för inbäddade system, behöver du alla tre.
Välj väl och ha kul med att utveckla en applikation som ger optimal prestanda.