A teljesítményproblémák kiküszöbölése a termelésben fájdalmas lehet, és bizonyos esetekben lehetetlen a megfelelő eszközök nélkül. A Java profilozás már régóta létezik, de a legtöbb fejlesztőnek csak egyféle java profilozó jut eszébe: a szabványos JVM profilozók.
Az egyféle profilozó használata azonban nem elég.
Tegyük fel, hogy az alkalmazás teljesítményét elemzi. Többféle profilkészítési tevékenységet végezhet. Általában a szabványos profilozók kezelik a memóriaprofilozást, a CPU-profilozást és a szálprofilozást.
De még ennyi lefedettség mellett is, több profilozó kombinációjának használatával több teljesítményproblémát találhat. Ennek az az oka, hogy minden profilozó egy bizonyos szempontból jobb egy-egy teljesítményhiba üldözésénél.
Ebben a bejegyzésben a háromféle Java-profilozóról lesz szó, és arról, hogy miért van szükség mindegyikre az alkalmazás fejlesztése során. A típusokkal kezdünk, majd mindegyikbe mélyen belemerülünk.
Vessünk egy pillantást a Java-profilerek három különböző típusára:
- Standard JVM-profilerek, amelyek a JVM minden részletét (CPU, szál, memória, szemétgyűjtés stb.) nyomon követik.
- Könnyű profilerek, amelyek egy kis absztrakcióval emelik ki az alkalmazásodat.
- Az alkalmazások teljesítménykezelési (APM) eszközei, amelyeket a termelési környezetben élő alkalmazások felügyeletére használnak.
Standard JVM-profilerek
Termékek, mint a VisualVM, JProfiler, YourKit és Java Mission Control.
A standard Java-profiler minden bizonnyal a legtöbb adatot szolgáltatja, de nem feltétlenül a leghasznosabb információt. Ez a hibakeresési feladat típusától függ.
A JVM profilozók minden metódushívást és memóriahasználatot nyomon követnek. Ez lehetővé teszi a fejlesztő számára, hogy bármilyen szögből belemerüljön a hívásszerkezetbe.
Pros:
- Nagyszerű a memóriaszivárgások felkutatásához, a szabványos profilozók részletezik a JVM összes memóriahasználatát és azt, hogy mely osztályok/objektumok felelősek érte. A szemétgyűjtés kézi futtatásának, majd a memóriafogyasztás áttekintésének lehetősége könnyen rávilágíthat azokra az osztályokra és folyamatokra, amelyek hibásan tartják a memóriát.
- Jó a CPU-használat nyomon követésére, a Java-profiler általában CPU-mintavételi funkcióval rendelkezik, amely osztályonként és módszerenként követi és összesíti a CPU-időt, így segít a forró pontok felderítésében.
Hátrányok:
- Elvárja a közvetlen kapcsolatot a megfigyelt JVM-mel; ez a legtöbb esetben a fejlesztési környezetekre korlátozza a használatot. (Megjegyzés: egyes profilozók korlátozottan képesek feldolgozni a szál- és memóriadumpokat.)
- Lassítják az alkalmazást; a nyújtott magas szintű részletességhez jelentős feldolgozási teljesítményre van szükség.
Könnyű Java tranzakciós profilozók
Termékek, mint az XRebel és a Stackify Prefix.
A könnyűsúlyú profilozók más megközelítéssel követik nyomon az alkalmazást, mivel közvetlenül a kódba injektálják magukat.
- A Aspekt profilozók az aspektusorientált programozást (AOP) használják, hogy kódot injektáljanak a megadott metódusok elejére és végére. Az injektált kód elindíthat egy időzítőt, majd jelentheti az eltelt időt, amikor a módszer befejeződik. Ezeket a profilozókat egyszerű beállítani, de tudni kell, hogy mit kell profilozni. Egy példát lásd: Spring AOP Method Profiling.
- A Java Agent profilozók a Java Instrumentation API-t használják arra, hogy kódot injektáljanak az alkalmazásba. Ez a módszer nagyobb hozzáféréssel rendelkezik az alkalmazásához, mivel a kódot bytecode szinten írják át. Ez lehetővé teszi, hogy bármilyen, az alkalmazásban futó kódot instrumentáljanak – legyen szó az Ön által írt kódról vagy harmadik féltől származó könyvtárakról, amelyektől az alkalmazás függ. Nézze meg ezt a bevezetést a Java-ügynökökről, hogy megtudja, hogyan működik mindez.
Az Aspekt profilozókat elég könnyű beállítani, de korlátozottan tudják megfigyelni, és terhelik őket azzal, hogy mindent részletezniük kell, amit nyomon akar követni. A Java Agents nagy előnye a követési mélység, de sokkal bonyolultabb megírni.
A Stackify Prefix egy fejlesztő-orientált Java profilozó, amely a Java Agent profilozó módszerét használja a színfalak mögött.
A király dolog az, hogy a Prefix már ismeri a fejlesztők által leginkább kívánt osztályokat és harmadik féltől származó könyvtárakat, amelyeket instrumentálni akarnak – így nem kell mindet részletezni. Ráadásul az instrumentálásból származó összes statisztikát egyszerű és érthető módon jeleníti meg.
Egy Hibernate-et használó alkalmazás futtatásakor a Prefix például nemcsak a lekérdezések eltelt idejét részletezi, hanem a generált SQL paraméterértékeit is megjeleníti. Amikor az alkalmazás SOAP/REST API-t hív, a Prefix megjeleníti a kérés és a válasz tartalmát.
Low Overhead, Java JVM Profiling in Production (APM)
Az eddigi profilozók nagyszerűek voltak a fejlesztéshez, de a rendszer teljesítményének nyomon követése a termelésben kritikus fontosságú.
A termelés mindig más terep – a fejlesztési és a staging beállítások jellemzően nem ugyanazokkal az adatkészletekkel és terheléssel rendelkeznek.
A Java APM eszközök jellemzően a Java Agent profiler módszerét használják, de más instrumentálási szabályokkal, hogy a termelésben a teljesítmény befolyásolása nélkül fussanak. A trükk ezekkel a profilozókkal az, hogy a megfelelő információkat okos módon szolgáltassák, hogy ne foglalják a CPU-ciklusokat.
A Stackify Retrace egy APM-eszköz, amely ugyanazt a technológiát használja, mint a Stackify Prefix, néhány módosítással, hogy zökkenőmentesen fusson a staging és a termelési környezetben.
Ez az időzítési statisztikák aggregálásával és a nyomvonalak mintavételezésével történik. Ezáltal módszer-szintű betekintést nyerhet a termelésben futó alkalmazás kódjába.
Így ha van egy lassú webes kérés, az a Retrace-ben megjelenő nyomvonalra fog lefordítani. Onnan belemerülhet, és láthatja, hogy mely metódusok a bűnösök.
Retrace Screenshot: Web Request Aggregation over 4 hours
Miért van szüksége mindhárom profilozóra az alkalmazásához?
A szabványos profilozók jól alkalmasak a teljesítményproblémák megtalálására a fejlesztési szakaszban. A gyártás azonban más forgatókönyv. Az alkalmazásod viselkedése változhat a bejövő forgalom, a szerver kérése, a válasz és sok más dolog alapján.
Szóval, mi a megoldás a termelési környezetben? Az APM eszközök jelentik a választ. Az APM-eszközök a termelési környezetet célozzák meg, és jelentést készítenek az alkalmazás teljesítményéről.
A standard profilozók tehát a fejlesztésben, az APM-eszközök pedig a termelésben segítenek. Talán elgondolkodik azon, hogy mi szükség van a könnyűsúlyú tranzakcióprofilozókra.
Nos, a könnyűsúlyú profilozók más megközelítést követnek a kódprofilozáshoz. Közvetlenül a kódba injektálják magukat – különösen egy metódus elején és végén.
Egyszerűen beállíthatók, és viszonylag kevesebb erőforrást fogyasztanak. Ez rendkívül hasznos a hardveres tranzakciómemóriát használó alkalmazásoknál. Ezek az alkalmazások kifinomult elemzőeszközöket igényelnek, amelyek pontosan rámutatnak arra, hogy melyik módszer vagy függvény okoz teljesítményproblémákat.
Kétségtelenül kijelenthetjük, hogy ha összetett alkalmazást fejlesztünk, mindhárom profilozóra szükségünk lesz. Mindegyik profiler típus egyedi megközelítéssel ellenőrzi az alkalmazás teljesítményproblémáit.
A RebelLab felmérése azt is kimutatta, hogy a legtöbb vállalat több kódprofilert használ az alkalmazás teljesítményproblémáinak felkutatására.
Miért olyan drágák egyes Java-profilerek?
Az XRebel egy remek eszköz, de évi 365 dollárba kerül. A Stackify Prefix ingyenes, és nagyrészt ugyanazt a funkcionalitást nyújtja.
A legnagyobb probléma az APM megoldásokkal egyértelműen az árazásuk. Hagyományosan olyan drágák voltak, hogy csak a legnagyobb vállalatok engedhették meg maguknak.
Nincs sok értelme havonta körülbelül 100 dollárt költeni egy Azure vagy AWS szerverre, majd közel 200 dollárt egy olyan termékre, mint a New Relic.
A felügyeleti eszközök nem kerülhetnek többe, mint a szerverek!
Bővebben: APM Pricing Is Now Affordable for All Developers, and Why They Should Care
Wrapping It Up
Most, hogy megismerte a Java kódprofilerek három típusát, itt az ideje eldönteni, hogy valóban szüksége van-e mindegyikre.
A válasz az alkalmazás jellegében rejlik.
Ha kicsi, mint egy helyi vállalkozás vagy üzlet költségkezelő rendszere, a profilozás nagyon egyszerű. Egy szabványos profilozó is megteszi a dolgát.
Ha webes alkalmazást fejleszt, például egy futárszolgálat nyomon követési rendszerét, akkor az alkalmazásához akár több ezer felhasználó is hozzáférhet. Ebben az esetben APM eszközökre is szüksége lesz a termelési környezethez.
Végezetül, ha az alkalmazása beágyazott rendszerekhez készül, mindháromra szüksége lesz.
Válasszon jól, és jó szórakozást az optimális teljesítményt nyújtó alkalmazás fejlesztéséhez.