PRESTATIES NGINX WEBSERVER

Transcriptie

1 PRESTATIES NGINX WEBSERVER Welke configuratiewaarden dienen gebruikt te worden voor de hoogst haalbare prestaties van de Nginx webserver? 1. Welke design architectuur implementeert Nginx? 2. Wat doen de configuratieopties worker_processes, multi_accept en use epoll? 3. Wat zijn hun standaardwaarde en waarom? 4. Welke invloeden hebben hun configuratiewaardes? Chris Lahaye Onderzoeksvaardigheden

2 Content 1 Introductie Probleemstelling Aanleiding Probleem Doelstelling Vraagstelling Hoofdvraag Hypothese Deelvragen Planning Methode Testomgeving Prestatietesten Onderzoeksresultaten Single-threaded architectuur Processor utilisatie Simultane verbindingen Event notificatiemechanisme Conclusies... 13

3 1 Introductie nginx uitgesproken als engine x is een open-source webserver en reverse proxy ontwikkeld door de Russische programmeur Igor Sysoey. Vanaf 2004, het jaar van de eerst publieke release door Nginx, Inc, is er veel aandacht besteed aan de prestaties van de webserver. Zaken als high concurrency (het in staat zijn om veel aanvragen simultaan af te handelen) en geheugenverbruik zijn al vroegtijdig opgenomen tijdens de ontwikkeling van de Nginx webserver waardoor de software is uitgegroeid en bekend staat als een snelle en lichtgewicht webserver. (Nginx, Inc, n.d.) 1

4 2 Probleemstelling 2.1 Aanleiding Voor het vak onderzoeksvaardigheden, gegeven in blok 11 Professional Software Engineering aan de Fontys Hogeschool ICT, dient de student zelfstandig een volledige onderzoekscyclus te doorlopen ter voorbereiding op de afstudeerstage. Al vele jaren maken vele websites een essentieel deel uit van het Internet en de infrastructuur die je wellicht nu gebruikt om dit document te downloaden en te lezen. Deze websites worden beschikbaar gesteld door middel van een webserver, een programma dat aanvragen via het HTTP netwerkprotocol afhandelt. Omdat Nginx tegenwoordig een gewenst en veel gebruikt alternatief is voor de Apache webserver richt dit onderzoek zich op optimalisatie van de Nginx webserver. 2.2 Probleem Webservers zijn zeer complex bij design en ontworpen als doel om zo veel mogelijk aanvragen met zo min mogelijk middelen binnen een korte tijd af te handelen. Omdat software vaak geschreven wordt om zo breed mogelijk ingezet te kunnen worden wordt configureerbare software ontworpen. Hierdoor kunnen bijvoorbeeld opties aan of uitgezet worden zodat de software zowel op een Linux of Windows werkzaam is, zonder dat die overbodige functionaliteit alle kostbare middelen opeist. De Nginx webserver staat er om bekend om en naar eigen zeggen hoog configureerbaar en van lichtgewicht te zijn. Door middel van de vele functionaliteiten en configuratieopties kan Nginx naar ieders wens gebruikt worden. Echter richten bestaande prestatietesten zich vooral op de verschillen in prestaties tussen Nginx en andere webservers. Omdat onduidelijk is wat voor invloeden bepaalde configuratieopties hebben op de algehele performance van Nginx zelf, richt dit toetsend onderzoek zich vooral op het bewijzen en aantonen van de theoretische hypotheses van iedere configuratieoptie. 2

5 2.3 Doelstelling Het doel van dit onderzoek is inzicht bieden welke invloeden bepaalde configuratieopties uitoefenen, en dus hoe de hoogst haalbare prestaties van de Nginx webserver behaald kunnen worden. 3

