Nieuwe Apache-versie moet beter presteren onder druk

Apache heeft versie 2.4 van de populaire Apache-webserver uitgebracht; de eerste grote update in zes jaar. De nieuwe versie moet onder meer beter met systeemresources omgaan om zo tegenwicht te kunnen bieden aan nginx.

Hoewel de Apache HTTP Server nog verreweg de populairste webserver is, wordt met name nginx steeds vaker ingezet, al dan niet als loadbalancer voor een Apache-installatie. De nieuwste versie van Apache moet tegenwicht bieden aan de vlot toegenomen populariteit van nginx; deze versie gaat beter om met systeembronnen, belooft de Apache Foundation.

Versie 2.4 is de eerste grote update in zes jaar en komt uit in het zeventiende jaar dat de webserversoftware wordt ontwikkeld. De software, oorspronkelijk een fork van een project van een Amerikaans supercomputer-instituut, moet niet alleen beter omgaan met beschikbare systeemresources, maar er ook minder van gebruiken en betere ondersteuning voor caching bieden. Daardoor moeten servers met veel verkeer beter presteren.

Verder zijn er verschillende nieuwe modules beschikbaar, zoals een aantal add-ons voor mod_proxy, officiële ondersteuning voor de programmeertaal Lua en een module waarmee gebruikers kunnen worden geauthenticeerd via een html-formulier. Voorheen was er in Apache enkel ondersteuning voor authenticatie op protocolniveau aanwezig en moest voor authenticatie met input uit html-formulieren een programmeertaal of een third-party-module worden gebruikt.

Een aantal meegeleverde modules is bijgewerkt. Zo heeft mod_ssl vanaf nu ondersteuning voor het controleren van client-side-certificaten met behulp van een ocsp-server en wordt het maken van leesbare url's vergemakkelijkt door een update van mod_rewrite. Met de bijgewerkte versie van die module kunnen bijvoorbeeld rewrite-mappings worden gegenereerd op basis van sql-queries.

Voortaan kunnen multi-processing-modules bovendien tijdens het starten van de webserver worden geselecteerd; voorheen moesten deze bij het buildproces worden in- of uitgeschakeld. De nieuwe versie kan worden gedownload onder een Apache 2.0-licentie.

Reacties (51)

[shadylog]

Mooi zo'n nieuwe versie, maar zolang ze prefork en worker niet "deprecaten" en gebruikers de nieuwe mpm-event dus niet gebruiken verandert er dus niks. Bijvoorbeeld zend server voor compatibiliteitsredenen werkt het beste onder mpm-prefork, wat erg langzaam is.
Maar dit is een enorm goede stap in de goede richting, en ik hoop dat prefork en worker steeds minder gebruikt zullen worden.

[elmuerte]

De reden waarom prefork zo veel gebruikt wordt is mod_php. PHP is nog steeds niet threadsafe. Dus als je PHP wilt gebruiken moet je of prefork gebruiken of PHP in CGI mode gebruiken. En dat laatste heeft nogal een crappy performance vergeleken met mod_php.

[hostname]

Volgens mij is met php-fpm, welke aanwezig is sinds PHP 5.3.3, de FastCGI performance van PHP stukken verbetered. Heeft wel als nadeel dat het wat meer configuratie nodig heeft en dus minder geschikt is voor shared hosting, maar voor servers die slechts een/enkele applicaties draaien werkt het volgens mij stukken beter.

[YaPP]

PHP is idd niet threadsafe, en zal het ook niet snel worden. Diverse PHP modules zijn een dun laagje om een C library heen (bijvoorbeeld mysql_..() en libxml functies). Om PHP threadsafe te maken, moeten al deze onderliggende libraries ook threadsafe worden, en dat is nog moeilijk te garanderen.

Je kunt PHP ook via FastCGI aanbieden, Apache kan dan in een thread/event MPM draaien, en stuurt PHP requests door naar een batterij PHP-FastCGI daemons op het systeem (evt met php-fpm hierboven).

