Snelheid van Apache/PHP/SQL [hoe is Wikipedia.nl zo snel?]

[hyperdry]

Beste medetweakers,

Van hosting en webdesign had ik tot vijf dagen terug geen kaas gegeten. Afgelopen dagen heb ik een persoonlijke wiki opgezet via installatie van Mediawiki 1.31.1: eerst lokaal in XAMPP, daarna gemigreerd naar een US host (shared hosting) en vervolgens gemigreerd naar een NL host (shared hosting) - ik wil er van elke locatie/device bij kunnen. Mediawiki werkt als een 'samenstel' van PHP files en gebruikt Apache/PHP/SQL. De wiki werkt super en ik kan een persoonlijke wiki (achter 2FA) aanraden, maar ik ben niet tevreden met de snelheid.

De migratie naar de NL host brengt page load time een paar 100ms terug, maar het huidige 1a2 sec wachten op pagina's en opslaan van edits vind ik nog veel - Wikipedia.nl laadt pagina's veel sneller (ook wanneer je daar op pagina's 'Edit' en 'Save changes' gebruikt). Vervolgens probeerde ik te bepalen hoe dit kan: ik nam wat bronnen door omtrent performance optimalisatie. Note: een kleine 1KB plain html file testpagina, zonder PHP of verwijzingen, laadt wel in 150ms.

Edit 14-11-2018 13:30: Inmiddels heeft het topic een andere wending gekregen. Ik ben met name op zoek naar verkleining van de laadtijd van het opslaan van Editpagina's. Met dank aan medetweaker @CodeCaster zie ik dat ik daarvoor met name dien te letten op IOPS, zelf zie ik dat ik daarbij rekening moet houden met latency en de samenstelling v/d volledige stack (denk aan LAN-kaart in je VPS, welke software op je VPS). Zie mijn post hieronder van 14 november 2018 12:53 voor een klein onderzoek naar snelheid van Mediawiki's en het wordt ontzettend gewaardeerd als je mijn vragen daar omtrent snelheid wilt beantwoorden.

---

Initiële vragen omtrent caching, ben er inmiddels achter dat dit voor mij ook relevant is maar minder - hier ga ik ook aan werken maar sturen op meer IOPS/minder latency krijgt nu prioriteit:

Ik heb geen achtergrond in IT, dit is wat technischer dus misschien doe ik hier verkeerde aannames. Ik zie dat het grootste verschil waarschijnlijk zit in caching: caching via Varnish Cache zou ervoor moeten zorgen dat eerder bezochte pagina's (ongeacht door welke gebruiker) gekopieerd worden en daarna opgeslagen klaar staan om geserveerd te worden als plain HTML, ipv dat er voor iedere pagina weer opnieuw een PHP verzoek gedaan en uitgevoerd wordt (correct me if I'm wrong!).

Correct me if I'm wrong ook in dit stuk: Nu zag ik dat je Varnish Cache dient te installeren en runnen op de machine waar je wiki op staat. Dit kan dus niet met shared hosting. Vandaar heb ik gisteren een VPS aangeschaft (Ubuntu 18.04), en vervolgens adhv wat guides deze beveiligd en Apache/PHP/SQL geïnstalleerd, en Mediawiki gedownload (leuk en leerzaam zo via SSH!). Momenteel werkt Mediawiki nog niet, maar dat gaat uiteindelijk wel goedkomen.

Mijn vraag voor de tussentijd: klopt het dat Wikipedia.nl waarschijnlijk zoveel sneller is dan mijn persoonlijke wiki door caching via Varnish Cache (we gebruiken beide Mediawiki 1.31.1)? En ga ik een zelfde soort snelheden behalen met mijn VPS als ik daarop Wikimedia werkend krijg met Varnish Cache?

Bedankt!!

[Voor 14% gewijzigd door hyperdry op 14-11-2018 13:41]

[Khallouki]

Wikipedia maakt inderdaad gebruik van varnish caching. Als je in de response header kijkt dan zie je onder andere deze headers staan:

