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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 46, views: 88.256 •

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.

Dual core Xeon DP Dempsey

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.


Reacties (46)

En je eerste fipo! :7

Ik ben bang dat AMD niet zo gek veel in het vat heeft komend jaar. Dit is tenminste de tendens in de berichtgeving op diverse sites.
Nee conclussie HT met meerdere cores zuigt.
Op single core werkt het wel (Heb ik al eens eerder vergeleken en op 2 test (van de 15) na kwam met Ht er beter uit)

Alleen net iets lagere geheugenlees en schrijfsnelheid (0,1% of zo)

Maar met meerdere cores is het dus BS om Ht aan te zetten gewoon niet doen dus.
Mooie test!! hier hou ik wel van!!

In deze test worden de pagina dus 'niet echt' gegenereerd?!
Ik zat namelijk vandaag te knoeien om de resultaten van een querie netjes op het scherm te drukken maar de opbouw van de pagina heeft ook nog eens veel impact op de totale load
De opmaak van je site zou niet uit mogen maken. Wat jij denk ik bedoeld is dat er bij sommige opmaken meer html en dus webserver load bij komt kijken.

De database server maakt het niet veel uit hoe en wanneer hij queries ontvangt!
De pagina's werden wel echt gegenereerd maar dat gebeurde op een apart systeem. De databasemachines hielden zich dus puur en alleen bezig met het verwerken van de queries, niet met de verdere opbouw van de pagina.
Ze worden niet 'echt' gegenereerd. Als je ze zou zien zou je een hoop getallen zien, niet alsof je naar de frontpage zou kijken.

Het genereren van de pagaina, de opbouw e.d. kost inderdaad veel rekenkracht ook, en de webservers hebben het daar ook wel zwaar mee, maar dat is niet aan de database gerelateerde load, dus die konden we voor deze test weglaten. Als we webserversoftware zouden testen dan was het inderdaad een kwestie van de pagina compleet genereren en 'laten zien', maar nu het puur om de queries gaat is dat niet gebeurd.
vraag me hier dus wel heel erg af, wat de geintergreerde geheugen controler voor de nieuwe Amd64 x2 chipjes zal opleveren, zou in ieder gevaal zeer benieuwd zijn naar een zelfde soort onderzoek tegen die tijd.

eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.

wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
vraag me hier dus wel heel erg af, wat de geintergreerde geheugen controler voor de nieuwe Amd64 x2 chipjes zal opleveren, zou in ieder gevaal zeer benieuwd zijn naar een zelfde soort onderzoek tegen die tijd.
Het is zeker de bedoeling om dit vaker te gaan doen, dus wie weet :).
eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
Het probleem daarbij is dat de code van Tweakers.net zwaar geoptimaliseerd is voor MySQL en zich dus niet zo makkelijk laat overzetten naar een andere database. Zelfs als het in een keer zou werken zou je weer hele andere trucs moeten gaan toepassen om de optimale prestaties te krijgen, en dat kost veel tijd. Nu dat gezegd is kan ik verklappen dat we hebben geprobeerd om Tweakers.net op PostgreSQL te testen, maar dat is om verschillende redenen fout gelopen en het resultaat daarvan hebben we dus achterwege gelaten. Wellicht komt dat echter nog terug in een toekomstig artikel.
wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking) is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Heel de frontpage van de site draait op één database. Query cache staat automatisch aan voor alle tabellen, maar degene waarin veel geschreven wordt profiteren er minder van.
Het probleem daarbij is dat de code van Tweakers.net zwaar geoptimaliseerd is voor MySQL en zich dus niet zo makkelijk laat overzetten naar een andere database.
Puur uit interesse, wat valt er aan MySQL zo specifiek zwaar te optimaliseren waardoor het dan ook nog eens voor SQL code zorgt die niet meer portabel is naar andere engines ?

Op die manier vervalt heel het voordeel van SQL als 'structured query language' IMHO...
Pas sinds 4.1 en nog meer 5.0 doet MySQL moeite om ook daadwerkelijk compatible met SQL te zijn. Daarvoor was het vrij gebruikelijk dat er zaken in zaten die niet in andere databases werken. Er zijn diverse voorbeelden, maar het lijkt me voor deze discussie niet heel handig ze allemaal te noemen.
Om je toch niet met een kluitje in het riet te sturen:
MySQL kan pas subqueries sinds 4.1, dus daarvoor moest je truckjes uithalen om hetzelfde effect te bereiken door de queries niet erg optimaal te herschrijven of door ze op te splitsen en de resultaten van "sub"queries eerst apart te verwerken in je applicatie.
MySQL gebruikte tot voor 4.1 de functie "concat" om iets vergelijkbaars als || te doen, maar niet het helemaal hetzelfde. Evenzo voor diverse andere functies, ze zijn/waren vaak net anders genoemd en/of werkten net even anders dan de standaardfunctionaliteit.
MySQL laat het toe dat je een langere select list hebt dan je group by list en dan heb ik het niet over de aggregations in de SL.

