TestAutomatisering & PerformanceTesten

APACHE MPM (op *nix servers)

Benieuwd naar de impact van het wijzigen van Apache MPM Prefork naar Worker? Lees dan door! Bij één van onze klanten heb ik dit onderzocht. Omdat dit ook interessant kan zijn voor anderen, deel ik mijn resultaten en ervaringen graag. Het is misschien wat technisch allemaal, maar voor performancetesters, de doelgroep, is het vast goed te begrijpen!

Ik zal beginnen met een korte uitleg van wat Apache MPM is en welke gangbare smaakjes er zijn voor *nix systemen. Hierna sta ik even stil bij de testen die ik hiervoor heb uitgevoerd en deel ik de conclusie.

Bij de web server Apache kan je kiezen op welke manier de httpd processen ingezet worden. Dit kan door een bepaalde MPM (Multi-Processing Module) te kiezen. MPM luistert naar (bind met) een netwerkpoort en ontvangt requests en laat zijn children de requests afhandelen.

Je hebt de volgende MPM’s:

  • Prefork
  • Worker
  • Event

Welke MPM je moet kiezen, hangt af van thread support en thread-safe polling. Als het systeem het gebruik van threads niet ondersteunt, gebruik je prefork. Anders kijk je nog naar ondersteuning van thread-safe polling. Als dat mogelijk is, kom je uit bij event en anders bij worker. Hieronder worden de verschillende MPM’s kort uitgelegd.

Prefork

Er is 1 parent proces die verantwoordelijk is voor de child processen. De child processen “luisteren” naar nieuwe connecties en handelen deze af. Het parent proces beheert de server pool (de pool met child processen) volgens configuratie.

Worker

Er is 1 parent proces die verantwoordelijk is voor het beheren van de server pool. De server pool bestaat uit child processen en elk child proces heeft zelf ook weer een soort pool van 1 listener thread en meerdere server threads. De listener thread “luistert” naar connecties en verdeelt deze over de server threads die de verzoeken van die connectie afhandelt.

Event

Bij Worker zijn er problemen met keep-alive. De connectie kan worden opengehouden vanaf clientzijde. Hierdoor kan de server thread niet ingezet worden terwijl deze niets aan het doen is (behalve dan wachten). Event MPM lost dit probleem op.

Event MPM is qua opzet gelijk aan de Worker MPM met het verschil dat bij Event de listener thread ook wat processing werk moet doen waaronder de connecties afhandelen van de sockets in keep alive status. Het werk wordt door de server threads op een shared queue gezet.

Event is bij versie 2.2 geïntroduceerd en wordt betiteld als experimenteel. Dit label verdwijnt bij versie 2.4 (op moment van schrijven is een versie 2.5 beschikbaar). Voor Linux wordt een 2.6 kernel geadviseerd.

Het is mogelijk dat Event niet werkt door connection filters die niet compatible zijn. In dat geval wordt automatisch Worker MPM in werking gesteld.

Uitgevoerde testen

Op mijn opdracht heb ik wat testen gedaan met verschillende MPM’s. Dit was voor een test op 1 applicatie waarbij ik bovengenoemde MPM’s heb geprobeerd. Ik heb 2 transacties gebruikt om load op het systeem te zetten. Ik heb het een en ander in een tabel gezet.

MPM Voor de test Tijdens de test Na de test
Httpd processen Prefork 9 118 9
Worker 2 7-8 7
Established connecties Prefork 0 108 0
Worker 0 109-111 0
Transactie 1 average Prefork 0,08
Worker 0,08
Transactie 1

99 percentiel

Prefork 0,12
Worker 0,13
Transactie 2 average Prefork 0,09
Worker 0,09
Transactie 2

99 percentiel

Prefork 0,14
Worker 0,15
CPU Prefork 52-68%
Worker 58-68%

De oplettende lezer heeft mogelijk al gezien dat in bovenstaande tabel MPM Event ontbreekt. Op de omgeving waarin ik testte, draaide Apache 2.2. Dit maakt de MPM Event experimenteel en het uitvoeren van testen en het vergelijken van de resultaten is hierdoor niet betrouwbaar.

Als we kijken naar de resultaten voor Prefork en Worker zien we het (grote) verschil voornamelijk in het aantal httpd processen tijdens de test (118 versus 7-8). Voor Prefork wordt voor elke connectie een httpd proces in gebruik genomen zoals ook verwacht. En bij Worker is dit dus aanzienlijk lager doordat worker httpd processen een pool met meerdere threads bevatten om het werk af te handelen. Met minder processen zou je ook minder CPU gebruik verwachten. Dat zien we niet terug in bovenstaande tabel. Dit komt doordat het aantal gebruikte threads niet heel anders zal zijn dan bij prefork. Dit konden we helaas niet controleren.

De testen wezen uit dat een overgang van Prefork naar Worker geen problemen oplevert.

Ik ben heel benieuwd naar andere ervaringen en bevindingen met MPM testen. Dus reageer vooral!

Dit bericht is geplaatst in Performancetesten en getagd in *nix Apache Prefork Worker

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Nieuws

Blijf op de hoogte

Visual Regression Testing – Wat is het en wat heb je eraan?