x-cache-status: hit-front
x-varnish: 858013513 329040835, 272965945…86823706, 590496974 370711239
via: 1.1 varnish (Varnish/5.1), 1.1…1), 1.1 varnish (Varnish/5.1)

Afhankelijk van je verkeer en de grootte van je VPS zou je dezelfde snelheid kunnen halen.

[Voor 15% gewijzigd door Khallouki op 14-11-2018 09:55]

[BAJansen]

Het eerst moeten renderen van een pagina kost inderdaad veel langer dan het direct kunnen serveren van een pagina uit een cache. Daarnaast helpt het natuurlijk ook mee dat Wikipedia waarschijnlijk iets krachtigere servers gebruikt dan jij, en niet alle onderdelen van de website onderbrengt op één enkele machine (losse servers voor de webserver, database enz.).

Caching is überhaupt een interessant onderwerp. Als je echt de technische details in wilt duiken is dit artikel van de ontwikkelaar van Varnish erg interessant: https://queue.acm.org/detail.cfm?id=1814327

[hyperdry]

@Khallouki Waardevolle informatie, de bevestiging dat Wikipedia.nl dus inderdaad gebruik maakt van Varnish (5.1). En die opmerking omtrent snelheid, geeft mij weer moed om verder aan de slag te gaan met mijn VPS in SSH! Thx!

@BAJansen Dat vermoedde ik inderdaad al. Maar ik word er blij van dat een flinke snelheidswinst desondanks nog wel te behalen is met inrichten van een goede caching-methode (in dit geval dan via Varnish). Bedankt! Ik ga het door jou gelinkte materiaal doornemen en me überhaupt meer inlezen over caching, interessant onderwerp dit.

Maar eerst moet er door hyperdry maar eens gestudeerd worden voor vakken ondernemingsrecht, belastingrecht en auditing.. Voordat die weer enkel uren maakt op zijn hobby en de studie eronder gaat lijden.

[Voor 60% gewijzigd door hyperdry op 14-11-2018 10:09]

[CodeCaster]

hyperdry schreef op woensdag 14 november 2018 @ 09:40:
een kleine plain html file testpagina, zonder PHP, laadt wel in 200-300ms

En dat is een factor tien te veel. Op deze server ga je niet de performance krijgen die je verwacht. Een statische file van hooguit een paar KB moet in 20-30ms kunnen laden.

Caching gaat ook niet helpen, want dat cachet het opvragen van pagina's, en maar voor een bepaalde tijd. Als jij dus de enige bent die die site gebruikt, zal elke eerste keer dat je een Wiki-pagina opvraagt voor de eerste keer sinds 'ie uit de cache is gekickt, die pagina weer helemaal uit de database moeten worden geladen en gerenderd. En voor het bewerken van pagina's gaat een cache al helemaal niets uitmaken.

Je hebt gewoon een brakke hoster uitgezocht. Wat betaal je ervoor?

[hyperdry]

@CodeCaster Ik was niet duidelijk - die 200-300ms laadtijd v/d plain html file is nog op de shared hosting service (bij NL host)! Dus niet op de VPS. En er zit wel een kleine image in. Ik betaal daar €2/mnd voor de kleinste oplossing. Deze stap heb ik gemaakt met beleid om te testen wat migratie van een US shared hosting- naar NL shared hosting aanbieder oplevert.

Ik denk dat cachen wel helpt voor het bewerken van pagina's via Mediawiki's Edit functie. Ik zal straks eens wat testjes uitvoeren maar het is anders onverklaarbaar waarom mijn wiki Edits afhandelt in 2500ms (US host), 2100ms (NL host), en Wikipedia in iets van 500ms. Zal straks aanvullen met daadwerkelijke snelheden (echte testdata). Daarbij: kan ik de Cache niet instellen op bijv pagina's 30 dagen bewaren? Ontzettend veel pagina's zullen het sowieso nooit worden op mijn persoonlijke wiki. En ik bezoek en Edit bepaalde pagina's tientallen keren per dag (agenda, to do list, studie, studienotes, etc)