En zo zijn er nog heel wat meer. Veel van de queries konden overigens met redelijk beperkte aanpassingen toch werken in PostgreSQL. Maar aangezien PostgreSQL relatief tov MySQL slecht presteert met hele lichte queries was het nuttig en bijna noodzakelijk om met name die opsplitsingen van queries terug te draaien.
Ondanks die "terugdraaiingen" zijn er nog zat andere stukken code die kunnen profiteren van het opnieuw doordenken van de structuur en/of de queries.
Ik ben benieuwd hoe de getallen zijn als je meer gaat schrijven in de DB
eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
Op zich heb je gelijk dat dat interessant is. Zoals Wouter al zegt, we hebben wel PostgreSQL in eerste instantie ook gebenchmarked. In de optimalisatie van de queries ging echter behoorlijk wat tijd zitten en juist daardoor gingen we enerzijds meer fouten introduceren en werden anderzijds de resultaten minder goed vergelijkbaar. Een redelijk belangrijke conclusie die ik je er nog wel over kan geven is dat ondanks de niet vergelijkbare resultaten (met mysql), gaven de cijfers ook bij PostgreSQL hetzelfde beeld als MySQL doet. Zowel voor HT als de dual-coreoplossingen
wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Nee, dat gaat niet zo maar. Veel van de queries combineren diverse tabellen weer met elkaar (bijvoorbeeld de username bij de reacties). Sterker nog, in de praktijk zijn er maar een paar waar relatief veel in geschreven wordt en een vrij groot aantal waar relatief weinig in geschreven wordt. Maar zelfs voor de reactietabel moet je niet vergeten dat er hooguit een paar nieuwe reacties per minuut bijkomen, terwijl er in dezelfde tijd misschien wel 10x zoveel views op reacties zijn geweest.
Het is daarom ook "minder effectief" niet gelijk totaal zinloos bij de meeste van onze queries :)
eigenlijk dan nog het liefste met ook andere db-oplossingen dan mysql postgreSQL Oracle en MSsql zouden naar mijn mening een zeer waardevolle toevoeging kunne bieden.
Dit artikel heeft een beperkte strekking, namelijk die van een webdatabase-server. MySQL wordt vanwege de lage kosten, afdoende mogelijkheden en goede prestaties veel gebruikt voor webdatabases. Oracle wordt gebruikt voor hele andere toepassingen waarvoor wij geen simulatie voorhanden hebben die is gebaseerd op omgeving uit de echte wereld.

MS SQL zou wel een mooie toevoeging zijn omdat het veel wordt gebruikt voor websites die op Windows-systemen draaien.
wat mij trouwens wel opvalt is die term mostly read... (of iets van die strekking)
is het dan niet zo dat de nodige tabelen waarin veelvuldig data wordt geinjecteerd (zoals reacties, en modpunten), op niet-gecashte database servers draaiden... (ik had dat namelijk eigenlijk wel verwacht).
Over het algemeen geldt dat alle tabellen in de Tweakers.net-database een hoge verhouding reads hebben ten opzichte van writes, behalve de tabellen waar vrijwel uitsluitend in geschreven wordt (met name statistieken). Dit zal voor veel webdatabases het geval zijn. Ik denk dat wij zelfs aan de hoge kant wat betreft writes zitten ivm de veelvuldig voorkomende mutaties in de Pricewatch, de reactietabellen en user/sessietabellen door het toevoegen of wijzigen van prijzen en user moderaties. Desondanks worden er toch veel meer views gedaan dan mutaties.

Op de statstabellen heeft de query cache weinig overhead omdat er nauwelijks SELECT's op die tabellen gedaan worden en er dus ook weinig in de cache getrashed kan worden.
Waarom niet de 1120 op alle hardwareplatformen getest?
Ik denk (maar misschien kan iemand anders die zich daadwerkelijk met het testen bezig heeft gehouden me corrigeren ;)) dat de singlecore Xeon simpelweg als eerste is getest en dat het niet de moeite waard was om die later nog een keer opnieuw te doen (gezien de lage I/O-activiteit).
In eerste instantie wilden we het juist allemaal met die 1130 doen, maar die bleek bij de 2e server (die 1U Dell op de foto) al niet te passen, waardoor we uiteindelijk maar de 1120 zijn blijven gebruiken.
De dual 3.8 Ghz hing tegen die tijd echter al in ons rack en konden we niet meer opnieuw testen. Voor de performance maakte het verder geloof ik niks uit en anders een heel klein beetje. De oplettende bezoeker zal misschien herkend hebben dat de 3.8Ghz configuratie precies overeenkomt met die van de forum-searchserver Aphrodite en de 3.4Ghz met de fileserver Atlas ;)
Als jullie dit nog eens doen is het misschien een idee om de kleuren van de verschillende data-sets wat contrasterender te maken. Vooral op de zesde pagina vond ik het af en toe wat slecht uit elkaar te houden.
Ik heb gekozen voor gelijke kleuren met verschillen lijnstijlen voor dezelfde cpu's zodat snel is te zien hoe de resultaten van dezelfde cpu (met/zonder HyperThreading, single- of multi-client) zich tot elkaar verhouden).
Wat op zich opvalt is dat de idletime niet echt zwaar onderuit gaat. dat wijst op een andere bottlenek. Kan het daardoor niet zo zijn dat het gewoon aan het moederbord c.q. chipset i.p.v. de processoren ?
Er blijft inderdaad maar weinig over als de Cpu's idle zijn en de i/o lang niet vol zit. Maar of het dat dan ook geweest is?