6 3 Vraagstelling 3.1 Hoofdvraag De hoofdvraag van dit onderzoek luidt: Welke configuratiewaarden dienen gebruikt te worden voor de hoogst haalbare prestaties van de Nginx webserver?. 3.2 Hypothese Voor de hoogst haalbare prestaties dient de waarde van de configuratieoptie worker_processes gelijk te zijn aan het aantal rekenkernen. Daarnaast moet Nginx geconfigureerd worden met de multi_accept configuratieoptie om verbindingen zo snel mogelijk en tegelijkertijd te accepteren. Nginx dient gebruik te maken van het epoll event notificatiemechanisme zodat aanvragen afgehandeld kunnen worden zonder intensieve pollingtechnieken. 3.3 Deelvragen Welke design architectuur implementeert Nginx? Omdat de prestaties van software onderzocht worden is het essentieel om de architectuur te begrijpen zodat theorie op de praktijk afgestemd kan worden. Relevant is bijvoorbeeld of de software multi- of singlethreaded is, of als de berichtgeving event-driven, publish-subscribe of überhaupt asynchroon verloopt. Voor het beantwoorden van deze deelvraag wordt gebruik gemaakt van de biebstrategie. Wat doen de configuratieopties worker_processes, multi_accept en use epoll? Deze configuratieopties worden vaak beschreven en gewijzigd omdat ze de grootste (positieve?) impact zouden hebben op de prestaties. Deze deelvraag heeft als doel om inzicht te krijgen in de werking van de genoemde configuratieopties. Voor het beantwoorden van deze deelvraag wordt gebruikt gemaakt van de biebstrategie. Bij de deelvraag Welke invloeden hebben hun configuratiewaardes wordt deze theorie getoetst door middel van de lab-strategie en datagericht onderzoek. 4

7 Wat zijn hun standaardwaarde en waarom? Deze deelvraag biedt extra kennis over de configuratieopties. Belangrijk is wat de standaardwaarde van een configuratieoptie is, maar vooral waarom er gekozen is voor deze waarde en zijn doel. Voor het beantwoorden van deze deelvraag wordt gebruik gemaakt van de biebstrategie. Welke invloeden hebben hun configuratiewaardes? Om de hoofdvraag te kunnen beantwoorden worden de prestaties van Nginx getest bij gebruik van de standaard- en afwijkende waarden voor iedere configuratieoptie. Iedere configuratiewaarde wordt getest door middel van de lab-strategie en datagericht onderzoek. Na verloop beschrijven de resultaten welke configuratiewaarden gebruikt dienen te worden voor de hoogst haalbare prestaties. 5

8 4 Planning De planning is verdeeld over drie fasen: 1. Literatuuronderzoek Voor deze fase is één week uitgetrokken en worden de volgende deelvragen beantwoord: - Welke design architectuur implementeert Nginx? - Wat doen de configuratieopties worker_processes, multi_accept en use epoll? - Wat zijn hun standaardwaarde en waarom? 2. Prestatietesten Voor deze fasen is twee weken uitgetrokken en wordt de volgende deelvraag beantwoordt: Welke invloeden hebben hun configuratiewaardes?. 3. Verslaglegging Voor verslaglegging is één week uitgetrokken. 6

9 5 Methode 5.1 Testomgeving De prestatietesten worden uitgevoerd tussen een laptop met een Intel Core i7-2630qm processor geklokt op 2.9GHz met vier fysieke kernen en een computer met een AMD Phenom II X6 1055T processor geklokt op 3.8GHz met zes fysieke kernen. Bewust is gekozen om gebruik te maken van een trager en een sneller systeem om ervoor te zorgen dat de server maximale werkcapaciteit verduren krijgt. De systemen zijn met elkaar verbonden door middel van een directe peer-to-peer verbinding zonder extra hardware om een bottleneck in netwerk infrastructuur te voorkomen. De laptop bevat een schone installatie van de 64-bits editie van CentOS 7 met Nginx versie el7. De computer draait een schone en bijgewerkte Arch Linux 64-bits installatie met de prestatietestsoftware Siege versie Energiebesparing- en turbofuncties zijn uitgeschakeld door middel van aanpassingen in de BIOS en door gebruik te maken van de performance governor in de Linux kernel voor de maximale klokfrequentie (Brodowski, n.d.). Firewalls staan uitgeschakeld en het limiet op het aantal file discriptoren is verhoogd naar Laptop Computer Server Client Intel Core i7-2630qm 4 x 2.9GHz AMD Phenom II X6 1055T 6 x 3.8GHz CentOS 7 64-bit Arch Linux 64-bit Nginx el7 Siege

