Hoe je de code tuned hangt uiteraard sterk af van wat voor applicatie je voor je hebt. "Het is een beetje als het afstellen van een raceauto", zegt Henrik Stahl, senior director van product strategy Java platform bij Oracle en spreker op JavaOne in San Francisco vorige week. "Regent het of is het droog? Hetzelfde geldt voor Javacode." Daarom is het volgens Stahl belangrijk om eerst een profiel te maken van de applicatie. Welke functies vervult de applicatie, wat moet er precies 'snel', en waar heb je meer speling?

Maar er zijn meer basisstappen die je moet nemen als Java-ontwikkelaar. Java is open source en wordt breed ondersteund, dus aan tuning-tools is geen gebrek. "Ik ga geen opsomming geven, want dat zouden de leveranciers die ik niet zou noemen niet op prijs stellen", lacht Stahl.

Stel een baseline vast

Hoe presteert de applicatie op dit moment ten opzichte van het doel? Dat kun je vergelijken door een baseline vast te stellen. Dat is een ijkpunt op basis van het applicatieprofiel waarin de belangrijkste parameters en prestatiecijfers zijn vastgelegd. "Je moet reproduceerbare resultaten kunnen overleggen voor je applicatie", zegt Stahl. "Dat betekent ook dat de baseline in de omgeving zelf moet worden vastgesteld, of in een omgeving waar de resultaten hetzelfde zouden zijn." Vervolgens kun je al je profilingtools en -vaardigheden erop loslaten.

"En je moet een doel hebben. Wil je een hoog aantal transacties per seconde? Wil je dat je webserver binnen 0.5 seconde reageert op een aanvraag?" Wie bijvoorbeeld bestellingen asynchroon wil laten afhandelen, of behoefte heeft aan andere batchgerelateerde taken, kijkt scherp naar de transacties per seconde. " Bijvoorbeeld wanneer je orders eerst verzamelt en in een keer doorstuurt naar logistiek of verzending."

Waar zitten de bottlenecks?

Vanaf dat moment begin je al met het eigenlijke tunen: waar zitten de knelpunten? Waardoor loopt het allemaal trager dan zou moeten? "Welke tools je daarvoor kunt gebruiken is afhankelijk van je applicatie", zegt Stahl. "Ook daar zijn enorm veel tools voor beschikbaar. Maar het komt erop neer dat je alle knelpunten in kaart brengt. Het is alsof je files analiseert: waar is een ongeluk gebeurt en moet de rijbaan worden vrijgemaakt?"

Zo is je database niet in staat om je load aan te kunnen, noemt Stahl als voorbeeld, waardoor de aanvraag vanuit de webserver niet snel genoeg wordt afgehandeld. "Dat kun je zien aan de responstijd van de database." Maar soms is het ook minder duidelijk. "Ik heb ooit bij een grote bank in Zweden gezien hoe een webserver constant omviel. Iedere keer als hij opstartte, ging hij neer", zegt Stahl. "Ze besloten om meer geheugen toe te wijzen aan de webserver. Gevolg: hij viel alleen maar sneller om. Het probleem bleek in de backend te liggen.

Meer middelen toewijzen aan de webserver betekende alleen maar dat meer gebruikers naar binnen kwamen, en in de rij komen voor de backend." Hij vergelijkt het met een winkel: als het ene kassameisje dat je hebt de stroom klanten niet aankan, dan helpt het niet om de ingang van de winkel te verbreden.

Verhelp de bottlenecks

Daarna is het zaak systematisch te werk te gaan. "Verhelp een knelpunt, en kijk vervolgens naar de nieuwe resultaten. Is het beter geworden? Als het antwoord 'ja' is, ga je naar het volgende knelpunt." Zo niet, dan zul je naar andere oplossingen moeten kijken. "Het is het waard om een paar rondes te draaien, want zeker in het begin vind je altijd wel iets dat beter kan."

Weet wanneer je moet kappen!

Zoals eerder gemeld: het kan altijd sneller, beter, efficiënter. Maar constant blijven tunen kost tijd, en tijd kost geld. "Naarmate je meer tuned, des te kleiner worden de prestatiewinsten die je behaalt", zegt Stahl. "De eerste keer kun je bijvoorbeeld ontdekken dat slechts een systeem van een heel cluster aan staat. Foutje, bedankt."

Maar de dingen die je vervolgens ziet zullen meer moeite kosten om boven water te krijgen, terwijl de winsten kleiner zijn. Bedenk ook dat op het moment dat er iets binnen je omgeving verandert, je opnieuw moet gaan tunen. "Er komt een punt dat het verder tunen van de code het gewoon niet meer waard is."