Serverduel: Xeon Woodcrest vs. Opteron Socket F

Benchmarkbeschrijving

Het doel van onze benchmark is het simuleren van de belasting die Tweakers.net (exclusief forum) onder normale omstandigheden veroorzaakt op de database. De productieversie - degene die net heeft geholpen tijdens het bakken van deze pagina - draait een MySQL 4.0-installatie met bijna tweehonderd tabellen, die sterk variëren in grootte (van enkele kilobytes tot enkele gigabytes) en mate van activiteit. De database draait op een toegewijd systeem en krijgt zijn opdrachten toegeworpen vanuit een loadbalanced cluster van webservers. Deze scheiding van data en (web)applicatie is een klassiek 'two-tier' patroon.

De webservers zijn voorzien van PHP 4.4 en maken gebruik van de standaard MySQL-bibliotheken. Afhankelijk van welke pagina er door een bezoeker wordt opgevraagd zal deze verschillende queries op de database afschieten, waarvan de complexiteit sterk uiteenloopt. Sommige opdrachten werken op een enkele tabel, andere op vier of meer. De WHERE-clausules zijn doorgaans echter vrij kort; in de meeste gevallen wordt er alleen gefilterd op een bepaalde key (zoals het nummer van een nieuwsbericht of product). In enkele gevallen wordt er ook nog gesorteerd of gepagineerd.

In de benchmark is doelbewust het reguliere onderhoudswerk weggelaten, enerzijds om de tijdsduur van de test te beperken en anderzijds om het aantal schrijfoperaties (UPDATE, DELETE en INSERT) te minimaliseren, zodat het opslagsysteem geen belangrijke invloed heeft op de prestaties. Het actieve deel van de database is enkele gigabytes groot, waardoor systemen met 4GB tot 8GB de volledige werkset in het geheugen kunnen houden, en er zelfs met 2GB nog weinig schijfactiviteit is. De nadruk komt hierdoor echt te liggen op de processors en het geheugen. Een ander verschil met de productieomgeving is dat er tijdens de test hele series van requests in één batch worden uitgevoerd, terwijl er normaal voor iedere pagina een nieuwe verbinding met de database gelegd zou worden. Door deze stap weg te snijden kunnen we de database zwaarder en beter gecontroleerd belasten.

De testdatabase is een back-up van de productiedatabase die ongewijzigd is ingeladen in MySQL 4.1.20 en 5.0.20a. Eveneens is hij geïmporteerd in een cvs-versie van PostgreSQL 8.2, die voor zover wij hebben kunnen ondervinden volledig stabiel is. Voor laatstgenoemde zijn enkele indices verplaatst om betere prestaties te krijgen en waren kleine wijzigingen van datatypes nodig. De testopstelling bestaat - naast de server die op dat moment onder vuur wordt genomen - uit drie machines. Twee webservers van Appro (dual Xeon 2,4GHz met 1GB geheugen) om de requests te genereren en een derde machine om de resultaten weg te schrijven. Alles is aan elkaar geknoopt met gigabit ethernet.

Een 'bezoeker' bestaat in onze test uit een serie van pageviews die worden afgehandeld door Apache 2.2 en PHP 4.4. Gemiddeld bestaat een serie requests uit ongeveer 115 stuks; de variatie zit hem in het feit dat er met een bepaalde kans een reactie wordt gegeven of prijs wordt ingevoerd. Om precies te zijn vraagt iedere 'bezoeker' de volgende pagina's op, waarbij tenzij anders vermeld willekeurig wordt gekozen:

Aantal	Omschrijving
34	Standaard frontpage
1	Dynamische frontpage (abonneefunctie)
18	Meest recente nieuwsberichten
7	Willekeurige nieuwsberichten
2	Reviews
13	Categorie-overzichten Pricewatch
14	Prijsoverzichten Pricewatch
2	Advertenties (V&A)
2	Productsurveys
6	Meuktracker-updates
14	XML-feeds
5% kans	Nieuwe prijs invoeren
2,5% kans	Reactie posten bij het meest recente bericht

Hoewel dit patroon niet helemaal natuurgetrouw is, denken we dat het wel een acceptabele benadering van de realiteit is, en in ieder geval één die zwaar en gevarieerd genoeg is om de database te laten zweten. De requests worden volledig willekeurig door elkaar gehusseld om een onvoorspelbaar patroon te krijgen en vervolgens afgevuurd. Er wordt zo min mogelijk gedaan met de antwoorden die ontvangen worden, om te voorkomen dat de webservers een bottleneck gaan vormen. Het uiteindelijke resultaat is het aantal pageviews dat in precies tien minuten tijd uitgevoerd wordt (gemeten door Apache-bench). Hoewel niet iedere pagina hetzelfde is, worden er zelfs tijdens de allertraagste runs nog ruim tienduizend opgevraagd, waardoor we ons statistisch gezien behoorlijk veilig kunnen voelen over de vergelijkbaarheid van de resultaten.

Tijdens een complete sessie worden runs uitgevoerd met een wisselend aantal gelijktijdige bezoekers, oplopend van één tot honderd stuks. Iedere webserver simuleert daarbij de helft van de bezoekers. Het startschot wordt steeds gegeven vanaf de databasemachine zelf, om zo precies de begin- en eindtijd te kunnen registeren. Het wordt overwogen om dit in de toekomst vanaf een apart controlesysteem te gaan doen, maar naar verwachting heeft dat nauwelijks invloed op de resultaten. Iedere sessie wordt afgetrapt door een (niet meetellende) opwarmronde met 25 gelijktijdige bezoekers om het geheugen en caches alvast te vullen. De eerste run wordt hierdoor niet onnodig benadeeld. Na iedere run wordt de database weer opgeschoond door de nieuw ingevoerde reacties en prijzen weer te verwijderen, en in het geval van PostgreSQL een 'vacuum'-commando te geven. Daarna krijgt de machine dertig seconden rust om zich voor te bereiden op de volgende aanval.

• Volgende pagina 10. Invloed HyperThreading

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.