Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 127, views: 138.287 •

Waarom in Java?

Behalve over onze keuze voor een oplossing, krijgen we ook vragen over het gekozen platform. We hebben gekozen voor een Servlet in Java. In 2008 was dat een prima en gebruikelijke oplossing om een REST-achtige omgeving op te zetten en wat ons betreft is het dat nog steeds. Uiteraard zijn er allerlei andere platforms en talen waarin hetzelfde had gekund, maar is dat ook beter of alleen anders?

Waarom niet gewoon in php zelf?

Zoals gezegd waren we in 2008 begonnen met de engine voor de Pricewatch. Destijds was ons duidelijk dat de php-code niet overweg kon met de hoeveelheid data die nodig was om een uitgebreide categorielisting te filteren, sorteren en samen met zijn facetten te presenteren. Het belangrijkste probleem zat hem in de complexiteit van die stappen samen; daardoor leek een pure SQL-oplossing onhaalbaar.

Met de eerste versie van de Pricewatch, met los instelbare specificaties per product, werd ons duidelijk dat de php-code behoorlijk wat gegevens moest ophalen. Die gegevens werden uit de database opgehaald en vertaald naar objecten, en dat kostte veel tijd. Om die tijd te besparen werden de objecten in Memcached opgeslagen. Ook het opslaan van objectbomen in Memcached bracht echter problemen met zich mee; veel van die data was namelijk groter dan 2MB, meer dan de maximale bucketgrootte van Memcached. Bovendien werd de objectboom, na unserialization, in php alsnog enorm. We zaten makkelijk over de 70MB aan ram-gebruik voor een paar duizend producten en dan hadden we nog niets gefilterd of gesorteerd.

Tweakers Pricewatch Engine prestatiewinst bij Laptops

Al met al kostten dergelijke handelingen na veelvuldig tunen nog altijd vaak meer dan een seconde, veel te lang voor onze eisen. Wij streven ernaar om de volledige pagina binnen 0,1 seconde te genereren!

Kortom, php viel af. Het belangrijkste knelpunt was dat er geen praktische manier was om de gegevens die uit de database of Memcached kwamen in ram vast te houden. Uiteindelijk bleek de Java-versie van diezelfde code zo veel sneller dat die inclusief de benodigde http-communicatie nog altijd veel minder tijd nodig had.

Waarom niet in taal X, die is toch veel beter dan Java?

Java is niet alleen een taal, het is een platform met diverse handige mogelijkheden. Zo is Tomcat een uitstekende Java Servlet-engine, terwijl de Servlet-technologie erg geschikt is voor onze toepassing. Daarnaast brengt de keuze voor Java een grote hoeveelheid bibliotheken met zich mee, zoals Lucene, Antlr, BCEL en Spring. Wat de taalkeuze op zich betreft komen we bovendien terug op de vraag die we ook stelden bij alternatieve oplossingen en databases: was het er al in 2008? En als het er al was, was het destijds net zo bekend en uitgebreid als het nu is? Kortom: was het in 2008 ook een goed alternatief?

Veel alternatieven beloven een betere productiviteit dan Java, maar als je het gebruik van een goede IDE meerekent, zijn de productiviteitsvoordelen van het alternatieve platform dan nog relevant? Een groot deel van het typewerk dat je in Java meer moet doen dan in andere platforms op de JVM valt immers weg door allerlei gradaties van autocompletion, code generation en short-keys. Denk daarbij aan het automatisch genereren van getters en setters, en het automatisch plaatsen van import-statements op het moment dat je het voorstel van de autocompletion accepteert.

Een ander sterk punt dat vaak genoemd wordt, bijvoorbeeld bij NodeJS en Scala, is de eenvoudige schaalbaarheid doordat allerlei werk asynchroon wordt gedaan. Dat levert echter vooral horizontale schaalbaarheid op, terwijl ook met de verticale schaalbaarheid rekening gehouden moet worden. Anders gezegd: als het alternatief wel meer requests tegelijk aankan (hogere concurrency), maar de performance vervolgens per stuk langzamer is (hogere latency en/of lagere througput) is het voor ons nog steeds geen goede oplossing.

Ironisch genoeg hadden we bij de introductie van Tweakers 7 inderdaad een schaalbaarheidsprobleem, dat echter niet door Tomcat 7 of Java kwam. We openden zo veel tcp-sockets naar de interne REST-service dat we uiteindelijk over de standaardgrens gingen van het aantal adressen dat Linux kan alloceren. Onze php-code noch onze Tomcat was dus de bottleneck en een asynchrone omgeving had hier geen winst opgeleverd.

Wat ons betreft was Java destijds een prima keus. Sterker, als we nu opnieuw moesten beginnen zou Java alsnog veel kans maken. We hebben nu eenmaal Java-kennis in huis en het is een uitgebreid platform met een scala aan bibliotheken en tools. Denk bijvoorbeeld aan de uitgebreide ide's en profilers die voor Java bestaan. Zijn er vergelijkbare tools voor de alternatieve platforms?

Nog een laatste punt: kan het alternatieve platform overweg met een paar gigabyte aan gegevens in ram? En als je dat op je platform hebt gestart, blijft het dan ook maandenlang stabiel draaien? Dat is namelijk wel onze ervaring met de Java-omgeving die we binnen Tomcat hebben draaien :)


Door Arjen van der Meijden

- Lead Developer

In Oktober 2001 begonnen met als voornaamste taak het technisch beheer van het forum. Daarna doorgegroeid tot senior developer en software architect. Nu lead developer, met een leidinggevende taak aan het team van programmeurs en systeembeheerders van Tweakers.net.

Lees meer over



Populair: Tablets Samsung Smartphones Beheer en beveiliging Google Apple Sony Games Consoles Politiek en recht

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013