U bent hier

Performance, meer caffeine of migraine?

Ontwikkelaars produceren bergen code, compileren de handel en kijken of de functionaliteit daadwerkelijk enigszins overkomt.
Beheerders daarentegen zien de impact van een applicatie op hun totale netwerk, tussen deze 2 werelden wil dan ook nog wel eens enige discrepantie ontstaan.

Wat namelijk de ontwikkelaar als perfectly acceptable kan beschouwen om zijn doel te bereiken, bijvoorbeeld een applicatie bepaalde verificaties laten uitvoeren, kan in een productie omgeving een bijna dodelijke ervaring betekenen voor arme web/database/file-servers.
Wat kan beginnen als een kleine workaround kan uitgroeien tot een stuk legacy code waarin geen enkele ontwikkelaar met enige vorm van gezond verstand zich zal wagen, zeg maar het Big Ball of Mud concept.

Als de ontwikkeling van een applicatie zich voor enkele jaren voortzet kan ook bij het ontwikkelaarsteam aan kennis ingeboet worden, met soms het gevolg dat bepaalde stukken legacy code inderdaad blijven stilstaan, niemand waagt zich eraan of men heeft de gedachte dat 'het al 10 jaar werkt, waarom dus veranderen?'.
Juist in dergelijk situaties kunnen incidenten op performancegebied een bijna onbeheersbare situatie opleveren.

Of we het nu namelijk over een web-based of stand-alone applicatie hebben, de gebruikerstevredenheid zal alleen maar van een acceptabel niveau zijn als de applicatie ook daadwerkelijk doet wat het moet doen en dat het liefst ook nog in een zo beperkt mogelijk tijdsbestek.

Zeker web-based applicaties kunnen starten als een simpel eendimensionaal PHP scriptje, maar uiteindelijk uitgroeien tot een spinneweb van gelaagde objecten, bootstrapscripts (bijv voor databaseverbindingen), includescripts, etc.
Al deze opeenstapelingen van lagen vormen individueel gezien niet een bijzondere performancepenalty, maar eenmaal op elkaar geplaatst kan een webserver het er danig warm van krijgen.

Soms kan het danook een onvermijdelijke stap blijken om een applicatie 'from-scratch' opnieuw te ontwikkelen, meestal kan men dat moment definieren als het moment waarop het ontwikkelaarsteam meer moeite lijkt te hebben met de oude code beheersen dan een nieuw script te brouwen.
Veel performanceoptimalisatietrajecten spitsen zich slechts toe op het optimaliseren van bestaande scripts en structuren, terwijl juist mogelijke inefficientie hierin dan blijft bestaan.
Een zeer lezenswaardig stukje is het volgende artikel van een van de hoofd ontikkelaars/architecten van, het enige tijd geleden ter ziele genane, Enron, deze persoon was verantwoordelijk voor de oorspronkelijke ontwikkeling van EnronOnline, een web-based applicatie voor realtime e-commerce.
Performance bleek een enorme bottleneck voor dit soort applicatie, waar duizenden bezoekers tegelijk in deze units wilden handelen.

Bij diverse bedrijven heeft men dan ook besloten de eerste versie vooral als een bijzonder goede leerschool te beschouwen van hoe bepaalde logische structuren vormgegeven konden worden, en deze ervaring gebruikt om een nieuwe versie volledig overnieuw te ontwikkelen om alle valkuilen en inefficienties te vermijden, het resultaat was een van de eerste full scale realtime web-based unit dealing/trading applicaties.

Maar performanceoptimalisatie is meer dan het beseffen van de benodigde logica, en het implementeren hiervan.
Het is ook vooral gebruik maken van beschikbare analysetools, wanneer een applicatie in testfase verkeerd dient effectief gezien elk object/functie daadwerkelijk aan een toets te voldoen.
Bijzonder belangrijk is ook dat deze monitoring gedaan wordt door van de applicatie losstaande monitoring technieken.
Niets is bedriegelijker dan de debug-output van een applicatie vertrouwen terwijl juist het draaien van deze debuglogging al een enorme performancepenalty inhoud, debug-output is zeer nuttig voor het tracen van logische (of simpelweg syntaxis) fouten in een applicatie maar totaal zinloos in geval van performancemonitoring.

Bij web applicaties is het zeer zinnig vooral te kijken in hoeverre men bepaalde communicatie/data-afhandeling zo efficient mogelijk kan laten verlopen, maw om een voorpagina van een site samen te stellen kunnen diverse queries benodigd zijn, voor bijv nieuwsberichten, headlines maar ook advertenties e.d.
Deze queries worden vaak los van elkaar afgehandeld, waardoor voor ieder van deze een afzonderlijke thread naar de database gestart moet worden.
Vele malen sneller zou zijn dit query zoveel mogelijk alle data in één keer te laten ophalen.

Performanceverbetering is zeker een langdurig en intensief traject, maar de vruchten die het afwerpt wegen ruimschoots op tegen alle soorten van mogelijke persoonlijke bezwaren of inspanningen die op de lange duur geleverd dienen te worden om een sleutelapplicatie uit de modder te moeten trekken.

Undefined