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.
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!
Comments