10 5.2 Prestatietesten Prestatietesten worden uitgevoerd door middel van Siege met het volgende commando siege b c 100 r De c-argument bevat het aantal simultane verbindingen (concurrency), de gebruikte waarden liggen tussen honderd en duizend met een stapgrootte van 100. De r-argument bevat het repetities, de gebruikte waarde is gebaseerd op het aantal simultane verbindingen en gezet naar een waarde voor een totaal van één miljoen verbindingen. De b-argument is gebruikt om de prestatietestmodus te activeren om ervoor te zorgen dat er niet tussen iedere repetitie een pauze van een seconde plaats vind. 8

11 6 Onderzoeksresultaten 6.1 Single-threaded architectuur Nginx implementeert een event-driven single-threaded architectuur met als doel om hogere prestaties te behalen dan als bij process- of thread gebaseerde architecturen. Gebruik van geavanceerde event notificatiemechanismen in besturingssystemen heeft geleid tot een asynchroon, single-threaded en niet-blokkerende architectuur dat de basis vormt van de Nginx webserver (Zhu, 2009). Apache daarentegen implementeert een traditioneel thread-per-connectie architectuur waarbij zoals de naam al suggereert iedere verbinding in eigen thread afgehandeld wordt. Doordat Apache gebruik maakt van blokkeerbare in- en output operaties, die de executie tijdelijk blokkeren tussen het aanvragen en ontvangen van informatie, is het noodzakelijk om iedere verbinding in eigen thread af te handelen ter realisatie van concurrency. Het voordeel van de event-driven single-threaded architectuur die Nginx implementeert is dat er efficiënter met beschikbaar geheugen en rekenkracht wordt omgegaan. Voor iedere thread dient namelijk een eigen thread control block, user- en kernel stack te worden aangemaakt (Stallings, 2011, pp ). Voor factoren als geheugenverbruik en beschikbare rekenkracht in multi-threaded high-concurrency applicaties werkt dit zeer nadelig. 6.2 Processor utilisatie De werkzaamheden van Nginx kunnen verdeeld worden over meerdere werkprocessen. Ieder werkproces heeft volgens de single-threaded architectuur maar één thread. Door gebruik te maken van meerdere werkprocessen kan Nginx beter geschaald worden om hogere processor utilisatie te behalen op multikernprocessoren. In de meest optimale conditie draait ieder werkproces op een eigen kern. Daartoe de verwachting dat Nginx beter presteert als het aantal werkprocessen gelijk is aan het aantal fysieke kernen. Op gelijkaardige wijze beredeneert Nginx de standaardwaarde voor het aantal werkprocessen van de webserver. In andere woorden Nginx heeft standaard één master proces en x werkprocessen waarbij x gelijk is aan het aantal fysieke kernen y. Door middel van de configuratieoptie worker_processes kan het aantal werkprocessen worden ingesteld. (Nginx, Inc, n.d.) 9

12 Aantal afhandelingen per seconde Aantal afhandelingen per seconde Prestaties Nginx webserver Met deze gedachte zijn de prestaties getest tussen scenario s waarbij x de configuratiewaarde: - x = 1 voor één thread; - x = y voor de optimale conditie; - en x = 2y Afhandelingen per seconde per aantal werkprocessen werkproces 4 werkprocessen 8 werkprocessen Aantal simultane verbindingen 6.3 Simultane verbindingen Standaard is Nginx geconfigureerd om inkomende verbinding eerst af te handelen voordat er een nieuwe geaccepteerd kan worden. Door middel van de configuratieoptie multi_accept kan dit mechanisme omzeild worden. Oftewel door deze configuratieoptie te activeren kunnen meerdere verbindingen tegelijk worden afgehandeld. Onderstaande resultaten vergelijkt de prestaties tussen scenario s waarbij multi_accept aan of uit staat en waarbij aantal werkprocessen x = 2y. Afhandelingen per seconde met multi_accept Aantal simultane verbindingen multi_accept uit multi_accept aan 10

