Onlangs besteedde Rick van de Lans zijn column aan een lezing waarin werd gesteld dat J2EE circa tien keer zo snel is als .Net. De columnist verwierp deze conclusie omdat hij vindt dat de in de benchmark gebruikte TPC-C transacties niet representatief zijn. Jurgen Appelo treedt in discussie met Van der Lans.
De kritiek van Rick van der Lans in zijn column J2EE versus .Net (Computable, 1 februari) vind ik een beetje flauw. Als je vijf ‘representatieve’ transacties neemt, dan hoeven deze (statistisch gezien) niet representatief te zijn voor alle transacties in de hele wereld. Maar een zeer sterke indicatie blijft het aangetoonde snelheidsverschil bij deze transacties natuurlijk wel. Daarnaast kun je vijf ‘representatief’ gekozen transacties natuurlijk niet vergelijken met vijf ‘willekeurig’ gekozen auto’s. De vijf transacties zijn geen aselecte steekproef maar een zorgvuldige selectie. Als de heer Van der Lans wil schermen met statistisch verantwoorde formuleringen, moet hij toch zelf nog eerst wat huiswerk doen. Als op basis van vijf ‘representatieve’ transacties blijkt dat er een enorm snelheidsverschil waarneembaar is, dan kun je gerust de uitspraak doen dat er een ‘hele grote kans’ bestaat dat .Net een stuk sneller is dan J2EE. En it-managers moeten hun budgetten nu eenmaal vaak verwedden op basis van kansen en (helaas) maar heel weinig op basis van zekerheden. Vervolgens vindt Van der Lans het ‘op z’n minst vreemd’ dat tijdens de bewuste presentatie de fictieve snelheid 50 procent verminderd werd voor J2EE, maar niet voor .Net. Misschien heeft hij, net als ik overigens, tijdens dat gedeelte niet alles goed kunnen volgen. De presentator heeft namelijk gezegd dat hij dit moest doen vanwege de snelheidsbeperkende aanwezigheid van Java’s virtual machine, die .Net duidelijk niet heeft. En die 50 procent was nog erg coulant gekozen.
Deze hele discussie zou natuurlijk een stuk gemakkelijker gaan wanneer Sun zelf ook eens met wat ‘benchmark’-statistieken zou komen. Maar om één of andere reden lijkt het of ze die niet durven te publiceren. Wat zegt dat over de kans dat .Net sneller is dan J2EE?
Jurgen Appelo
Naschrift
In de eerste plaats wil ik de heer Appelo bedanken voor het feit dat hij een reactie heeft ingestuurd op mijn column over J2EE versus .Net. Het onderwerp is belangrijk genoeg om door velen besproken en beschreven te worden, dus de inzending verdient dan ook een reactie van mijn hand.
Met twee opmerkingen van de heer Appelo ben ik het eens.
Allereerst tonen de cijfers aan dat .Net veel meer in zijn mars heeft dan velen denken. De TPC-C benchmark-cijfers die met de Microsoft-software gerealiseerd zijn, zien er zeer goed uit. Dit geef ik ook in mijn column aan: "De huidige resultaten van de benchmarks met TPC-C dienen de Java-fans wel aan het denken te zetten."
Ten tweede wordt het echt tijd dat de leveranciers van Java-applicatieservers eens TPC-C resultaten laten zien. We zouden haast gaan denken dat ze het wel geprobeerd hebben, maar de resultaten niet durven te publiceren.
Het is trouwens interessant om te bemerken dat de JCP (Java Community Process) een eigen benchmark heeft gedefinieerd, de zogenaamde ECperf. Deze is speciaal voor de Java-applicatieservers ontwikkeld is, en kan dus niet met .Net uitgevoerd worden. Deze benchmark zal dus niet helpen bij een vergelijking tussen J2EE en .Net.
Met de andere opmerkingen van de heer Appelo ben ik het in het geheel niet eens. Het is niet mogelijk vijf transacties te vinden die representatief zijn voor het brede scala aan transacties die reeds ontwikkeld zijn of nog ontwikkeld moeten worden. De TPC zelf formuleert het als volgt: "… the range of customer application environments is almost infinite …".
Hoe selectief die keuze ook gemaakt wordt, het zal niet lukken. Er zijn teveel variabelen die de aard van een transactie kunnen beïnvloeden, zodat een representatieve keuze van vijf onmogelijk is. Mogelijke variabelen zijn de complexiteit van de instructies waaruit de transactie is opgebouwd, of het een ‘query’- of mutatie-intensieve transactie is, of de transactie veel of weinig gegevens benadert, of het veel lange of weinig korte transacties zijn. En zo kan ik nog wel even doorgaan.
Had de betreffende spreker keurig aangegeven dat de .Net-omgeving wat betreft de TPC-C benchmark x maal is, dan was dat een correcte conclusie geweest. Maar nee, hij concludeerde dat .Net x maal sneller was dan J2EE, dus zonder de vermelding dat de cijfers alleen voor TPC-C gelden.
Daarnaast vindt de heer Appelo dat we de spreker op zijn woord moeten geloven en dat we 50 procent vertraging moeten inbouwen vanwege de "snelheidsbeperkende aanwezigheid van Java’s virtual machine". Hoe de spreker aan die 50 procent is gekomen is een raadsel, want om tot een dergelijk cijfer te komen dient hij zelf een dergelijke operatie uitgevoerd te hebben. Hij had dat voor geen enkele Java-omgeving gedaan. Het had dus ook 25 procent of 75 procent kunnen zijn. De heer Appelo geeft echter geen extra argumenten waarom we dit zouden moeten geloven.
Een simpele rekensom maakt echter duidelijk dat die 50 procent zeer onwaarschijnlijk is. De verwerkingstijd van een TPC-C transactie wordt bepaald door enkele softwaremodules. De applicatie waarin de transactie opgenomen is, vuurt de instructies af op de applicatieserver; deze geeft de instructies door aan de databaseserver die weer i/o-instructies afvuurt op de i/o-manager van het besturingssysteem. (Ik realiseer me dat dit een simplificatie van de werkelijkheid is, maar het is voldoende detail voor mijn rekensom.) De totale verwerkingstijd wordt dus bepaald door de hoeveelheid tijd die respectievelijk de applicatieserver, de databaseserver en de i/o-manager gebruikt. Omdat de TPC-C benchmark een zeer database-intensieve applicatie is, kunnen we aannemen dat de databaseserver samen met de i/o-manager de meeste verwerkingstijd voor hun rekening nemen. Laten we ervan uitgaan dat de applicatieserver goed is voor maximaal 20 procent van de totale verwerkingstijd. Dit zou wel eens minder kunnen zijn, want vergeet niet dat bij een database-intensieve applicatie i/o vaak de bottleneck is.
Een van de belangrijke cijfers die een TPC-C benchmark ons geeft is de zogenaamde ’throughput’. Dit cijfer geeft aan hoeveel transacties er per tijdseenheid verwerkt kunnen worden. De conclusie van de spreker was dus dat, als een benchmark-omgeving met een klassieke TP-monitor een bepaalde ’throughput’ heeft, de Java-omgeving, die boven op de TP-monitor gebouwd is, de throughput met 50 procent vermindert. Of met ander woorden, dat als een klassieke TP-monitor bijvoorbeeld 100 microseconden over een transactie doet, de Java-omgeving, die hierop gebouwd is, er 150 microseconden over doet; 50 procent meer. Maar als de TP-monitor inderdaad slechts 20 procent, dus 20 microseconden van de totale verwerkingstijd voor zijn rekening neemt, dan is die Java applicatieserver 3,5 keer zo langzaam als de oude TP-monitor (20 versus 70 seconden). Dit lijkt me hoogst onwaarschijnlijk.
Tijdens ontmoetingen bij leveranciers met enkele ontwikkelaars van Java-applicatieservers is mij getoond dat de Java-applicatieserver voor sommige transacties zelfs sneller is dan de klassieke TP-monitor. Deze cijfers heb ik echter niet kunnen controleren, maar in ieder geval konden zij wel iets laten zien.
Kortom, de conclusie dat in het algemeen .Net vele malen sneller is dan welke J2EE-omgeving dan ook, berust niet op cijfers, maar op het vermoeden van een spreker. Echter, de conclusie dat .Net momenteel de TPC-C benchmark veel sneller verwerkt dan de J2EE-omgevingen, had wel correct geweest. Deze resultaten dienen de Java-wereld wel aan het denken te zetten.
Tenslotte vind ik dat deze discussie over de prestatieverschillen tussen J2EE en .Net wel met technische argumenten gevoerd moet worden. Hopelijk heeft mijn reactie enige technische argumenten aangedragen en daarmee bijgedragen aan de discussie.
Rick Van Der Lans Columnist En Onafhankelijk Adviseur
