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 prestatievergelijking. 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.
| Is Microsoft .Net sneller dan J2EE? Columnist Rick van der Lans zwengelde de discussie hierover aan in zijn column van 1 februari: Op verzoek van Computable geven IBM, Microsoft, en een Java-consultant hun visie. |
‘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 prestatie van Encina en Tuxedo met vijftig procent, maar deed dit niet voor .Net. Op zijn minst een vreemde aanpak.
Met de .Net-configuratie zijn meer dan 700.000 transacties van het type TPC-C per minuut te verwerken. 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 verschillend 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 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!
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