13 6.4 Event notificatiemechanisme Select() en poll() kernelaanroepen De select() kernelaanroep wordt gebruikt om de status van geopende file descriptoren te onderzoeken en zo bijvoorbeeld uit te sluiten of er events of data beschikbaar zijn of niet. Hiervoor dienen eerst verscheidene structuren worden opgezet met de gerelateerde file descriptoren. Deze structuren zijn niet persistent omdat ze overschreven worden door de kernel na iedere aanroep. Ze zijn dus niet persistent en dienen dus iedere keer opnieuw aangemaakt te worden. In applicaties die veel verbindingen tegelijkertijd afhandelen kan dit een probleem vormen omdat er dan door een lijst van honderden en soms duizenden file descriptoren gescand moet worden (Kegel, 2006). Daarnaast is het gebruikelijk dat persistente connecties, geïntroduceerd met HTTP 1.1. en sindsdien standaard, na de aanvraag open blijven voor eventuele nieuwe aanvragen (The Internet Society, 1999). Hierdoor kan de lijst met file descriptoren gigantisch worden en afbreuk doen aan de algehele prestaties van het systeem. Dit probleem staat bekend als het C10K probleem (Kegel, 2006). Epoll de Linux variant van kqueue in Unix is een schaalbaar event notificatiemechanisme dat de select() en poll() kernelaanroepen vervangt. Met epoll hoeft maar één structuur in de kernel te worden aangemaakt die alle betrokken file descriptoren omvat. Deze structuur wordt persistent beschikbaar gesteld aan de user-space en bevat enkel de beschikbare file descriptoren. De prestaties van dit mechanisme liggen significant hoger doordat alleen de descriptoren die events of data tot beschikking hebben worden teruggegeven. 11

14 Aantal afhandelingen per seconde Prestaties Nginx webserver Het epoll event notificicatiemechanisme kan geactiveerd worden door middel van de use epoll configuratie optie. Onderstaande resultaten vergelijken prestaties tussen scenario s waarbij gebruik is gemaakt van het select() met poll() en met epoll. Het aantal werkprocessen is x = 2y en multi_accept staat op aan. Afhandelingen per seconde per eventmechanisme Aantal simultane verbindingen select() en poll() epoll 12

15 7 Conclusies De prestatietesten tonen aan dat de prestaties bij gebruik van één werkproces significant lager liggen dan bij vier of acht werkprocessen. Echter presteert Nginx beter met acht werkprocessen terwijl het systeem maar vier fysieke kernen heeft. Dit heeft wellicht te maken met de Hyper-threading functionaliteit die het besturingssysteem in staat stelt om niet één maar twee threads per fysieke kern uit te voeren. Het activeren van de multi_accept configuratieoptie en het epoll eventmechanisme heeft maar minimale invloed op de prestaties van de Nginx webserver. Wellicht dat het bij een hoger aantal simultane verbindingen denk aan duizenden van meer belang is. 13

16 Bronnen Brodowski, D. (sd). CPU frequency and voltage scaling code in the Linux(TM) kernel. (N. Golde, Redacteur) Opgeroepen op april 22, 2015, van The Linux Kernel Archives: Kegel, D. (2006, september). The C10K problem. Opgeroepen op april 21, 2015, van Dan Kegel's Web Hostel: Nginx, Inc. (sd). About nginx. Opgeroepen op april 21, 2015, van Nginx: Nginx, Inc. (sd). Core functionality. Opgeroepen op april 21, 2015, van Nginx: Stallings, W. (2011). Operating Systems (Sevent International ed.). Harlow, Essex, England: Pearson Education Limited. doi: The Internet Society. (1999, juni). Hypertext Transfer Protocol -- HTTP/1.1. Opgehaald van The Internet Engineering Task Force (IETF): Zhu, J. (2009, september 21). Nginx internals. Opgehaald van SlideShare: 14