Introductie
De markt voor (relatief) goedkope servers met twee sockets is de laatste paar jaar erg spannend geworden. Intel heeft lange tijd gedomineerd door met zijn Xeons alle andere architecturen zo goed als weg te jagen uit dit segment. Het bedrijf begon pas in 1995 serieus mee te doen met de Pentium Pro, maar het bleek al snel dat het enorme schaalvoordeel van x86 in het algemeen en Intel specifiek een beslissende factor zou gaan worden in de concurrentiestrijd. Intels Xeon profiteert direct van de enorme hoeveelheid capaciteit en onderzoek die sowieso al aanwezig is voor de Pentium. Andere bedrijven hebben niet zo'n geldkoe in huis, en moeten de gehele ontwikkeling van hun serverchips dus financieren met veel kleinere aantallen.
Naar mate de transistors kleiner worden stijgen de kosten voor de ontwikkeling en productie van processors sterk. Er winst mee maken is zeker niet onmogelijk, maar wie slechts kleine aantallen kan afzetten krijgt het steeds zwaarder. Toch zijn er nog drie van de top vijf serverbouwers die toekomst zien in het ontwikkelen van hun eigen processors, namelijk IBM, Sun en Fujitsu. Om dat te betalen verkopen ze servers als totaalpakket, inclusief software, consultancy, ondersteuning en alle hardware tot de behuizing en tapestreamers aan toe. Hierop wordt genoeg winst gemaakt om door de sluizen naar de processorafdeling, maar het gevolg is wel dat de verkoop van 'kale' hardware nauwelijks aantrekkelijk is. Intel daarentegen verkoopt juist alleen maar de losse onderdelen: processors, chipsets en hier en daar wat moederborden. Tientallen andere bedrijven gaan hier vervolgens mee aan de slag om servers te bouwen. Het gevolg daarvan is automatisch concurrentie en dus ook weer betere deals voor de klant.
De Xeon was dus een groot succes voor Intel, en het bedrijf was druk bezig met zijn plannen om dezelfde truc uit gaan halen in het high-end segment met de Itanium-familie. Dit deed het in samenwerking van HP, dat had ingezien dat de ontwikkeling van zijn eigen PA-RISC-chips in de toekomst niet meer rendabel zou zijn. Ondertussen leek men de bedreiging van AMD aan de onderkant echter te onderschatten. De eerste poging van AMD om het succes van Xeon na te bootsen (de Athlon MP) was an sich zeker niet slecht, maar het bedrijf miste het imago en de geloofwaardigheid die Intel had opgebouwd, en werd dus niet als een serieuze bedreiging gezien.
Met de introductie van de Opteron - bijna precies drie jaar geleden - veranderde alles. De K8 was met zijn geïntegreerde geheugencontroller, 64-bit extensies en een zuinig ontwerp niet zomaar een tweederangs alternatief voor Xeon meer, maar een volwaardige concurrent die een aantal overduidelijke voordelen te bieden had. Het conservatieve bedrijfsleven stelde zich zoals gebruikelijk afwachtend op, maar toen bleek dat er écht geen addertje onder het gras zat begon het in relatief snel tempo de Opteron te verwelkomen, waardoor de concurrentie was teruggekeerd. AMD had echter nog meer in petto: na 64-bit x86 in 2003 was in 2005 dualcore aan de beurt, en wederom werd Intel gedwongen om overhaast te reageren.
Nu beide bedrijven voor relatief lage prijzen single- en dualcore 64-bitters in de aanbieding hebben is er voor kopers van x86-servers een hoop keuze ontstaan. Tweakers.net is met zijn park van veertien servers één van de bedrijven die deze afweging regelmatig moet maken, en het leek ons een goed idee om met de evaluatie van nieuwe hardware voor onze databases twee vliegen in één klap te slaan: enerzijds door goed te testen welk platform voor ons het meest geschikt is, en anderzijds een interessant stuk content voor de lezers genereren. In dit artikel worden de volgende processor meegenomen:
- AMD Opteron 280 (dualcore 2,4GHz, 2x 1MB cache)
- AMD Opteron 254 (singlecore 2,8GHz, 1MB cache)
- Intel Xeon 'Paxville' (dualcore 2,8GHz, 2x 2MB cache)
- Intel Xeon 'Irwindale' (singlecore 3,8GHz, 2MB cache)
Naast de hardwarekant zullen we in dit artikel ook naar de software kijken: de site draait op dit moment op MySQL 4.x, maar dat zal natuurlijk niet altijd zo blijven. We besloten daarom ook MySQL 5.0 uit te proberen.
Testverantwoording
Om de webdatabase-prestaties van database-software en serverplatformen te testen, heeft Tweakers.net een simulatie ontwikkeld op basis van de eigen Tweakers.net-code en -database. De omgeving van Tweakers.net kenmerkt zich door zijn goed geoptimaliseerde queries, die over het algemeen een 'licht' karakter hebben en binnen enkele milliseconden verwerkt kunnen worden. De queries zijn vaak joins van twee of meerdere tabellen, waarvan de indices en datatypes goed zijn geoptimaliseerd. Veel queries laten zich bovendien goed versnellen door de query cache van MySQL, die resultaten van zoekopdrachten tijdelijk in het geheugen vasthoudt zolang de gegevens in de betrokken tabellen ongewijzigd blijven. Omdat er veel gelijktijdige queries door de Tweakers.net-database worden verwerkt, ontstaat er toch een hoge belasting van de database-server.
De queries in de simulatie zijn gebaseerd op degene die worden gebruikt om de belangrijkste pagina's op Tweakers.net op te bouwen. De pagina's voeren acties uit zoals het opvragen van een nieuwsbericht met de bijbehorende productkoppelingen en reacties, of het opvragen van een prijslijst in de Pricewatch. Om de simulatie zo realistisch mogelijk te maken is de verdeling van deze acties gebaseerd op de werkelijke verhoudingen tussen pageviews van de verschillende onderdelen van Tweakers.net (exclusief het forum). Deze verdeling is als volgt:
 |
 | Verdeling pageviews | |