Ik hou het op een combinatie van factoren, want ook bij de relatief snelle bus (tov aantal cpu's en snelheid ervan) bij de Dual Opteron 254 zaten de cpu's niet vol.
Kun je na het hele verhaal over de raidcontrollers constateren hd performance niet belangrijk is voor een databaseserver? Zou een gewone SATA schijf ook voldoen?
Disk performance is zeker niet onbelangrijk voor database-servers. Dit artikel is gericht op de prestaties van serverplatformen, dwz de combinatie processor/chipset/geheugen. Om te voorkomen dat de storage een grote invloed heeft op de prestaties is de dataset kleiner gehouden dan het geheugen van de servers. De data kan daardoor goed gecached worden. In de echte wereld zal er vaak gewerkt worden met datasets die (soms velen malen) groter zijn dan het RAM in de server. Als er ook nog eens een groot gedeelte van de dataset frequent wordt gebruikt ontstaat er vanzelf meer disk I/O.
dus als de dataset kleiner blijft dan je werkgeheugen zit je goed met een wat mindere disk(array).
is misschien goed om te weten voor degenen met een relatief kleine dataset dat zou de keuze voor een grote array of meer ram makkelijker kunnen maken(als er een compromis gemaakt moet worden, en we blijven natuurlijk nederlanders he).
Dat is een te simpele conclusie. Je zit dan altijd nog met writes die altijd naar disk doorgestuurd moeten worden, etc.

In deze test wordt daarnaast minder in de database geschreven dan in onze productieomgeving. Dat zorgt er dus voor dat de data in de caches van de database en de diskcache van het OS minder snel verouderen en er dus ook om die reden minder diskactiviteit nodig is.

Maar ik denk dat je doorgaans met meer ram meer bereikt dan een versnelde I/O. Met name omdat ram tot op zekere hoogte relatief goedkoop is, terwijl I/O al vrij snel behoorlijk prijzig kan worden.
Desalniettemin moet je natuurlijk ook weer uitkijken met een onderbemeten I/O-systeem, want dan kan het zijn dat het wachten op writes zo lang duurt dat je alsnog daar problemen door ondervindt. :)
In veel gevallen kun je beter je geld in meer geheugen en snellere disks steken, dan snellere cpu's overigens. Tenzij je een kleine actieve dataset hebt (die dus volledig in het geheugen past) en je daar veel rekenintensieve queries op los wilt laten, uiteraard.
Er stond 600 kb/s dus het ligt dus duidelijk niet aan de harde schijven dan zou zelfs een eeuwenoude harddisk uit 1995 genoeg zijn die haalde ook al makelijk 4MB/s.

Maar een buffer is natuurlijk wel handig om wat sneller te zijn. En met een Raidset heb je meerdere schijfbuffers die veel sneller werken als het echte schijfoppervlak.

edit: - En wat hierboven al staat er zit ook nog RAM geheugen voor dus is de RAID-set niet echt nodig.
Er stond 600 kb/s dus het ligt dus duidelijk niet aan de harde schijven dan zou zelfs een eeuwenoude harddisk uit 1995 genoeg zijn die haalde ook al makelijk 4MB/s.
Transfer rate is (zeker in dit geval) niet de juiste manier om te meten hoe druk een HDD het heeft. Helaas geven alle/veel niet aan welk gedeelte van de tijd een HDD bezig of idle is.
Mooie test zeg!
Ik vind het deel van mySql 4.x en 5.0 erg interessant.

Hebben jullie bij de test gebruik gemaakt van een PHP script?
Daar heb je op dit moment namelijk ook het verschil van de mysql en mysqli library.

De mysqli staat voor mysql Improved en zou veiligheid en snelheids verbeteringen met zich mee moeten brengen.
Hebben jullie hier al wat mee getest toevallig? Voor- en/of na-delen van gevonden?
Mooie test, om zowel hardware als software zo te betrekken. Ik ben in iedergeval weer een stukje advies rijker voor toekomstige aankopen.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBGrand Theft Auto V

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013