Iedereen heeft het inmiddels wel meegekregen: het securitylek in de processor genaamd Meltdown en Spectre. Een securityprobleem dat het mogelijk maakt om geheugen van andere processen te lezen. Nu wordt beweerd dat de patches tegen deze lekken een negatieve impact hebben op de performance. In benchmarks die direct zijn uitgevoerd wordt zelfs gesproken over 30% tragere systemen. Veel bronnen zoals het journaal, namen dit klakkeloos over. Genoeg reden om zelf de proef op de som te nemen.
Dat er een performance hit is die wordt veroorzaakt door de patches, is volgens de theorie goed te verklaren. De kwetsbaarheden zitten in de hardware van de processor en kunnen enkel door middel van een hardware upgrade gedicht worden. Om in de tussentijd bescherming te kunnen bieden aan haar gebruikers hebben de verschillende besturingssystemen een oplossing bedacht die de kwetsbaarheid voorlopig mitigeert. De mitigatieoplossing is echter verre van ideaal, voornamelijk omdat deze behoorlijk resource-intensief lijkt.
Synthetische metingen
De resultaten uit de benchmarks die in de media worden genoemd zijn echter vooral gebaseerd op synthetische metingen, waarbij een verhoogd CPU-gebruik en verlaagde verwerkingscapaciteit werden geconstateerd. Om dit te toetsen hebben we zelf testen uitgevoerd om de impact van de patch op een typische webshop of webapplicatie te meten. Want dat is de zorg die beheerders en website-eigenaren hebben: heeft deze patch invloed op de responstijden en zorgt de patch ervoor dat ik nu minder capaciteit heb?
Voor de test hebben we Magento gebruikt, een populair framework voor webshops, dat draait op Ubuntu 16.10, PHP7, Nginx en Mysql. Om puur en alleen de invloed van de patch te testen hebben we gekozen voor een kernel die alleen nog wordt onderhouden met belangrijke securitypatches. We hebben performance testen gedaan tussen Linux kernel 4.9.74 (zonder de patches) en 4.9.75 (met de patches), waarbij we de responstijden meten onder 1 uur continu hoge load en een stresstest, waarbij we op zoek gaan naar het maximaal aantal page views per seconde.
Impact patch Meltdown en Spectre op de responstijden
De bovenstaande tabel toont de gemiddelde responstijd van verschillende pagina’s. Gemiddeld genomen zijn de responstijden ongeveer 2,5% hoger na de patch. Elke pagina en transactie is binnen een uur duizenden keren opgehaald om een stabiel gemiddelde te kunnen berekenen. Tevens zijn alle testen meerdere malen herhaald en telkens waren de resultaten vergelijkbaar. In deze opstelling zien we dus wel een kleine invloed op de responstijden.
Kijken we naar het CPU-gebruik tijdens de testen, dan zien we een marginaal hoger System-CPU-gebruik. Het relatieve verschil is ongeveer 8%. Een verhoging op dat vlak valt ook te verwachten gezien de werking van de patch. Het User-CPU-gebruik is nauwelijks beïnvloed. Dit verschil is 1% en niet significant.
De stresstest die we hebben uitgevoerd om het maximaal aantal pagina’s per seconde te meten, gaf een minder duidelijk verschil weer. Bij beide testen kwamen we tot ongeveer 13 page views per seconden.
Geen significant verschil page views
Bovenstaande grafiek toont een gelijk beeld tot aan de bottleneck. Op de bottleneck lukt het de versie zonder de patch om marginaal meer page views per seconde te verwerken. Een verschil van 12,6 vs 12,4 per seconde is niet significant genoeg.
Als we naar de verschillen in het CPU-gebruik kijken, dan zijn deze ook redelijk vergelijkbaar. Zoomen we in op het System CPU-gebruik, dan is deze met de patch wat hoger. Als de CPU-bottleneck is bereikt, is het User-CPU met de patch lager en is er dus een fractie minder capaciteit beschikbaar om het aantal page views per seconde te verwerken. Al met al een verschil van minder dan 2%, wat voor de gebruiker nauwelijks merkbaar zal zijn.
Conclusie performance-impact Meltdown en Spectre patch
Onder de streep heeft de patch in deze veelvoorkomende situatie een zeer kleine impact op de performance. Ook de terugval in totale capaciteit is te klein om in de meeste situaties voor problemen te zorgen.
Veel webapplicaties verstoken voornamelijk User-CPU en weinig System-CPU. Deze ondervinden dus gelukkig weinig tot geen hinder van de patch. Zijn alle beweringen over de performance-impact van de patch dan een storm in een glas water? Nee, want er zijn ook (web)applicaties of andere situaties waarbij de impact serieuzer zal zijn. Neem webapplicaties die veel IO hebben zoals applicaties met een database die veel IO-verwerkingen heeft (zowel disk- als netwerk-IO). Ook valt te verwachten dat bepaalde batches een performance-verslechtering ondervinden. Vaak zijn batches sterk IO-gedreven. Het kan dus zijn dat de verwerkingstijd zomaar 30% langer wordt en daarmee andere productieprocessen zal verstoren.
Testen voordat je de patch uitrolt
Er valt dus eigenlijk heel lastig aan te geven welke performance-impact je kunt verwachten. Dit verschilt van implementatie tot implementatie. Als je afhankelijk bent van een goede performance van je omgeving is het belangrijk dat je deze goed test en meet voordat je de patch direct in productie uitrolt. Alleen zo voorkom je dat je voor vervelende performance-verrassingen komt te staan.
