Cookies op Tweakers

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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 206 reacties

In de afgelopen periode hebben we bij Tweakers diverse belangrijke stukken code herschreven. Eerder dit jaar is ons vernieuwde reactiesysteem geïntroduceerd, en in april en mei zijn we bezig geweest om het karmasysteem te herschrijven.

Daarbij is niet alleen de functionaliteit aangepakt, ook de prestaties van de componenten zijn opnieuw bekeken. Bij beide systemen zijn de prestaties bij het gebruik van de database dominant voor de totale benodigde tijd. Een goede vorm om de data op te slaan, met de juiste indices, en het efficiënt uitlezen van de gegevens zijn dus erg belangrijk. Voor beide voorbeelden gebruiken we onze centrale MySQL-database.

Op internet zijn allerlei uitspraken over de snelheid van sql-databases te vinden. In de afgelopen jaren zijn er bijvoorbeeld allerlei NoSQL-databases verschenen en vaak worden dan een of meer negatieve aspecten genoemd die met een dergelijke nieuwe database beter gaan. Vaak wordt gesteld dat het voldoen aan alle vier de componenten van acid de prestaties en schaalbaarheid in de weg zit. Daarbij worden dan vooral consistency en isolation zwakker uitgewerkt in die systemen.

Ook de complexe queries die met sql mogelijk zijn, worden genoemd; die mogelijkheid zou slecht zijn voor de prestaties en bovendien helemaal niet nodig zijn. Het kunnen join-en van tabellen en de mogelijkheden voor subqueries zijn de vaste voorbeelden daarbij. Het gaat dan soms zelfs zover dat in één adem geadviseerd wordt om die zaken ook te vermijden als je wél sql blijft gebruiken. Het zou dan eveneens slecht zijn voor de prestaties en lastig te verenigen zijn met sharding-functionaliteit. Het advies is dan om de queries zo simpel mogelijk te houden en liefst alleen via de primary key in een tabel te zoeken. Complexe handelingen, zoals het combineren van data, kunnen tenslotte ook in de applicatielaag gedaan worden.

Als je een object relational mapper gebruikt, zoals Doctrine, dan wordt dat advies effectief standaard opgevolgd. Bij een orm moet er meestal zelfs moeite gedaan worden om van dat model af te wijken. Een join gebruiken betekent vaak extra code toevoegen.

Hoewel het altijd verstandig is om code eenvoudig te houden, is het wel zonde als daardoor grote prestatiewinsten blijven liggen. De adviezen over sharding van data zijn tenslotte alleen relevant als dat echt gebruikt wordt. Als er geen sharding wordt gebruikt, is het juist handig om data uit diverse queries in de database al te koppelen. Dat kan flink wat overhead schelen; denk aan de losse round-trips van query en data, rechtenchecks en allerlei aanverwante handelingen die dan in de database minder vaak gedaan hoeven te worden.

Er is daarbij natuurlijk wel verschil tussen de diverse platforms. Op sommige platforms, waaronder veel soorten applicaties in java-applicatieservers, kunnen orm's gegevens in het geheugen van de applicatie cachen. In zulke gevallen worden al round-trips bespaard, maar dat valt of staat dan met de effectieve hitratio van de cache en de kwaliteit van de synchronisatie met de database. De hier gegeven adviezen gelden vooral voor toepassingen waarbij dergelijke caches niet praktisch zijn, zoals meestal bij php het geval is.

Wat ons betreft valt de database van Tweakers met 219GB trouwens niet in de orde van grootte om over te stappen op sharding of andere technieken om verscheidene servers tegelijk te gebruiken. Overigens hebben we er wel op diverse manieren voor gezorgd dat de MySQL-database niet voor alle gegevens gebruikt hoeft te worden. We hebben er bijvoorbeeld voor gekozen om bepaalde stukken data in MongoDB op te slaan of in memcached te cachen en veel van de informatie wordt via onze Java-omgeving opgevraagd.

In dit artikel beschrijven we twee toepassingen waarbij de databaseprestaties voor ons belangrijk waren. Daarbij laten we stapsgewijs een aantal optimalisaties zien die significante verbeteringen in de prestaties gaven. Bedenk wel dat dit artikel niet gaat over het plaatsen van de juiste indices of het optimisaliseren van de instellingen van een database. Dit is een parallelle taak waarbij bekeken wordt of de database wel optimaal ingezet wordt, maar een goed geoptimaliseerde tabelstructuur en database zijn uiteraard ook belangrijk voor goede prestaties.


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 softwarearchitect. Nu lead developer, met een leidinggevende taak binnen het team van programmeurs en systeembeheerders van Tweakers.

Lees meer over



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True