|
| Frontpage |    35% | |
|
| Nieuws | 25% | |
|
| RSS-feeds | 14% | |
|
| Pricewatch | 13% | |
|
| Meuktracker | 6% | |
|
| Productsurvey | 2% | |
|
| Vraag & Aanbod | 2% | |
|
| Reviews | 2% | |
|
| Shopsurvey | 1% | |
|
De simulatie wordt uitgevoerd in een 2-tier-opstelling met een database-server aan de ene kant en één of meerdere webservers aan de andere kant. Op de webservers draait een load generator die queries op de database afvuurt.
Werking van de load generator
De load generator is feitelijk een combinatie van "ab" (Apache Bench) en een php-script. Het php-script stelt een lijst van honderd "acties" op (zoals het ophalen van de frontpage, een nieuwspagina, een Pricewatch-prijslijstpagina of een meukpost) volgens de eerder genoemde distributie. Om het min of meer willekeurige klikgedrag van enkele honderden gelijktijdig ingelogde tweakers te kunnen simuleren, wordt de lijst van acties "geshuffeld" voordat de acties daadwerkelijk worden uitgevoerd. De acties bestaan uit het verwerken van de queries zoals deze ook in werkelijkheid worden uitgevoerd bij het parsen van pagina's op Tweakers.net. Het "shuffelen" voorkomt dat er eerst 35 keer de frontpage wordt aangeroepen, vervolgens 25 nieuwspagina's, enzovoorts. De database-server zou dan op veel momenten enkel gelijksoortige queries uitvoeren, wat niet realistisch is.
Met behulp van Apache Bench kan de load generator met een bepaalde concurrency, dat wil zeggen een bepaald aantal tegelijk draaiende generators, aangeroepen worden. Zo kan de simulatie in lichtere en zwaardere scenario's getest worden. We hebben ervoor gekozen om de testruns uit te voeren met een concurrency van 1, 2, 3, 4, 5, 7, 10, 13, 15, 20, 25, 30, 35, 40, 45 en 50 gelijktijdige load generators. Normaliter nemen de prestaties (gemeten in queries per seconde) toe tot een bepaalde concurrency waarna de performance ongeveer gelijk blijft of juist weer afneemt. Onze ervaring is dat concurrencies hoger dan 50 nauwelijks verschillen laten zien en bovendien in de praktijk nauwelijks voorkomen.
De virtuele pagina's die door de acties in de load generator worden gesimuleerd, worden aangevraagd door middel van willekeurig berekende ID's binnen een realistisch bereik. Voor nieuwspagina's zijn dit de ID's tussen 0 en ongeveer 40.000 met de nadruk op het nieuws van de afgelopen dag. De random ID-generators zorgen ervoor dat een breed gedeelte van de database wordt aangesproken, zodat de dataset niet eenvoudig gecached kan worden. Voor alle virtuele pageviews worden net als in de werkelijkheid statistieken gelogd. Op willekeurige basis worden er met een bepaalde waarschijnlijkheid inserts in de reactie- en prijstabellen gedaan. Daarbij wordt ook de tabel met gegevens van de users, die veel wordt benaderd voor het ophalen van gebruikers- en sessiegegevens, geupdate. Dit alles zorgt ervoor dat er geen sprake is van een statische database. Wijzigingen in de database hebben invloed op de effectiviteit van de MySQL query cache, want een wijziging in een tabel zorgt ervoor dat alle gecachede resultaten die betrekking hebben op de tabel uit de cache verwijderd moeten worden.
Om de database de tijd te geven om zijn buffers te vullen, worden de testruns vooraf gegaan door een ramp-up run. Daarna volgen de testruns met een oplopende concurrency van 1 tot 50 simultane load generators. Tijdens het draaien van de benchmark worden er statistieken verzameld over het aantal queries per seconde en de processorbelasting van de database-server.
Testplatformen
De resultaten van de singlecore Xeon-processors werden verkregen op een Melrow QX312S-systeem met een Intel SE7520BD2-moederbord voorzien van 4GB DDR2-400-geheugen. Dit moederbord is gebaseerd op de Intel E7520-chipset en biedt helaas geen ondersteuning voor dualcore Xeon-processors. De dualcore Xeon werd daarom getest in een Dell PowerEdge 1850 met 4GB DDR2-geheugen. De Opteron-processors werden getest op een Iwill DK8ES nForce Pro 2200-moederbord met 4GB DDR400-geheugen.
Het singlecore Xeon-systeem was uitgerust met een Areca ARC-1130 SATA RAID-adapter met 256MB cache. Omdat deze full-height PCI-X-adapter niet ondergebracht kon worden in de low-profile slots van de Dell PowerEdge 1850 moest er voor dit systeem noodgedwongen uitgeweken worden naar een low-profile Areca ARC-1120 met 128MB cache. Vanwege de kleinere hoeveelheid cache presteert deze kaart in sommige situaties net iets minder dan de Areca ARC-1130. Het is niet aannemelijk dat dit heeft geresulteerd in significante verschillen in de prestaties van de database-server. De I/O belasting in de databasebenchmarks was namelijk gering met een gemiddelde CPU iowait van minder dan een procent en een lees transfer rate van zo'n 600KB/s. De Opteron-processors werden eveneens getest met de Areca ARC-1120.
De Areca-adapters waren aangesloten op acht Western Digital Raptor WD740GD-harde schijven. Daarvan waren twee stuks geconfigureerd in RAID 1 als bootarray en vijf stuks in RAID 5 als data-array. Het achtste exemplaar diende als hotspare. Als client werd een Linux-systeem met een Pentium 4 2,8GHz en 1GB RAM ingezet. Voor de multi-clienttests werd er een Windows-systeem met een P4 3,2GHz en 2,5GB geheugen als tweede client gebruikt.
Dell PowerEdge 1850 met acht Raptor-harde schijven Softwareconfiguratie| MySQL |
|---|
| Versies | 4.1.14 en 5.0.18 |
| key_buffer | 1024M |
| table_cache | 512 |
| sort_buffer_size | 2M |
| read_buffer_size | 2M |
| myisam_sort_buffer_size | 64M |
| thread_cache | 8 |
| query_cache_size | 32M |
| max_connections | 1000 |
| innodb_buffer_pool_size | 1200M |
| innodb_additional_mem_pool_size | 128M |
| innodb_file_io_threads | 8 |
| innodb_lock_wait_timeout | 50 |
| innodb_log_files_in_group | 3 |
| innodb_log_file_size | 800M |
| innodb_log_buffer_size | 35M |
MySQL 4.1 versus 5.0
Het eerste punt waar we naar hebben gekeken zijn de prestaties van MySQL. Tweakers.net heeft (bijna) zijn hele geschiedenis op deze opensourcedatabase. Helemaal terug in 1998 is het wel even mSQL (MiniSQL) geweest, maar dat kwam eigenlijk alleen maar omdat ons aller Femme een verkeerde checkbox had aangevinkt bij de toenmalige hostingprovider. In april van 1999 werd die fout rechtgezet en rolden we hoogstwaarschijnlijk ergens bij versie 3.22 van MySQL binnen. Sinds die tijd is er natuurlijk een hoop verbeterd aan het pakket en inmiddels draait Tweakers.net dan ook op versie 4.x. Omdat de database uiteindelijk zo'n beetje het hart van de site vormt zijn we nooit ál te vooruitstrevend geweest als het gaat om het installeren van grote nieuwe versies, maar we zouden ook geen tweakers zijn als we niet op zijn minst nieuwsgierig waren naar de dingen die de nieuwste telg van de MySQL-familie - versie 5.0 - voor ons zou kunnen betekenen. Het eerste dat we gaan bekijken is dan ook het verschil tussen MySQL 4.1 en 5.0:
Wanneer we naar de snelste machine kijken - de dual Opteron 280 - zien we dat het verschil in prestaties tussen versie 4.1 en 5.0 enorm is. De oudere release piekt bij 2610 queries per seconde met een concurrency van 10. Gemiddeld genomen over het bereik van één tot vijftig gelijktijdige gebruikers komen we uit op 2164 queries per seconde. Dit klinkt allemaal niet slecht - tot de resultaten van 5.0 binnenkwamen: met een piek van 3576 en een gemiddelde van 2989 queries per seconde is de nieuwe release bijna 40% sneller geworden voor het soort belasting dat een site als deze veroorzaakt. Het kan echter nog beter: verbaasd over het feit dat de Opteron-machine rond de 3500 queries per seconde bleef steken terwijl de processorbelasting onder de 60% bleef, hebben we geprobeerd om een tweede cliënt toe te voegen om eventuele bottlenecks aan die kant weg te nemen. Zoals in de grafiek te zien is kan het op die manier inderdaad nóg sneller, waarover later meer op de volgende pagina.
Voor Tweakers.net zelf over kan stappen op MySQL 5.0 moet er overigens nog wel meer worden getest. Onze ontwikkelaars besteden veel tijd aan het optimaliseren van queries en MySQL 5.0 gedraagt zich soms toch net even iets anders dan de 4.x-versies. Tevens lijken er hier en daar functionele wijzigingen te zijn: in het (beperkte) testscript kwamen we al één query tegen die niet zonder aanpassingen op versie 5.0 bleek te kunnen draaien. Voor we kunnen overstappen zal dus eerst alle code zorgvuldig nagekeken en getest moeten worden, maar als alles meezit kunnen we later dit jaar wel overstappen.
MySQL query cache en multi-client
MySQL 5.0 bleek verrassend goede resultaten op te leveren, maar de snelste machine die we beschikbaar hadden kwam niet aan zijn top met maar één cliënt die om pagina's aan het vragen was. De server kon kennelijk dus sneller antwoorden geven dan de cliënt ze kon verwerken. Om die reden hebben we een tweede testmachine geconfigureerd, zodat er iets meer druk op de servers gelegd kon worden. Het resultaat is hieronder zichtbaar gemaakt:
Het vermoeden dat er nog meer uit MySQL 5.0 te halen was met meerdere cliënts bleek te kloppen: de piek kwam voor de dual Opteron 280 (2,4GHz dualcore) op 4131 queries per seconde te liggen, tegenover 3576 queries met één cliënt. Ook de gemiddelde query rate steeg met 11%. De Opteron 254 (2,8GHz singlecore) weet ook nog een aardig voordeel uit de tweede cliënt te halen, wat doet vermoeden dat het sowieso beter is voor de prestaties van een database om meerdere cliënts in te zetten. Het leeuwendeel van de benchmarks in dit artikel is nog uitgevoerd met één cliënt, maar dat is dus een les die is geleerd. Zoals te zien is aan de belastingsgrafiek zitten de processors zelfs met twee cliënten nog steeds niet aan hun absolute maximum. Er zitten ergens anders dus nog bottlenecks in het systeem, maar het is niet duidelijk waar precies. De harde schijven leken in ieder geval niet echt een beperkende factor te zijn: de leessnelheid bedroeg gemiddeld slechts 600KB/s.
Query cache
Een van de redenen waarom MySQL zo goed werkt voor websites is het query cache. Het resultaat van een zoekopdracht wordt door deze functie tijdelijk vastgehouden, zodat er de volgende keer dat dezelfde opdracht gegeven wordt niet opnieuw gezocht hoeft te worden. Het cache staat standaard aan en is dus ook overal in de benchmarks gebruikt.
Een query cache is echter lang niet altijd evenveel nuttig: het komt natuurlijk het best tot zijn recht in een read-only omgeving, maar als er ongeveer even veel geschreven als gelezen wordt heeft het nauwelijks effect. Tweakers.net valt net als de meeste andere websites in een categorie applicaties die in databasetermen 'read-mostly' genoemd wordt: het grijze gebied tussen read-only en read-write in. De database spendeert het grootste deel van zijn tijd aan het lezen van data, maar moet af en toe ook dingen bijwerken (afhankelijk van welke tabel tientallen tot duizenden keren per dag). In verhouding tot ruim een miljoen pageviews die stuk voor stuk meerdere lees-queries nodig hebben is het aantal schrijfacties dus klein, maar toch kan het cache hierdoor niet optimaal werken. Iedere keer als er is iets veranderd moeten de queries namelijk wél opnieuw uitgevoerd worden.
Dat de feature toch nog flinke winsten oplevert blijkt uit onderstaande test van een dual Xeon 3,8GHz waarbij het cache als experiment is uitgeschakeld: bij een concurrency van 1 tot en met 3 halveert het aantal queries per seconde zowat, een vrij dramatische val ten opzichte van dezelfde configuratie met cache. Omdat we query cache verder overal aan hebben staan hebben we niet verder doorgetest tot en met een concurrency van 50, maar het is in ieder geval iets om in het achterhoofd te houden.
Invloed HyperThreading
Intels Xeon-processors hebben sinds een paar jaar HyperThreading aan boord: een feature die ervoor zorgt dat één core aan twee threads tegelijk kan werken. Vanaf de kant van de software ziet een core met HyperThreading ingeschakeld er (bijna) precies hetzelfde uit als twee losse cores, en in gunstige gevallen kan de feature dan ook redelijke prestatiewinsten opleveren, oplopend tot enkele tientallen procenten. Het werkt natuurlijk lang niet zo goed als twee echte cores, maar ieder beetje is natuurlijk mooi meegenomen. Het gevaar is echter dat het niet altijd winst oplevert, maar in sommige gevallen de prestaties ook negatief kan beïnvloeden. Oorzaken hiervoor moeten onder andere gezocht worden in het cache van de processor: wanneer twee threads met elkaar 'vechten' om ruimte in het cache lijden ze daar allebei onder. Uit onze test bleek dat de normale single-core Xeons geen problemen hadden met HyperThreading: de virtuele extra cores leveren een prestatievoordeel op van gemiddeld 8%.
De machine met dualcore Xeons (2,8GHz Paxvilles) vertoonde echter vreemde kuren: acht virtuele cores was kennelijk iets te veel van het goede en bij een concurrency van 7 of hoger stortte de snelheid volledig in. Zonder HyperThreading bleek dezelfde machine het wel goed vol te kunnen houden, dus de oorzaak moest in die hoek gezocht worden. We hebben deze bevindingen voorgelegd aan Dell en Intel, die beide hebben gezocht naar een verklaring. Uiteindelijk werd de schuld aan de software gegeven: de manier waarop MySQL 4.1 omgaat met meerdere threads zou ver van optimaal zijn, waardoor het pakket onder zware belasting in de problemen komt.
In MySQL 5.0 hebben de ontwikkelaars de schaalbaarheid verbeterd: het is duidelijk te zien dat het voordeel van HyperThreading voor de singlecore Xeon in stand is gehouden, maar ook dat de dualcore Xeon het met de nieuwe versie van de software een stuk beter volhoudt. Bij een concurrency van 40 of hoger is het echter wederom foute boel: met HyperThreading aan zakken de prestaties tot ver onder het niveau van dezelfde configuratie zónder virtuele cores.
Processors: Intel, AMD, single- en dualcore
Nu we de softwarekant hebben besproken is het de hoogste tijd om het over de hardware te gaan hebben. Oplettende lezers is het waarschijnlijk al opgevallen dat de dualcore Opteron 280 de beste prestaties neerzet. Het feit dat de processor 400MHz lager geklokt is dan de singlecore Opteron 254 wordt in onze test ruimschoots gecompenseerd door de verdubbeling van het aantal cores. Gemiddeld genomen is het dualcoresysteem ruim 10 procent sneller met één cliënt en bijna 14 procent sneller met meerdere cliënten. Wanneer we alleen naar de zwaardere belastingen (concurrency >5) kijken doet de dualcore AMD het zelfs nog beter: 13 procent verbetering met één client en 19 procent met meerdere clients. De dualcore Opteron 280 staat op dit moment voor 851 dollar op de prijslijst, niet veel duurder dan de singlecore Opteron 254 van 690 dollar. De singlecoreversie levert in deze test nét iets betere prestaties per dollar, maar op een volledige databaseserver is het prijsverschil zo klein dat het waarschijnlijk verstandiger is om die extra kosten even te slikken en later te profiteren van betere groeimogelijkheden.
Aan de kant van Intel is het verhaal echter anders: de verschillen tussen de singlecore Xeon 3,8GHz (Irwindale) en de dualcore Xeon 2,8GHz (Paxville) zijn slechts marginaal. Sterker nog: de singlecore doet het met HyperThreading ingeschakeld in veel gevallen beter dan dezelfde configuratie met dualcoreprocessors. HyperThreading inschakelen op de Paxville-machine is een optie om het verschil kleiner te maken maar leidt er onder zware belasting toe dat de prestaties juist inzakken. Gegeven het prijsverschil (1043 dollar voor een 2,8GHz dualcore en 851 dollar voor een 3,8GHz singlecore) zouden we op dit moment niemand aanraden om een dualcore Xeon voor dit soort databasewerk aan te schaffen.
Gezien de resultaten met MySQL 5.0 zouden we eigenlijk helemaal geen Intel-processor kunnen adviseren, aangezien de Opteron duidelijk meer waar voor zijn geld biedt in deze toepassing. Natuurlijk spelen er bij het kopen van een server veel meer factoren mee dan alleen de processor, maar als we konden kiezen tussen identieke configuraties met dezelfde kwaliteit, ondersteuning en prijs, dan zou AMD een streepje voor krijgen.
Conclusie
Hoewel dit artikel zeker niet bedoeld is om het laatste en volledige antwoord te geven op de vraag wat nou de beste databasesoftware en -hardware is, willen we met deze test wel een fundering leggen voor een serie van toekomstige artikelen die over hetzelfde onderwerp gaan. Er staat een aantal interessante nieuwe ontwikkelingen te gebeuren dit jaar, waaronder de introductie van Intels Xeon 'Dempsey', de Socket F Opteron van AMD met DDR2-geheugen en natuurlijk ook Intels Woodcrest.
Hoewel we van AMD dit jaar geen grote verbeteringen meer verwachten, ligt de lat voor Intel hoger - het bedrijf heeft dan ook aardig wat achterstand om in te halen. De roadmaps geven aan dat de situatie zoals die er nu ligt aan het einde van het jaar drastisch anders zal zijn: een van de redenen waarom de dualcore Xeon in deze test niet harder wilde gaan dan zijn singlecore broertje is zijn beperkte bandbreedte: met vier cores op één 6,4GB/s bus werken is duidelijk geen pretje. Binnenkort verschijnt er echter een nieuwe chipset met een dubbele FSB en vier kanalen FB-DIMM, waardoor de beschikbare bandbreedte meer dan verdubbelt naar 17GB/s. De 65nm Xeon-processors die daarbij horen laten zich bovendien een heel stuk hoger klokken: we hebben hier een 2,8GHz Paxville onder de loep genomen, maar Dempsey zal beschikbaar zijn tot en met 3,73GHz.
Binnen een half jaar na Dempsey verschijnt Woodcrest, die de bandbreedte nog eens extra opvoert naar 21,3GB/s. Bovendien is deze chip gebaseerd op de volledig nieuwe architectuur die ook in Conroe en Merom terug te vinden zal zijn. Eén van de belangrijkste dingen die hiermee wordt aangepakt is het stroomverbruik van de Xeons: Dempsey krijgt nog een TDP van 150 watt mee, wat vergeleken met de 95 watt Opterons erg veel is. Woodcrest zal het verbruik naar verluidt bijna halveren (naar 80 watt), terwijl het tegelijkertijd betere prestaties belooft. Dat Intel ons aan het einde van het jaar een veel beter product zal kunnen bieden dat we nu getest hebben lijkt zo ongeveer vast te staan, maar de grote vraag is natuurlijk hoeveel beter, en of het ook genoeg is om de Opteron van de troon te stoten. Merom en Conroe mogen in vroege tests dan wel indrukwekkende resultaten neerzetten tegenover de Athlon 64 X2, maar een serverconfiguratie waarin twee processors moeten samenwerken is toch andere koek dan de een chip die op zichzelf goed werkt.
Omdat we hier feitelijk maar één soort toepassing hebben getest kunnen we in dit artikel geen definitieve conclusies trekken over welke processor of databasepakket nou 'het beste' is, maar we zijn duidelijk onder de indruk van de prestaties van de dualcore Opteron, en ook MySQL 5.0 was voor ons een positieve verrassing. Intels Xeons zouden het in andere taken misschien beter kunnen doen, maar in ons geval stellen ze teleur: vooral de dualcore-versie lijkt zijn geld niet waard te zijn. Hoewel dat later in het jaar weer helemaal kan veranderen, moeten we op dit moment concluderen dat we nog steeds liever voor AMD gaan.
Dankwoord
Tweakers.net wil Robin Kuepers (Dell), Alex Vellinga (Melrow), Matty Bakkeren (Intel) en Winnie Silvertand (Whizpr / AMD) bedanken voor hun medewerking aan dit artikel. Verder dank aan onze eigen Femme, Kees, ACM en moto-moi voor het opzetten en uitvoeren van de tests en hun waardevolle inzichten voor het schrijven van dit artikel.
:strip_icc():strip_exif()/u/140051/BSOD.jpg?f=community){kind=small}
:strip_exif()/u/818/we33ee45.gif?f=community){kind=small}
./u/1830/acm.png?f=community){kind=small}
/u/1/femme.png?f=community){kind=small}
/u/36978/icon.JPG?f=community){kind=icon}
/u/8/oog3.png?f=community){kind=small}
:strip_icc():strip_exif()/u/3550/S2462.jpg?f=community){kind=small}
/u/18715/1.JPG?f=community){kind=small}
/u/13471/karnemelk.png?f=community){kind=small}
/u/166246/unixCopy.JPG?f=community){kind=small}