Voordeel is ook, dat je meer controle hebt over het geheugengebruik van PHP. Als PHP in de webserver zit (prefork + mod_php), zul je zien dat al je Apache processen 1 voor 1 ineens meer geheugen nodig hebben. Dat komt omdat in dat proces PHP geïnitialiseerd is, evt. aangevuld met gecachte objecten / APC cache. Bij een FastCGI/fpm oplossing blijft de PHP executie en bijkomend geheugengebruik beperkt tot een strict aantal processen.

[Reactie gewijzigd door YaPP op 23 juli 2024 04:14]

[Kees]

hoezo is mpm-prefork langzaam? Ja, met statische images etc, maar qua php zal prefork sneller zijn dan wanneer je fcgi gebruikt icm php

[shadylog]

Dat klopt, maar je zegt het zelf al. Met statische images en normale requests gaat het dus niet goed. Wat je trouwens vaak ziet is dat nginx ingezet wordt om de statische requests op te vangen en de rest doorgesluist wordt naar apache->mod-php/zend-server.
Deze nieuwe versie zal hopelijk ook statische requests goed kunnen doen. En deze versie heeft ook nog een nieuwe fastcgi-starter ingebakken!

[GlowMouse]

De echte verbetering is hier de event Multi-Processing Module. Zonder deze module neemt elke verbinding één thread in beslag (Apache heeft er maximaal 256), ook als deze in keep-alive modus zit en niks opvraagt. Dit zorgde voor eenvoudig uit te voeren DOS-aanvallen (zoals slowloris 2,5 jaar geleden), omdat je door het openhouden van 256 verbindingen ervoor zorgde dat niemand anders kon verbinden.

Met deze module gedraagt Apache zich iets meer als webservers als lighttpd en nginx, door threads alleen te gebruiken als er daadwerkelijk iets gedaan moet worden.

[Mathijs1]

Andere MPM's gebruiken is geen oplossing voor slowloris-aanvallen, of er nou 256 threads open moeten blijven staan of 2500, vol krijg je ze toch wel. Wat wel een echte oplossing voor slowloris is, is http://httpd.apache.org/docs/current/mod/mod_reqtimeout.html

[Verwijderd]

Apache heeft er maximaal 256

Standaard ja en zonder threading door de MaxClients.

Je kon nu al met de mpm module aangeven hoeveel processen (StartServers) en hoeveel threads er bij opstarten moeten draaien (StartThreads), hoeveel threads minimaal moeten draaien (MinSpareThreads), hoeveel er maximaal bij geschaald kan worden (ThreadLimit) per proces en wanneer er terug geschaald wordt (MaxSpareThreads). Met MaxClients geef je aan hoeveel clients je tegelijk kunt helpen. Maarja, dat is onder bijna alles behalve Windows.

Onder Windows draaien er eigenlijk altijd maximaal 2 processen waarvan 1 je requests afhandelt en de andere de aansturing doet. Onder het eerste proces draaien zoveel threads als nodig is met een maximum van ThreadsPerChild, standaard 64 en deze waarde moet omhoog om meer gelijktijdige requests af te handelen. Verder is ThreadLimit van toepassing onder Windows maar slechts als plafond voor ThreadsPerChild en met een standaard maximum van 1920.

quote: http://httpd.apache.org/docs/2.0/mod/mpm_winnt.html

This Multi-Processing Module (MPM) is the default for the Windows NT operating systems. It uses a single control process which launches a single child process which in turn creates threads to handel requests

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:14]

[s.stok]

Ook niet onbelangrijk is dat in mod_ssl de ondersteuning voor SSLv2 is gedropt.
En dat NameVirtualHost niet langer verplicht zijn.

Daarnaast is er een experimentele ondersteuning voor virhosts draaien onder een eigen gebruiker. Alleen Solaris op het moment, maar het zou tijd worden dat Apache zelf iets ging bieden, al is het maar een begin.

En, iets waar vooral nginx vooral bekent om staat.

Per-request configuration sections
<If>, <ElseIf>, and <Else> sections can be used to set the configuration based on per-request criteria.

Dus zeker een hoop moois.

[Mathijs1]

