Journalistiek

Onpartijdig, onafhankelijk nieuws, uitsluitend in dienst van het branchebelang.

Grote verschillen in performance van virtuele servers

  • Door
  • Arnout Veenman
  • geplaatst op
  • 10 april 2014 08:01 uur

In de performance van virtuele servers zitten grote verschillen. Deze week plaatste Argeweb-directeur Gerben van Leeuwen een blog op zijn website waarin hij een benchmark laat zien van virtuele servers van verschillende hosters. Hoewel de benchmark interessant is, hebben de uitkomsten toch de verdenking dat er sprake is van WC-eend die WC-eend adviseert.

Daarom heb ik zelf bij Argeweb, Strato en TransIP de VPS besteld die in alle gevallen een (reguliere) prijs van 10 euro per maand heeft. Op al deze servers heb ik Debian of Ubuntu laten installeren. Vervolgens heb ik zelf Phoronix geïnstalleerd op elk van de servers en verschillende tests gedraaid. De uitkomsten van de benchmarks die ik heb gedraaid kwamen in grote lijnen overeen met die van Van Leeuwen.

De performance van de virtuele servers van Argeweb en TransIP ontlopen elkaar niet zoveel. Al moet gezegd worden dat de server van Argeweb het in alle gevallen nét 10 tot 20% betere performance heeft dan die van TransIP. Dat is geen wereldschokkend verschil, maar toch significant.

Trager

Mijn aandacht wordt echter vooral getrokken door de performance van de server van Strato. Op de meeste punten is het verschil tussen de server van Strato en de andere gemiddeld zo’n 300% verschil. Het maakt niet uit waar je naar kijkt, processor, geheugen of disk. Alles is véél trager dan bij de twee concurrenten. Alleen op leessnelheid van disk laat Strato een acceptabele performance zien.

Het absolute dieptepunt is te vinden wanneer het gaat om met OpenSSL signeren van sleutels, de server van Strato komt niet verder dan 9 versleutelingen per seconde, terwijl de servers van Argeweb en TransIP beide ruim boven de 80 uitkomen.

Wie 10 euro per maand te besteden heeft aan een VPS doet er – wanneer performance van belang is – verstandig aan om niet met Strato in zee te gaan. Al bestaat een virtuele server als dienst niet alleen uit de rauwe performance, maar ook de mogelijkheden om de server te kunnen beheren. Binnenkort ga ik daar onderzoek naar doen bij aanbieders van virtuele servers.

Vraag van de dag

Denkt u dat er veel verschil is in de performance van virtuele servers van verschillende hosters?
Bekijk resultaten

Tom, 10 april 2014 8:40 am

Neem tilaa ook maar eens mee in het onderzoek.
Kwam bij mij als snelste uit de bus, WHM -cPanel met een standaard webshop getest.

Sander, 10 april 2014 9:12 am

Ik heb ook de test gelezen op de blog van Gerwen van Leeuwen conclusie is wel dat het hier wel gaat om eenzijdige belichting, want hoe zijn de geteste VPS's ingericht?

Zijn de tests van Argeweb (maar ook van Ispam) op een lege omgeving/node gedaan zonder andere VPS'en erop geplaatst?

Niet echt objectief om dan te schreeuwen dat je de snelste VPS zou leveren....

Dick Tump, 10 april 2014 10:09 am

Ik denk dat je niet eenvoudig de snelheden tussen ISP's kunt vergelijken door maar 1 VPS te bestellen. Als je toevallig op een wat rustigere fysieke server terecht komt, of bijv. de storage (SAN of wat dan ook) nog wat rustiger is op dat cluster, zul je relatief veel performance halen. Terwijl het misschien een maandje later een stuk langzamer is.

Uiteindelijk valt of staat de snelheid bij hoe de ISP de resources verdeelt. En uiteindelijk ook wat de prijzen/marges zijn op het product, want als je het goedkoop aanbiedt moeten er nou eenmaal domweg meer virtuele servers draaien binnen dezelfde hardware.

Dat maakt een goedkope VPS niet per definitie slecht natuurlijk, want als je het bijv. voor back-ups gebruikt heb je niet veel performance nodig.

Thomas Lobker, 10 april 2014 11:09 am

Performance behalen is redelijk eenvoudig, maar het heeft een keerzijde. Kijk bijvoorbeeld naar je opslag. Je wilt dat je opslag op meer dan een enkele server beschikbaar is, want als je hypervisor uitvalt dan moet de virtuele server weer snel opgestart worden (of verder draaien) op een andere hypervisor. Dus replicatie van je opslag. Dit heeft op zich nog geen impact op je performance, maar als je gehecht bent aan je data, dan wil je zeker weten dat iedere schrijfactie klaar is voordat je een nieuwe schrijfactie begint. Dit is de grootste penalty voor de performance van je opslag.

Wil je geen risico op corruptie van je data en databases, dan wil je synchrone replicatie waarbij alle caching wordt gedaan in een RAID controller met BBU. Iets inleveren op performance, maar veel hogere zekerheid. Praat hierover met je provider en kies niet alleen op basis van performance.

Tom, 10 april 2014 12:55 pm

Ik ben het eens met Thomas, aangezien je vaak met mooie caching geen directe syncs heb. Mocht er een hypervisor wegvallen en staat net jou belangrijke data van een mysql transactie nog in het cache geheugen dan kan het gebeuren dat na het rebooten op een andere hypervisor jou data corrupt is.

Met iets minder snelheid maar wel bijv het direct wegschrijven van de data heb je veel meer zekerheid, minder problemen en uiteindelijk een hogere uptime en een beter bereikbare server.

Robert van der Meulen, 11 april 2014 8:34 am

Hallo Arnout,

Laat het gerust even weten als je er een paar bij ons nodig hebt om te testen!

Robert van der Meulen

Feedback!
Fill out my online form.
Laatste reacties

Bedankt voor het succes van ISPam.nl
Koen Stegeman, Editor-in-Chief & founder Hostingjournalist.com: Jammer Arnout, maar je hebt een mooie bijdrage aan de hosting industrie geleverd, en dat jaren lang....

Bedankt voor het succes van ISPam.nl
Dillard Blom: Jammer dat een 'instituut' verdwijnt, en daarmee een bron van informatie over actuele zaken (en opin...

Bedankt voor het succes van ISPam.nl
L.: Uit automatisme kijk ik toch nog steeds elke dag naar ispam.nl, toch de hoop dat er nog een berichtj...

Bedankt voor het succes van ISPam.nl
Toni Donkers: Arnout bedankt! ik ga het missen dat is een feit!

Bedankt voor het succes van ISPam.nl
Marcel Stegeman: Ik zie het nu pas. Inderdaad jammer maar ik kijk nu al uit naar het volgende project.