07/11/2018

Visual Regression Testing, of visuele regressie testen, is een categorie van testen die zich focust op het identificeren van visuele wijzigingen tussen iteraties of versies van een website. Dit kan handmatig door schermen of schermafdrukken te vergelijken, maar het is beter herhaalbaar en sneller te testen door dit automatisch te doen. Het mooiste is om deze testen als een […]

Meer efficiency en flexibiliteit in API’s

04/10/2018

Er wordt steeds meer gebruik gemaakt van GraphQL API. Tijdens mijn laatste opdracht heb ik hier dan ook mee gewerkt.. Graag deel ik mijn ervaringen hierover in een aantal blogs. In deze eerste blog wil ik het graag hebben over de uitdagingen met REST API en hoe GraphQL deze oplost. Maar eerst even een korte […]

Impact tooling op performance: Dynatrace

21/09/2018

In deze blog geef ik kort de resultaten weer van een onderzoekje dat ik bij één van mijn laatste opdrachten heb gedaan naar de impact van het gebruik van de tool Dynatrace op de infrastructuur waar het op draait. Mocht je gebruik maken van tooling als Dynatrace of op een andere manier geïnteresseerd zijn in […]

Tips en tricks voor Protractor

06/09/2018

Vanuit PerformanceArchitecten doen we graag aan kennisdeling. Van tool reviews tot aan complete best practices maar ook van een aantal simpele tips en tricks die je kan gebruiken in je dagelijkse werk. Vandaag in die laatste categorie voor gebruikers van Protractor: (Javascript) timing issues en het managen van de volgorde van uitvoeren van actions. Inleiding […]

PerformanceArchitecten @The Next Web conferentie

04/07/2018

Was het een interessante conferentie? Beslist. Heeft TNW PerformanceArchitecten op nieuwe ideeën gebracht? Zeker. Heb jij TNW gemist, maar wil je je wel in vijf minuten op de hoogte laten brengen? Lees dan snel verder! En mocht je er wel zijn geweest.. We zijn benieuwd naar jouw beeld! Wat is de Next Web? Voor hen […]

De ‘waar begin ik met testautomatisering’ handleiding.

11/04/2018

Wij worden regelmatig gevraagd te helpen bij het opzetten of verbeteren van testautomatisering in een Agile omgeving bij een klant. En hoeveel ervaring je ook hebt, wat je opdracht ook precies inhoudt en in welk team je ook terechtkomt, het is altijd even zoeken waar te beginnen. Onderstaand stappenplan ondersteunt hierbij. PerformanceArchitecten organiseert veel kennissessies. Zo […]

Wat is het Bug Filter?

26/03/2018

Een algemeen gedeelde opvatting over het doel van testen binnen software ontwikkeling is “het tegenhouden van bugs en het afdekken van risico’s”. Over hoe dit vervolgens het best valt te organiseren, bestaan er echter vaak veel meningsverschillen. In deze 2 minute snack sta ik graag even stil bij een inzicht dat verhelderend werkt in deze […]

Testen? Begin bij de basis! | Het belang van unittesten

19/02/2018

Inleiding Mijn vrouw en ik zijn op dit moment bezig met het bouwen van een huis. In dit geval niet als bouwvakker of aannemer, maar dan toch wel als opdrachtgever. Spannend vinden we het zeker, leuk ook. Wat heeft dit te maken met unittesten zou je denken. Nou, het volgende… Het huis wordt namelijk gebouwd […]

De Absolute Beginners Guide voor API Testen met rest-assured.io

16/01/2018

Omdat het moeilijk was om een eenvoudige tutorial te vinden voor rest-assured.io, ben ik na eerst zelf uit te vinden hoe het werkt, maar eens begonnen met een tutorial die de absolute basics uitlegt over rest-assured. In deze post laat ik zien hoe we op een zo eenvoudig mogelijke manier een API test kunnen maken met […]

APACHE MPM (op *nix servers)

07/11/2017

Benieuwd naar de impact van het wijzigen van Apache MPM Prefork naar Worker? Lees dan door! Bij één van onze klanten heb ik dit onderzocht. Omdat dit ook interessant kan zijn voor anderen, deel ik mijn resultaten en ervaringen graag. Het is misschien wat technisch allemaal, maar voor performancetesters, de doelgroep, is het vast goed […]

Performancetesten en CI/CD, gaat dat samen?

13/10/2017

De afgelopen najaarseditie van Testnet stond onder het thema Continuous Everything vooral stil bij CI/CD en natuurlijk testen. Gezien DevOps en CI/CD ook grote invloed hebben op het vakgebied performance (testen), zijn wij blij dat we vanuit PerformanceArchitecten een bijdrage mochten leveren door middel van het delen van onze visie hierop. Onze collega René Meijboom […]

Een eerste indruk van Gauge

08/09/2017

Tijdens één van onze kennismiddagen hebben we gekeken naar het testtool Gauge. Doel van de sessie was om een beeld te krijgen wat de toegevoegde waarde van Gauge is voor een tester. Benieuwd naar onze ervaringen? Lees dan snel verder! Gauge is een open source project, gesponsord door ThoughtWorks en belooft in het kort het […]