Voor het draaien van virtualhosts onder een eigen gebruiker zijn ook een aantal andere oplossingen, bijvoorbeeld mpm_itk (http://mpm-itk.sesse.net/ , nadeel is dat dit wel traag is, aangezien het een patch op de prefork mpm is), of mod_ruid2 (http://sourceforge.net/projects/mod-ruid/)

Probleem met al deze 'trucs' is dat het hele security model van Linux ongeschikt is voor zulke oplossingen. De enige user die de identiteit van een andere user kan aannemen is root, en als je Apache dus elke vhost naar een unix user wil laten 'setuid-en', dan zul je je HTTP request als root moeten ontvangen. En dat is natuurlijk met oog op security weer niet zo'n goed plan

[arjankoole]

Dat moet sowieso, omdat alleen UID 0 (root) kan binden op poorten lager dan 1024. Daarnaast dropped apache de meeste van z'n root privileges zodra dat gedaan is. Ik heb nog niet meegemaakt dat iemand via apache's non-priv user weer het root owned proces binnenkwam.

Dus wat je zegt is onmogelijk, op iedere Unix.

[Mathijs1]

Je kan prima het apache parent process als een andere user draaien, zie het Apache voorbeeld op deze pagina: http://www.friedhoff.org/posixfilecaps.html

Maar over het verschil wat ik probeerde duidelijk te maken, normaliter forkt het httpd parent proces zich in een aantal child processes die draaien met de gebruiker en groep die je in je config instelt (User apache, Group apache, bijvoorbeeld). Die child processes handelen vervolgens de requests af, van begin tot einde. Wanneer er een bug zou zitten in de afhandeling van de http headers, dan zou deze middels privilege escalation alleen de rechten van deze apache user/group krijgen.

Echter als je per vhost will switchen van user, dan zal het child process als root moeten draaien, en kan privilege escalation tijdens afhandeling van een request leiden tot root-toegang.

[s.stok]

mod_ruid2 ken ik al ja maak er zelf gebruik.
En heb ook een heel artikel geschreven over de verschillende mogelijkheden.

http://www.pfz.nl/wiki/ap...uiste-gebruiker-uitvoeren

Ik vind het met name goed nieuws dat Apache nu 'zelf' ondersteuning is gestart, want ondanks dat er verschillende modules voor bestaan en SuExec via CGI kan worden gebruikt is het iets waar iedereen al jaren om loopt te zeuren en één van de redenen is waarom sommige server beheerders (lees prutsers) chmod 777 als oplossing aandragen.

Maar als Apache het zelf bied kunnen ze het eindelijk meteen goed doen, en zal één gehackte site niet gelijk tot het hacken van andere sites uitlopen.

Voor mij persoonlijk maakt het niets uit, voor de gebruikers is uiteindelijk wel beter.

[Mathijs1]

Erg belangrijk om te vermelden is dat de Windows versie van Apache HTTPD 2.4 niet goed werkt icm. SSL, hiervoor staan nog enkele kritieke bugs open. Mocht je dus een Windows server beheren waar je Apache + SSL op draait: gewoon nog even 2.2.22 blijven gebruiken

[TvdW]

Leuk, maar dit levert nog geen ondersteuning voor bijv. websocket. Ook Comet wordt slecht ondersteund. Een echte terugkeer zal Apache hier ook vast niet mee maken, daar is nginx te snel voor.

[Reactie gewijzigd door TvdW op 23 juli 2024 04:14]

[simplicidad]

Er zijn toch veel betere oplossing als je dergelijke zaken wilt zoals bvb node.js ? http://nodejs.org/

Ik vind het nu niet een bepaald gemis in Apache.

[Reactie gewijzigd door simplicidad op 23 juli 2024 04:14]

[TvdW]

En da's nou precies wat ik bedoel, voor dat soort dingen moet je direct naar andere webservers.

[Verwijderd]

Je hebt er plugins voor zie link hieronder

[Ventieldopje]

Nginx mag wel iets aan hun website doen, alleen daar om ben ik al een beetje huiverig om dit grootschalig in te gaan zetten

Geef mij maar lekker apache

[wica]

Ik vind deze website top, laat zien dat ze alleen bezig met het ontwikkelen van de code

[cbravo2]

kennelijk heb je niet zoveel page views/s...

[Verwijderd]

Apache kan behoorlijk ver gaan, zeker als je die met bijvoorbeeld de worker MPM kunt laten draaien en met Varnish ervoor. Ik zou dus niet te snel conclusies trekken.

[erikdenv]

Websockets kan ondersteund worden via een module:
https://github.com/disconnect/apache-websocket

Over welke terugkeer heb je het eigenlijk, Apache is nog steeds veruit de grootste.
http://news.netcraft.com/...tegory/web-server-survey/

[Reactie gewijzigd door erikdenv op 23 juli 2024 04:14]

[Verwijderd]

http://activemq.apache.org/websockets.html

[Sv3n]

Dat is heel iets anders, dit artikel gaat over Apache httpd, ActiveMQ een JMS messagebroker en heeft niets met Apache httpd te maken. De enige relevantie is dat beide producten van de Apache foundation zijn.

[Yggdrasil]

Mooie verbeteringen hoor!

Ben benieuwd wanneer deze versie in de distro's beschikbaar komt.

[army]

Voor alle Debian afgeleiden zou ik rekenen op na 2013Q1 aangezien de freeze voor Debian Wheezy voor juni dit jaar op de planning staat. De laatste grote aanpassing de hoogstwaarschijnlijk mee gaat is GNOME 3.4 en gezien de problemen met sysvinit versus systemd nu bv en GCC 4.6 in het verleden zullen er gok ik geen grote wijzigingen meer komen. Misschien dat Ubuntu zelf aan de slag gaat met Apache 2.4 voor release 12.10, maar of je er dan al productie mee wilt draaien is de vraag. Gezien het verleden kan je er bij 2.4.3 of 2.4.4 weleens over na gaan denken en dat zitten we toch al in 2013. Je zou hoogstwaarschijnlijk wel een poging voor 2.4 in Debian Experimental zien binnenkort, maar dat is koffiedik kijken nu.

[i-chat]

resultaten uit het verleden bieden geen garantie voor de toekomst, dan is het dus vraag of er een backport komt naar 12.04 - en dat hangt weer af van de lifecycle van apache want als die stoppen met 2.2 updates (over bijv een half jaar) dan is de lts status van 12.04 server nog niet eens op de helft, en moeten ze dus wel upgraden... maar eerlijk is eerlijk de kans is dat men nog lang genoeg bij 2.2 kan blijven en dan zie je dus hooguit backports of ppa's..

voor mensen die de nieuwe features nodig hebben is dat TOCH geen probleem..

[Phoenix1337]

Of ze stoppen m in 12.04.1 of nog iets latere versie. In 12.04 zal hij denk ik niet komen aangezien dat wel heel kort dag is.

[AugmentoR]

Voor de duidelijkheid: apache stopt echt niet al over een half jaar met updates op 2.2 (zelfs voor 1.3 worden nog patches uitgebracht, die is al 15 jaar op de markt).

Of de major distro's hier ook zo over denken is een ander verhaal, maar ook hier zit je de eerste jaren nog wel goed met 2.2

[hostname]

Ik verwacht eigenlijk gewoon dat Apache 2.4 nog in Wheezy (Debian 7.0) meekomt. De freeze staat ergens in juni gepland, dus ze hebben nog ongeveer 4 maanden. Een van de maintainers van Apache in Debian geeft ook al aan te hopen dat hij halverwege April in Sid komt, dus dan moet Wheezy zeker lukken.

Verder weet ik ook niet waar je vandaan haalt dat GNOME 3.4 de laatste grote wijziging zal zijn. Er zijn nog zat zgn. transitions die lopen of gepland zijn. Daarnaast is het zo dat er tot de freeze nog grote wijzigingen gedaan worden. Pas vanaf de freeze worden grote changes geweigerd.

Waarschijnlijk is dan 12.10 de eerste Ubuntu versie waar hij in zit. Voor 12.04 is het al veel te laat, en als hij zoals gepland in April Debian haalt, dan wordt hij automatisch naar Ubuntu 12.10 gekopieerd.

[s.stok]

Dat verschild per distro, in de huidige Ubuntu LTS zou ik hem sowieso niet meer verwachten, deze houden ondersteuning voor de versie waarmee ze gebouwd zijn.

Debian, misschien in testing.

En voor de andere zoals Suse en Redhat zullen over een tijdje aparte RPM's komen.

[1993jjohan]

Het nieuwste is niet altijd het beste. ik zou op dit moment gewoon nog voor 2.3 kiezen. of zelfs lager. ik denk echter wel dat ik dit eens ga proberen op mijn testserver. maar zeker de komende maanden durf ik dit niet aan op een productie server. en waarom upgraden als 2.3 het nog prima naar verwachting doet.

als er een stuk software wel een update nodig heeft dan is het wel x11 server. die word door biljoenen gebruikt maar is al jaren oud.

[MadEgg]

Euh? De X11 server bestaat al jaren ja. Maar Windows ook... dat betekent niet dat er geen nieuwe versies uitkomen! Zeker sinds het forken van XFree86 naar X.Org ergens rond 2004 is de ontwikkeling in een stroomversnelling gekomen.

Perfect is de huidige versie zeker niet, maar ook niet 'al jaren oud'. De huidige stabiele versie, 7.6, is iets meer dan een jaar uitgekomen, december 2010, en heeft daarna nog kleine updates gehad. Vernieuwingen als Wayland zijn leuk, maar imo niet strikt noodzakelijk, X.Org doet zijn taak prima.

En natuurlijk ga je de nieuwste versie van je webserver software niet draaien op je productieomgeving. Er zijn ook jaren over de overstap van Apache 1.x naar 2.x gegaan. Nu was dat een iets grotere overstap, maar met nieuwe major versies van software is het altijd verstandig de kat even uit de boom te kijken. Behalve met Firefox tegenwoordig...

[s.stok]

Apache 2.3 is een testuitgaven!

Alle even versies zoals 2.2, 2.4 en 2.6. zijn stabiel.
Oneven versies zijn bedoeld voor het testen en uiteindelijk uitgeven als even versienummer.

http://httpd.apache.org/dev/release.html

With the introduction of Apache 2.1, the Apache httpd project has adopted an odd-even release strategy, where development happens with alpha and beta releases assigned an odd-numbered minor version, and its general availability (stable) release is designed with the subsequent even-numbered minor version. E.g. 2.1.0-alpha through 2.1.6-alpha were followed by 2.1.7-beta through 2.1.9 beta, and cumulated in the 2.2.0 general availability release.

[zeduude]

ah da's nou goed nieuws,
maarreh naast backports voor oudere distro's ( ok, compileren from scratch is vervelend, maar iig mogelijk, hoop ik dan ) en de nodige bugs en lekken afwachten, tot die tijd blijven nginx en apache 2.2 gewoon doordraaien

[MMaI]

compileren op CentOS 6 mislukt door ontbrekende dependencies, ik denk als je nu al wil beginnen met testen dat je bij FC16 of 17 moet zijn.

[Verwijderd]

Dat het jou niet lukt om te compileren wil niet zeggen dat het niemand lukt...
Ik zal je een tip geven: Apache HTTP leunt stevig op de Apache Portable Runtime. Daar is pas ook een nieuwe versie van gereleaset, en die is wat nieuwer dan de met CentOS 6.2 meegeleverde versie.

[Verwijderd]

Uiteraard staat dit nieuwsitem ook in de Meuktracker: meuk: Apache 2.4

[GWTommy]

Ik draai Direct Admin. Is er informatie bekend over een Direct Admin update die Apache update naar 2.4.1?
Is het verstandig om nu al te updaten of eerst afwachten of er iets uit komt mbt stabiliteit of veiligheid?

[AugmentoR]

Je mag aannemen dat serieuze partijen nog wel even de kat uit de boom kijken. Maar als het een testserver is kun je wel een kijkje nemen natuurlijk. Stel jezelf eerst de vraag: heb ik die extra functionaliteit nodig want veiliger zal het vooralsnog niet zijn.