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)
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 woensdag 22 februari 2012 14:15]
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.
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.
Ik vind het nu niet een bepaald gemis in Apache.
[Reactie gewijzigd door simplicidad op woensdag 22 februari 2012 14:17]
En da's nou precies wat ik bedoel, voor dat soort dingen moet je direct naar andere webservers.
Je hebt er plugins voor zie link hieronder
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/
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 woensdag 22 februari 2012 16:04]
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
Geef mij maar lekker apache
Ik vind deze website top, laat zien dat ze alleen bezig met het ontwikkelen van de code 
kennelijk heb je niet zoveel page views/s...
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.
Uiteraard staat dit nieuwsitem ook in de Meuktracker: meuk: Apache 2.4
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
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
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.
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.
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.
Mooie verbeteringen hoor!
Ben benieuwd wanneer deze versie in de distro's beschikbaar komt.
Ben benieuwd wanneer deze versie in de distro's beschikbaar komt.
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.
Debian, misschien in testing.
En voor de andere zoals Suse en Redhat zullen over een tijdje aparte RPM's komen.
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.
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..
voor mensen die de nieuwe features nodig hebben is dat TOCH geen probleem..
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.
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
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
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.
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.
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.
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.
Dus zeker een hoop moois.Per-request configuration sections
<If>, <ElseIf>, and <Else> sections can be used to set the configuration based on per-request criteria.
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
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
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.
Dus wat je zegt is onmogelijk, op iedere Unix.
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.
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.
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.
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.
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.
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.
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
Standaard ja en zonder threading door de MaxClients.Apache heeft er maximaal 256
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.
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 Incr.Badeend op woensdag 22 februari 2012 21:27]
Ok, mooi, een updateje. Maar welke is nu veiliger: Nginx of Apache? Da's veel belangrijker dan snelheid .
.De webserver die jij het beste instelt qua security, en waarvan je het beste weet hoe je die secure kan houden
Zaken als 'security by design' í.p.v. ''security by obscurity' bijvoorbeeld... Dat soort zaken lijken mij belangrijker .
Als het (grotendeels) af moet hangen van de user, dan klopt er naar mijn mening iets niet...
.Als het (grotendeels) af moet hangen van de user, dan klopt er naar mijn mening iets niet...
Als onwetende gebruiker is het eenvoudig de configuratie zo in te stellen dat de boel zo lek als een mandje wordt. Secure by design gaat je dan echt niet redden, je moet weten wat je doet.
[Reactie gewijzigd door arjankoole op donderdag 23 februari 2012 08:22]
Was er al IPv6 support of is dat er nu ook gekomen?
IPv6 support zit er al HEEL lang in
Die ondersteuning is er al sinds de 2.0 release z'n dikke 10 jaar geleden.
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.
Maar dit is een enorm goede stap in de goede richting, en ik hoop dat prefork en worker steeds minder gebruikt zullen worden.
hoezo is mpm-prefork langzaam? Ja, met statische images etc, maar qua php zal prefork sneller zijn dan wanneer je fcgi gebruikt icm php
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!
Deze nieuwe versie zal hopelijk ook statische requests goed kunnen doen. En deze versie heeft ook nog een nieuwe fastcgi-starter ingebakken!
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.
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.
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.
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 woensdag 22 februari 2012 21:52]
licht er natuurlijk ook aan hoe website gemaakt is dat scheelt ook al een stuk
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
