MySQL-optimalisaties
Het testen van de UltraSparc T1 was geen makkelijke taak: we zijn ruim drie maanden bezig geweest om de optimale configuratie te vinden voor onze test, waarbij er door ons is samengewerkt met mensen van Sun, die op hun beurt weer met mensen van MySQL aan de slag zijn gegaan. In totaal zijn er ruim twee miljard queries gedraaid, verdeeld over ruim 3500 runs, die in serie meer dan 19 dagen zouden duren. Tijdens ons onderzoek hebben we zeer uiteenlopende resultaten gezien, wat ons leert dat deze machine niet makkelijk te temmen is. Wie het onderste uit de kan wil halen moet zorgen voor de juiste combinatie van software en instellingen, iets wat veel geduld kan vereisen. We zijn er nu redelijk van overtuigd dat we het beste hebben gedaan van wat we tot op dit moment hebben kunnen doen, maar Sun heeft onze benchmark op dit moment nog steeds in onderzoek, omdat het bedrijf gelooft dat het beter moet kunnen. Naar aanleiding van de problemen die wij ondervonden heeft men een verbetering bedacht voor de Sun Studio-compiler die later mogelijk een behoorlijke winst kan opleveren, maar we wilden daarop niet meer wachten met het publiceren van onze bevindingen.
Ten opzichte van het vorige artikel zijn er een aantal dingen veranderd aan de testmethode. Het meest zichtbare is dat we voor de resultaten over zijn gestapt van 'queries per seconde' naar 'requests per seconde'. Hierdoor kunnen verschillende databases beter met elkaar vergeleken worden, omdat de een meer queries nodig kan hebben om dezelfde pagina op te bouwen dan de ander. Een voorbeeld hiervan is MySQL 4.x, dat niet echt optimaal omgaat met subqueries en daardoor sneller is met een groter aantal simpelere opdrachten. Dit terwijl een alternatief als PostgreSQL zijn beste kant juist laat zien met ingewikkelde queries, waar er ook minder van nodig zijn.
Verder hebben we nu standaard twee cliëntmachines gebruikt om belasting op de database te genereren, omdat in onze vorige review - helaas pas tegen het einde van de test - bleek dat dit structureel betere resultaten opleverde. Ook hebben we functionaliteit ingebouwd die ons in staat stelt om cores en/of threads uit te schakelen, zodat we het schaalgedrag van de servers beter kunnen bestuderen.
Om het grote effect dat een paar kleine veranderingen kunnen hebben te demonstreren, staat hieronder een grafiek met verschillende MySQL 5.x-resultaten die we tijdens ons onderzoek hebben verkregen. Er is steeds een gelijk aantal cores en evenveel geheugen gebruikt, maar desondanks lopen de scores tussen verschillende versies van MySQL wild uiteen. Ook de instellingen kunnen een wereld van verschil maken: een door Sun onder handen genomen 5.0.18-versie was bijvoorbeeld behoorlijk sneller dan onze oorspronkelijke configuratie, terwijl er eigenlijk maar één parameter was aangepast.

Ten opzichte van het vorige artikel zijn er een aantal dingen veranderd aan de testmethode. Het meest zichtbare is dat we voor de resultaten over zijn gestapt van 'queries per seconde' naar 'requests per seconde'. Hierdoor kunnen verschillende databases beter met elkaar vergeleken worden, omdat de een meer queries nodig kan hebben om dezelfde pagina op te bouwen dan de ander. Een voorbeeld hiervan is MySQL 4.x, dat niet echt optimaal omgaat met subqueries en daardoor sneller is met een groter aantal simpelere opdrachten. Dit terwijl een alternatief als PostgreSQL zijn beste kant juist laat zien met ingewikkelde queries, waar er ook minder van nodig zijn.
Verder hebben we nu standaard twee cliëntmachines gebruikt om belasting op de database te genereren, omdat in onze vorige review - helaas pas tegen het einde van de test - bleek dat dit structureel betere resultaten opleverde. Ook hebben we functionaliteit ingebouwd die ons in staat stelt om cores en/of threads uit te schakelen, zodat we het schaalgedrag van de servers beter kunnen bestuderen.
Om het grote effect dat een paar kleine veranderingen kunnen hebben te demonstreren, staat hieronder een grafiek met verschillende MySQL 5.x-resultaten die we tijdens ons onderzoek hebben verkregen. Er is steeds een gelijk aantal cores en evenveel geheugen gebruikt, maar desondanks lopen de scores tussen verschillende versies van MySQL wild uiteen. Ook de instellingen kunnen een wereld van verschil maken: een door Sun onder handen genomen 5.0.18-versie was bijvoorbeeld behoorlijk sneller dan onze oorspronkelijke configuratie, terwijl er eigenlijk maar één parameter was aangepast.

Volgende pagina (MySQL-schaalgedrag - 6/10)