[Voor 16% gewijzigd door hyperdry op 14-11-2018 10:24]

[CodeCaster]

hyperdry schreef op woensdag 14 november 2018 @ 10:20:
Ik was niet duidelijk - die 200-300ms laadtijd vd plain html file is nog op de shared hosting service (bij NL host)! Dus niet op de VPS. En er zit wel een kleine image in. Ik betaal daar €2/mnd voor de kleinste oplossing. Deze stap heb ik gemaakt met beleid om te testen wat migratie van een US shared hosting- naar NL shared hosting aanbieder oplevert.

Je moet ook geen appels met peren vergelijken. Maak een pagina met enkel HTML, geen externe resources en benchmark die. Eén KB aan HTML mag echt niet meer dan 10-50ms kosten. Indien significant meer, verander van host.

Ik denk dat cachen wel helpt voor het bewerken van pagina's via Mediawiki's Edit functie. Ik zal straks eens wat testjes uitvoeren maar het is anders onverklaarbaar waarom mijn wiki Edits afhandelt in 2500ms (US host), 2100ms (NL host), en Wikipedia in iets van 500ms. Zal straks aanvullen met daadwerkelijke snelheden (echte testdata) .

Nee. Caching is voor lezen, niet voor schrijven (disk caches daargelaten, maar daar hebben we het hier niet over). Een cache bewaart gegevens die recent van schijf of database zijn gelezen (of bewaart volledige, gerenderde pagina's) om die bij de volgende aanvraag sneller te kunnen retourneren zonder weer naar de disk te hoeven gaan.

Het opslaan van bewerkingen duurt zo lang omdat je shared host waarschijnlijk tientallen, zo niet honderden databases op dezelfde fysieke schijf/schijven heeft staan met een beperkt aantal IOPS.

[hyperdry]

@CodeCaster Bedankt voor je uitgebreide reacties, hier heb ik echt heel veel aan. Ik wil inderdaad juist met name snelheid v/d edits verhogen - ik pas heel veel aan op een dag, af en toe tijdens Editen sla ik tussentijds op. Telkens 2sec laden van het opslaan van een Edit duurt gewoon lang (400ms voelt snel en is mijn doel). Bedankt voor het openen van mijn ogen, dat ik me niet blind staar op caching terwijl daar niet de winst te behalen valt voor mijn doel.

Ik zal straks ter info ook even testen hoe snel een (niet-gecachede) 1KB html file laadt (na runnen van CCleaner) bij mijn huidige shared host en zal terug rapporteren.

[Voor 10% gewijzigd door hyperdry op 14-11-2018 10:38]

[drie van acht]

hyperdry schreef op woensdag 14 november 2018 @ 10:20:
@CodeCaster Ik was niet duidelijk - die 200-300ms laadtijd v/d plain html file is nog op de shared hosting service (bij NL host)! Dus niet op de VPS. En er zit wel een kleine image in.

Dat is dan (waarschijnlijk) toch minstens twee tcp-verbindingen. Kijk in de "waterfall" in de developer tools in je browser. Een "kaal" bestand kan een nette webserver direct van disk in de network stack schuiven ("sendfile()") en hoeft dus niet door een hele reeks aan backend-processen afgehandeld te worden. Is de inhoud html die de browser instrueert ook nog plaatjes, css, fonts, iframes, en zo verder te laden, dan volgen er meer http-aanvragen voor de pagina klaar is met laden.

Ik denk dat cachen wel helpt voor het bewerken van pagina's via Mediawiki's Edit functie.

Caching is een eerder resultaat bijhouden zodat je het nog eens kan opserveren. Ga je de pagina wijzigen dan moet'ie toch echt opnieuw opgebouwd worden. Dus voor de reine net veranderde inhoud zal het niet veel kunnen doen.


Naast het laden van de berg php van mediawiki optimaliseren, waar je nog eindeloos mee zoet kan zijn (andere webserver, verschillende soorten caches, database queries nalopen en tunen, noem maar op) en dan mischien beginnen met een beetje een vlotte host gemeten naar statische paginas, kan je ook naar andere wikisoftware kijken. mediawiki is groot en uitgebreid en mischien een beetje overkill voor als je maar een of een paar gebruikers hebt.

wikimatrix.org laat je een hoop wikis vergelijken (disclaimer: geen relatie). Van de selectie wikis in php heb ik dokuwiki wel ingezet bijvoorbeeld.

[hyperdry]

Zoals gezegd, zou ik terugrapporteren met wat testbevindingen. Ik heb er een soort kleine studie van gemaakt. Zouden jullie zo vriendelijk willen zijn in te gaan op mijn zes vragen? Ook ingaan op beantwoording van één daarvan helpt mij en wordt ontzettend gewaardeerd.

---

SECTIE 1: SNELHEID VAN LADEN PLAIN HTML-FILE, EN .JPG-FILE


@CodeCaster Naar verwachting haalt dit zeker niet de 20-30ms waar jij over spreekt (want shared hosting). O.b.v. jouw post is mijn verwachting dat een goede VPS de 1KB file in 30ms zal serveren. Stap ik over naar een VPS, dan win ik dus 100-120ms voor een statische 1KB file.
Vraag 1: Zal de snelheidswinst groter zijn dan 100-120ms bij pagina's met meer PHP en HTML? Schaalt de snelheidswinst met complexiteit van server-verzoeken?



Vraag 2: De snelheidswinst op het laden van de 3.9MB .jpg-file is kleiner dan de snelheidswinst op de 1KB file. Waarom? Het lijkt of de US host slomer is in het 'parsen' van HTML, maar slechts een fractie slomer in het daadwerkelijk laden van files?

---

SECTIE 2: SNELHEID V/D WIKI BIJ NL-SHARED-HOST vs US-SHARED-HOST


Duidelijk te zien dat de NL shared host wat sneller is. Grote uitschieter bij laden v/d main page bij de US shared host: andere websites op de shared server zullen op dat moment even gepiekt hebben qua verkeer o.i.d.

Wat opvalt is dat het opslaan v/d Editpagina bij de 'slomere' US host, zo'n seconde sneller is dan bij de NL host.
Vraag 3: betekent dit dan dat de US host meer IOPS per server op de shared server beschikbaar heeft gesteld dan de NL host?

---

SECTIE 3: SNELHEID V/D GROTE JONGENS


Deze test gaat in op de snelheid van de grote jongens die van de Mediawiki software gebruikmaken. De hoofdpagina, en de pagina Beleg van Breda op wikipedia.nl laden ontzettend snel. Ik pas mijn doel voor het laden van pagina's aan naar [wikipedia.nl+100ms].

Verder zie ik dat mijn eerdere norm/verwachting omtrent Editen niet reëel is: zelfs de snelste van de groep,
oldschool.runescape.wiki, doet 1500ms over het opslaan van Editpagina's.

Als deze grote jongens voor Opslaan van Editpagina's geen 400ms halen, dan haal ik dat al helemaal niet.
Maar 1500ms is ook prima - oldschool.runescape.wiki voelt snel aan.
Vraag 4: welk stuurmiddel gebruik ik om de laadtijd van het opslaan van Editpagina's van 2300ms
naar 1500ms of sneller terug te brengen? Wat ik inmiddels weet met dank aan @CodeCaster: zoeken van een VPS, dedicated server aanbieder, of zelf een dedicated server opzetten, met een groot aantal IOPS. Hoe hoger het aantal IOPS, hoe hoger de snelheid van het laden v/h opslaan van Editpagina's.
Vraag 5: Waar dien ik nog meer op te letten? Inmiddels zie ik dat je IOPS niet los kan zien van latency https://sohosted.cloud/blog/latency-vs-iops/. Huidige conclusie: sturen op IOPS/latency gains verkleint laadtijd van opslaan van Editpagina's, dit stuurmiddel moet daardoor in mijn zoektocht naar een host/VPS-oplossing de hoogste prioriteit krijgen.
Vraag 6: Hierbij gaat het dan met name om de I (input operations) van IOPS denk ik?


Dank!

---

@drie van acht Dank voor je reactie. Deze klare taal maakt de boel helderder voor een leek als ik. En even nuchter nadenken en uitzoomen is niet verkeerd nee. Ik ben inderdaad het type dat zich zo kan verliezen in optimalisatie van van alles en nog wat waarbij ik volledig aan het doel voorbij schiet en waarschijnlijk een keer de handdoek in de ring gooi omdat ik na urenlange sessies nog niet het gewenste (niet-realistische) resultaat heb bereikt. Jouw reactie gaf mede aansporing te onderzoeken hoe realistisch mijn doelen zijn - i.p.v. halsoverkop aan de slag te gaan en me direct een dag te verliezen in SSH.

Ik ben het ermee eens dat een andere optie voor een persoonlijke wiki (1 user) wellicht een betere keuze
is vanuit het perspectief van performance. Máár, mijn long game is dat ik ook voor de afdeling op mijn werk, vervolgens wellicht voor de hele organisatie, en eventueel andere organisaties/bedrijven snelle en robuuste wiki's kan ontwikkelen.

Vandaar dat ik me graag beperk tot Mediawiki: de in mijn ogen meest gerenommeerde software. Als ik dit op persoonlijk niveau snel kan krijgen, en ik word er handig mee, dan kan ik dat ook voor anderen (waarbij ik ervan bewust ben dat grotere organisaties weer complexere inrichting vereisen [maar daar zijn dan ook gespecialiseerde partijen voor], maar je moet ergens beginnen). Als je elke dag wat bijleert kan het hard ten slotte hard gaan.

[Voor 27% gewijzigd door hyperdry op 14-11-2018 13:57]

[drie van acht]

hyperdry schreef op woensdag 14 november 2018 @ 12:53:
Ik ben het ermee eens dat een andere optie voor een persoonlijke wiki (1 user) wellicht een betere keuze
is vanuit het perspectief van performance. Máár, mijn long game is dat ik ook voor de afdeling op mijn werk, vervolgens wellicht voor de hele organisatie, en eventueel andere organisaties/bedrijven snelle en robuuste wiki's kan ontwikkelen.

Vandaar dat ik me graag beperk tot Mediawiki: de in mijn ogen meest gerenommeerde software.

Je moet het zelf weten maar mijn ervaring is dat de wikisoftware zelf vrij oninteressant is om een wiki aan een organisatie verkocht te krijgen. Het gaat erom dat je de "buy-in" op poten krijgt. Zonder dat verstoft het ongebruikt in een digitaal hoekje. Met dat krijg je iedere redelijke software wel verkocht.

Dit uit mijn ervaring bij verschillende bedrijfjes. Zorg voor een stukje branding (hoort bijna geheel in CSS te kunnen) en zorg dat het gaat leven als een ding dat ook echt handig is binnen het bedrijf. Dat is veel belangrijker dan of het wel hetzelfde is als wat wikipedia gebruikt. Die ook absoluut niet de eersten waren of het patent hebben op goede wiki software.

En dan kun je zelf kiezen wat je aan features naarvoren schuift. Voor mij was bijvoorbeeld "CREOLE"-syntax belangrijk, want dat is vrij makkelijk bij meerdere wikis te krijgen. Dat wikipedia dan net weer anders is, ach. Ze zijn wel bekend maar er zijn meer gebruikers dan editors en van die editors doet maar een paar procent de bulk van het werk. Vandaar dat ze zo druk waren met die nieuwe (en zware) "javascript enhanced" editor: Zodat er minder kennis van de syntax nodig zou zijn voor de af-en-toe-editor. Of het geholpen heeft? Kennelijk niet zo erg want de bulk van het werk wordt nog steeds door een heel klein percentage editors gedaan.

Daarnaast zijn er vele fora die allemaal net even andere syntax hebben, dus het is niet ongebruikelijk dat daar verschillen tussen bestaan. Zorg dus vooral dat de syntax duidelijk te vinden is.

Als ik dit op persoonlijk niveau snel kan krijgen, en ik word er handig mee, dan kan ik dat ook voor anderen (waarbij ik ervan bewust ben dat grotere organisaties weer complexere inrichting vereisen [maar daar zijn dan ook gespecialiseerde partijen voor], maar je moet ergens beginnen). Als je elke dag wat bijleert kan het hard ten slotte hard gaan.

Vanuit mijn perspectief kies je hiermee voor een traject met dit als gevolg: Iemand elders maakte een argument dat'ie al tien jaar PHP programmeerde en dat'ie geen zin meer had nog andere talen te leren want dan zou zijn investering in PHP voor nop zijn geweest.

Daar tuitten mijn oren van. Mijn achtergrond is systeembeheer maar ik schrijf makkelijk een half dozijn talen. Niet allemaal even goed, maar ook van een nieuwe programmeertaal leer je weer nieuwe dingen en dat is dus nooit weggegooide moeite.

Plus als je dit "ik lever wikis"-idee tot "consulting grade" wil opkrikken zul je minstens verschillende opties van webserver, (cacher,) database, ook zonder database, en zo verder, in de vingers moeten hebben. En natuurlijk verschillende wiki-software, want hoewel je best een standaardoplossing mag hebben (hoort te hebben), ben je geen goede consultant als je niets anders kan dan dat. Ook dan is het mischien slimmer met iets simpels te beginnen --een flat-file- of RCS-gebaseerde wiki bijvoorbeeld-- en dan later nog eens een keertje mediawiki aanzwengelen. Of je moet van steile leercurves houden.

Wil je koperslager worden moet je niet beginnen jezelf op een enkele hamer vast te leggen.

[hyperdry]

Hier komt duidelijk wijsheid over.. Bedankt voor het delen hiervan o.b.v. jouw ervaring. Je hebt gelijk. Als ik dit idee van wiki's aanbieden ooit wil commercialiseren, dan zijn mijn klanten op zoek naar een oplossing voor het efficiënt delen en opslaan van kennis, en niet naar een 'Mediawiki' (iemand die in een gereedschapszaak kijkt naar boren om thuis een schilderij op te hangen, is in feite op zoek naar een een gat in de muur... Wellicht zijn er ook andere opties dan de aanschaf van een boor). Als jij als aanbieder precies het fijne weet van alles dat er momenteel op de markt beschikbaar is, daardoor de juiste oplossing kan kiezen, én leveren, dan voeg je natuurlijk echt waarde toe. Ik ga vanmiddag maar eens die link bezoeken die je eerder geplaatst hebt!

TiddlyWiki: hierbij is het mogelijk om een snapshot te maken om je wiki zo te genereren naar een complete verzameling statische html pagina's. Als je zo'n snapshot browset/leest, laadt dat natuurlijk ontzettend snel! Ik ga me hier eens op richten.

[Voor 28% gewijzigd door hyperdry op 14-11-2018 15:44]

[eMiz0r]

hyperdry schreef op woensdag 14 november 2018 @ 12:53:
Vraag 4: welk stuurmiddel gebruik ik om de laadtijd van het opslaan van Editpagina's van 2300ms
naar 1500ms of sneller terug te brengen? Wat ik inmiddels weet met dank aan @CodeCaster: zoeken van een VPS, dedicated server aanbieder, of zelf een dedicated server opzetten, met een groot aantal IOPS. Hoe hoger het aantal IOPS, hoe hoger de snelheid van het laden v/h opslaan van Editpagina's.
Vraag 5: Waar dien ik nog meer op te letten? Inmiddels zie ik dat je IOPS niet los kan zien van latency https://sohosted.cloud/blog/latency-vs-iops/. Huidige conclusie: sturen op IOPS/latency gains verkleint laadtijd van opslaan van Editpagina's, dit stuurmiddel moet daardoor in mijn zoektocht naar een host/VPS-oplossing de hoogste prioriteit krijgen.
Vraag 6: Hierbij gaat het dan met name om de I (input operations) van IOPS denk ik?

Interessant onderzoekje wat je hier doet! Ik wilde toch even mijn ervaringen nog met je delen:

Vraag 4: een VPS lijkt hier wel de beste optie. Je behoudt de schaalbaarheid die je niet hebt met een dedicated server, terwijl je qua performance eigenlijk nauwelijks tot niet hoeft in te leveren (afhankelijk van de infrastructuur er achter natuurlijk). Meer beschikbare IOPS betekent niet per sé beter. Een synthetische benchmark kunnen we allemaal wel draaien, maar het is heel moeilijk om realtime performance te meten. Er zijn storagesystemen op de markt beschikbaar die 1 miljoen of meer IOPS kunnen serveren en op constante basis, maar als je met een doorsnee website hooguit 100 IOPS piekt dan maakt het aantal IOPS eigenlijk niet zoveel meer uit.

Vraag 5: zoals in dit blogartikel inderdaad verwoord wordt is het eigenlijk nog interessanter om te weten hoe hoog en constant de latency is in tegenstelling tot het aantal beschikbare IOPS. In de regel mag je er vanuit gaan dat SSD storage voldoende opdrachten kan verwerken voor lichte tot middelzware applicaties, maar hoe snel 1 opdracht verwerkt kan worden heeft een hogere impact op de overall performance. Voor elke I/O opdracht die de disk moet uitvoeren telt de latency op. Des te meer requests er gedaan worden, des te trager de applicatie (website) die je host.

Vraag 6: yes klopt, de latency naar de disk oftewel hoeveel tijd er voorbij gaat bij het uitvoeren van 1 opdracht richting de disk.

Wat ik vaak in het veld zie is dat partijen schermen met bijvoorbeeld "tot wel 500 MB/s!" Wat dan vaak ontbreekt is op basis van welke metrics die performance gemeten is. Stel een storagecluster kan maximaal 100k IOPS verwerken (makkelijk rekenen) en je test met een 4 kB blocksize, dan kan je nu al uitrekenen dat het SAN maximaal 400 MB/s kan leveren aan performance. Test je echter met 16 kB blocksizes, dan zou je 1,6 GB/s moeten kunnen halen en zo niet, dan is er sprake van een bottleneck (maar welke?). Ik heb zelf een keer in de praktijk getest met een SAN dat meer dan 6 GB/s levert. Hoe spannend die cijfers ook allemaal klinken, op het gebied van performance kan je er niet veel mee zolang je niet weet welke testvariabelen zijn gebruikt. In combinatie met wat je ook daadwerkelijk aan performance nodig hebt.

Als je gaat testen met verschillende aanbieders en verschillende VPS'en, dan zou ik graag willen weten wat de latency is naar de disken toe. AS SSD meet niet alleen de totaal beschikbare bandbreedte, maar ook de latency. Zolang de VPS beschikt over SSD's zou ik me dan ook minder zorgen maken over de totale hoeveelheid IOPS dan over de latency en vooral of die constant is.

En ook al is je infrastructuur helemaal topnotch, dan nog is de configuratie van PHP, MySQL en Apache in combinatie met goede caching ook weer een uitdaging op zich. Uiteindelijk allemaal prima te doen natuurlijk, maar het kost wel tijd

De truc is uiteindelijk om door al die marketingpraat heen te prikken (500 MB/s! 100k IOPS! "BladeVPS PureSSD" wtf?) en een aantal aanbieders te selecteren die je wilt proberen. Ik zou om te beginnen in ieder geval onderscheid maken tussen providers die het goedkoopste beweren te zijn aan de ene kant (DigitalOcean) en die zich richten op kwaliteit aan de andere kant (Previder). DO zou ik wel aandurven voor testomgevingen, maar niet voor productie. Previder is weer te duur voor enkel wat testjes en om dingen te proberen.