![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
MySQL 5.0.20a en 5.0.32-bk
De eerste testkandidaat is MySQL 5.0.20a, dezelfde versie die we in alle eerdere reviews ook hebben gebruikt. Tijdens het opschalen van één core naar twee cores is er weinig bijzonders aan de hand. Clovertown is door zijn lagere kloksnelheid wel wat trager dan het topmodel Woodcrest, maar vertoont geen abnormaal gedrag. Ook de stap van een enkele dualcore naar een dubbele dualcore is weinig bijzonder vergeleken met eerdere ervaringen. Wanneer we twee dualcores met één quadcore vergelijken zien we dat het minder soepel verloopt. Omdat nog maar een van de twee bussen gebruikt kan worden, is de hoeveelheid beschikbare bandbreedte effectief in tweeën gesneden. De prestaties dalen hierdoor met ongeveer 5% onder zware belastingen van 25+ gelijktijdige gebruikers. De uiteindelijke stap naar acht cores blijkt funest te zijn: MySQL snapt het allemaal niet meer en de prestaties zakken onder het niveau van twee dualcores, om tegen het einde zelfs helemaal in te storten. Gemiddeld verliezen we onder zware belastingen 22% van onze prestaties.
Het is niet de eerste keer dat MySQL dit soort gedrag vertoont: in het artikel over de Sun T2000 zagen we precies hetzelfde gebeuren. De ontwikkelaars van MySQL zijn op de hoogte van dit probleem, maar toen we destijds samen met Sun op zoek waren naar een oplossing hiervoor was er nog niets beschikbaar. Voor deze test zijn we opnieuw op zoek gegaan en het bleek dat er inmiddels een patch in de stijgers staat. Deze is nog niet officieel uitgebracht, maar met een snapshot uit BitKeeper - het systeem dat de ontwikkelaars gebruiken om de broncode mee te beheren - van MySQL 5.0.32 konden we alvast kijken hoe ver men hiermee gevorderd is.
De nieuwste ontwikkelingen op het gebied van MySQL zijn interessant: men lijkt een deel van de prestaties met een laag aantal cores te hebben ingeleverd om bij hogere aantallen stabieler te blijven. Gemiddeld verliezen we met één core 10% ten opzichte van 5.0.20a en met twee cores 4%. Bij vier cores registreren we echter een winst van 1% en met acht cores gaat het 36% beter. Ook de piek van 616 requests per seconde voor 5.0.32-bk is duidelijk beter dan de 498 die we maximaal uit 5.0.20a konden persen. Nog steeds geldt echter dat MySQL zware belasting niet leuk vindt: na de piek zakt het aantal requests per seconde weer hard naar beneden.
Het is niet de eerste keer dat MySQL dit soort gedrag vertoont: in het artikel over de Sun T2000 zagen we precies hetzelfde gebeuren. De ontwikkelaars van MySQL zijn op de hoogte van dit probleem, maar toen we destijds samen met Sun op zoek waren naar een oplossing hiervoor was er nog niets beschikbaar. Voor deze test zijn we opnieuw op zoek gegaan en het bleek dat er inmiddels een patch in de stijgers staat. Deze is nog niet officieel uitgebracht, maar met een snapshot uit BitKeeper - het systeem dat de ontwikkelaars gebruiken om de broncode mee te beheren - van MySQL 5.0.32 konden we alvast kijken hoe ver men hiermee gevorderd is.
De nieuwste ontwikkelingen op het gebied van MySQL zijn interessant: men lijkt een deel van de prestaties met een laag aantal cores te hebben ingeleverd om bij hogere aantallen stabieler te blijven. Gemiddeld verliezen we met één core 10% ten opzichte van 5.0.20a en met twee cores 4%. Bij vier cores registreren we echter een winst van 1% en met acht cores gaat het 36% beter. Ook de piek van 616 requests per seconde voor 5.0.32-bk is duidelijk beter dan de 498 die we maximaal uit 5.0.20a konden persen. Nog steeds geldt echter dat MySQL zware belasting niet leuk vindt: na de piek zakt het aantal requests per seconde weer hard naar beneden.
Volgende pagina (PostgreSQL 8.2-dev - 7/8)
