Java suorituskyvyn tuunaamisesta

Törmäsin erinomaiseen artikkelisarjaan koskien Java suorituskyvyn tuunaamista. Aihe on ollut lähellä sydäntäni, sitä on tullut koulutettua ja konsulttihommissakin olen asiakkaita auttanut tiristämään virtuaalikoneesta kaikki tehot irti ja miettimään mitä hölmöilyjä EI SAA koodissa tehdä. Kuitenkin tuntuu että joka kuukausi aiheesta oppii lisää, ja aina välineet voisivat olla myös parempia mitä käyttelee.

 

Kirjoittelin jo taannoin New Relic tuotteesta joka osui omaan tutkaan JavaOne seminarissa vuonna 2011. Samaan sarjaan kuuluvat JRebel, JFrog ja Artifactory, hyviä vimpaimia kaikki. Näistä New Relic perustuu reaaliaikaiseen suorituskyvyn mittaukseen, monitorointiin ja analysointiin, ja vaikuttaisi rahan arvoiselta palikalta. Itselle ei ole ollut tarpeen kuitenkaan sitä ostella, koska omissa systeemeissä ei ole ihmeempiä suorituskykyhaasteita koskaan ollut, ja vähäiset mysteerit on pystytty ratkomaan ihan jconsolella tai visualvm:llä sekä logeilla.

 

Pari omaa kulmakiveä mitä tulee Java suorituskykyyn:

– Koodin optimoinnilla on lopulta varsin vähäinen merkitys, se mikä merkitsee on arkkitehtuuri ja se että koodissa ei hölmöillä eli turhaan haaskata suorituskykyä.

– Java on pääsääntöisesti nykyään C++ kielen kanssa tasalinjalla monessa operaatiossa, mutta on yhä alueita joissa se voi olla tolkuttoman hidasta. Pääsääntö siihen miten olla hölmöilemättä on ymmärtää Java muistimalli. Kiitos automaattisen roskankeruun tärkeintä on olla aiheuttamatta tarpeetonta roskankeruuta. Etenkään jos roskankeruualgoritmi on ns. Stop-The-World malli joka paussittaa oman koodin. Joissain mittaroimissani koodipohjissa vietetään aikaa roskankeruussa enemmän kuin itse tuotantokoodissa – pahimmillaan suhde on ollut jopa 99% vs 1%! Roskankeruuta voi välttää pääsääntöisesti miettimällä olioiden elinkaarta ja raskautta, ja tekemällä niistä tarvittaessa pitkäikäisempiä.

– Parhaiten optimoituu koodi joka on kirjoitettu hyvin yksinkertaisesti. Java virtuaalikone optimoi ajon aikana ja optimointi perustuu siihen miten koodi normaalisti toimii. Jos olet koodannut kummallisia virityksiä, virtuaalikone ei ehkä kykene koodia optimoimaan oikein tai voi jopa optimoida väärin. Muista siis optimoinnin kolme ensimmäistä sääntöä: Älä optimoi koodatessasi, älä optimoi koodatessasi, ÄLÄ OPTIMOI KOODATESSASI! Tee koodia joka on selkeää ja ymmärrettävää ensin, ja optimoi vasta tarpeen tullen ja mittaustuloksiin perustuen.

– Virtuaalikonetta voi tuunata. Sitä ei kuitenkaan kannata tehdä sokkona vaan taas pitäisi tietää mitä muistin sisällä tapahtuu. Turn on the headlights! Virtuaalikoneessakin on kosolti kytkimiä joilla sieltä saa tietoa muistista, optimoinneista ja ajankäytöstä. Löytyy myös visuaalisia työkaluja jotka ovat hyviä tiivistämään näkymiä suuresta datamassasta. Java ei nopeudu välttämättä lisäämällä isompi muistikampa ja parempi prosessori – se voi pahimmillaan jopa hidastua siitä (kiitos roskankeruun toiminnan).

Tuossapa taas viikon ärhentelyt. Java optimointi ei ole vaikeaa, mutta se vaatii osaamista, tietoa, työkaluja, ja hieman loogista päättelyä. Se vaatii myös testi edellä menemistä, koska joskus arvaus tai teoria osoittautuu vääräksi ja voi jopa hidastaa tai muuttaa sovellusta raskaammaksi tarpeettomasti.

Joka tapauksessa, tässä muiden ajatuksia aiheista ja välineistä. JRebelillä on tietysti oma lehmä ojassa mutta mielenkiintoista luettavaa silti. Meillä asiaa puidaan mm. Tehokas Java-kurssilla:

Tehokas Java-kurssi Tieturilla

Become a Java GC Expert artikkelisarja

 

 

Mainokset