J2EE versus Microsoft.NET
Auteur: Rick F. van der Lans
Geschreven: december 2001
Gepubliceerd in: Computable, jaargang 2002, week
7
Onlangs woonde ik een lezing bij waarin de twee meest populaire platformen, J2EE en .NET, met elkaar vergeleken werden. Naast een functionele vergelijking gaf de spreker tevens een performance-vergelijking. Zijn conclusie was dat .NET ongeveer tien keer zo snel en zes keer zo goedkoop is als J2EE. Als dit inderdaad zo is, dan kunnen we J2EE direct in de vuilnisbak gooien, want niemand die bij zijn volle verstand is, zal dan ooit nog J2EE kiezen.
Maar is deze conclusie wel gerechtvaardigd? Hoe kwam deze man tot deze verbijsterende cijfers? Had hij soms zelf een testje gedaan met zijn eigen hobby-applicatie waarin hij gegevens over zijn goudvissen registreert? Gelukkig niet, hij had gebruik gemaakt van de TPC-C (Transaction Processing Council) benchmark-cijfers. Dit zijn serieuze benchmark-cijfers die door de onafhankelijke TPC gecontroleerd worden voordat ze gepubliceerd worden.
‘Oei, dit is niet best’, denkt de J2EE-aanhanger nu. ‘Want ik heb net afgelopen jaar mijn baas geadviseerd om bedrijfsbreed voor Java te kiezen.’
Ondanks het gebruik van deze serieuze benchmark zijn de conclusies van deze spreker toch ‘te kort door de bocht’. Het grootste manco in zijn redenering is dat er tot nu toe nog geen benchmarks met J2EE en .NET uitgevoerd zijn. Om toch een vergelijking mogelijk te maken, vergeleek hij de cijfers van klassieke applicatieservers, zoals IBM’s Encina en Bea’s Tuxedo met die van Microsoft’s COM+. Om de cijfers van J2EE te krijgen, verminderde hij de performance van Encina en Tuxedo met vijftig procent, maar deed dit niet voor .NET. Op zijn minst een vreemde aanpak.
Met de .NET configuratie kunnen meer dan 700.000 transacties van het type TPC-C per minuut verwerkt worden. De meeste J2EE platformen blijven steken onder de 100.000 transacties. Indien een leverancier deze cijfers publiceert, moet hij ook aangeven wat de kostprijs van de gehele configuratie per transactie is. Ook daar bleek Microsoft veel gunstiger uit te vallen: gemiddeld zes keer goedkoper. De spreker baseerde zijn mening dus op serieuze cijfers.
De .NET fan wrijft zich al gniffelend in zijn handen: ‘Zie je wel dat Java niet vooruit te branden is? Ik heb het altijd al geweten.’
Maar wat is TPC-C eigenlijk? Het is een applicatie die uit vijf verschillende transacties bestaat die gelijktijdig verwerkt moeten worden. Vijf verzamelingen met database-instructies die alle geopend worden met een start-transactie-instructie en afgesloten met een ‘commit’-instructie. En deze vijf transacties blijken door .NET veel sneller en goedkoper afgehandeld te worden. Het zijn wel transacties die qua moeilijkheidsgraad representatief zijn voor de transacties die door doorsnee bedrijven gedraaid worden.
‘Oh oh, dat gaat de verkeerde kant op’, mompelt de Microsoft-fan, wiens euforie al wat bekoeld is.
Maar mag je nu op basis van vijf transacties concluderen dat .NET veel sneller is dan J2EE? Het antwoord is nee. De belangrijkste les die ik geleerd heb bij het uitvoeren van benchmarks is dat verschillende soorten transacties verschillend door platformen verwerkt worden. Bijvoorbeeld, platform A blijkt transactie 1 veel sneller te verwerken dan platform B, terwijl voor transactie 2 het tegenovergestelde geldt. Op basis van een klein aantal transacties mag men niet generaliseren.
‘Aha’, denkt de Java-aanhanger, die weer wat rechter op gaat zitten, ‘dus misschien valt het allemaal wel mee.’
Als we proberen te berekenen hoeveel verschillende transacties er op deze planeet bestaan, dan moet dat een enorm aantal zijn. Stel dat een gemiddelde applicatie uit tien transacties bestaat. Een gemiddelde organisatie heeft vijftig applicaties; stel dat er één miljoen organisaties op deze planeet zijn. In totaal hebben we dan minimaal vijfhonderdmiljoen verschillende transacties. Nu zullen ze niet allemaal hetzelfde zijn, maar daartegenover staat dat we eigenlijk veel meer bedrijven hebben. In ieder geval hebben we het over meer dan één miljoen verschillende transacties.
‘Dat gaat inderdaad de verkeerde kant op’, denkt de Microsoft-fan, terwijl de Java-fan langzaam uit zijn depressie komt.
De conclusie dat .NET veel sneller en goedkoper is, is gebaseerd op vijf uit meer dan één miljoen transacties. En dat is een te simpele conclusie. In feite is het statistisch onverantwoord. Het zou vergelijkbaar zijn met de volgende situatie: aan vijf automobilisten uit Nederland en vijf uit België vragen we welk type auto ze hebben, waarna we concluderen dat Nederlanders in kleinere auto’s rijden.
De enige correcte conclusie die uit de TPC-C benchmark te trekken is, is dat .NET de TPC-C transacties veel sneller en goedkoper verwerkt. Maar het zou nuttiger zijn als we tevens honderd andere transacties in het onderzoek zouden betrekken. Dan zouden we wel algemene conclusies kunnen trekken.
De Java-fan begint opgelucht adem te halen: ‘Misschien is mijn carrière toch nog te redden en hoef ik mijn boot niet te verkopen.’
Let wel, ik concludeer niet dat .NET sneller en goedkoper is dan J2EE, maar ook niet andersom. Al bestaat er wel een ongefundeerde en foutieve perceptie in de Java-wereld dat .NET niet schaalbaar is. Zo denken sommige mensen nog steeds dat Italiaanse auto’s roestbakken zijn. Misschien gold dat vroeger, maar nu niet meer. Soms moeten we onze vooroordelen laten vallen. Zeker als bewezen is dat ze nergens meer op gebaseerd zijn. TPC-C wijst niet uit dat één van de twee platformen het snelst is. De huidige resultaten van de benchmarks met TPC-C dienen de Java-fans wel aan het denken te zetten. Java, wees gewaarschuwd, .NET komt er aan!
Titel: Reactie op ingezonden brief van de heer Appelo
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, en kan dus niet met .NET uitgevoerd worden. Deze benchmark zal dus niet helpen bij een vergelijking tussen J2EE en .NET.
Maar met de andere opmerkingen van de heer Appelo ben ik 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 transacties 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 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, 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 conlusie 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 performanceverschillen 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.
