Google haalt bètalabel van Apache-module mod_pagespeed
Google heeft het bètalabel van de Apache-module mod_pagespeed verwijderd. Met mod_pagespeed worden webpagina's die de Apache-webserver serveert geoptimaliseerd waardoor het laden van webpagina's flink sneller zou gaan.
De optimalisatiemodule werd door Google met een opensource-licentie in november 2010 als bèta uitgebracht. Volgens de zoekgigant bevat mod_pagespeed meer dan veertig verschillende optimalisatiefilters voor webcontent. Zo wordt minification toegepast op javascript- en css-bestanden, kunnen afbeeldingen dynamisch geschaald en gecomprimeerd worden, en de cache lifetime kan per contenttype bepaald worden. Volgens Google zijn snelheidswinsten tot 50 procent mogelijk.
Inmiddels is de module in de ogen van Google na achttien releases voldoende gerijpt en is besloten om het bètalabel van mod_pagespeed te verwijderen. Volgens Google wordt de Apache-module al op meer dan 120.000 websites gebruikt en hebben ook grote hosters als GoDaddy en DreamHost gekozen voor implementatie van mod_pagespeed op hun webservers.
Google wijst er verder op dat de snelheid van een website een belangrijke rol is gaan spelen bij het bepalen van de ranking in zijn zoekmachine. Daarnaast poogt de zoekgigant webontwikkelaars met diverse tools over te halen om hun webservers zo snel mogelijk pagina's te laten serveren. In juli vorig jaar bracht Google ook een eigen content delivery network online. Daarbij worden deels dezelfde technieken gebruikt als die van de module page_speed.
Reacties (52)
Ik begrijp nooit helemaal hoe dit soort modules werken. Net als Apache search modules. Dit kan toch beter door een CMS zelf gedaan worden? Een database kan zoeken, een scriptje kan css comprimeren. Als een server dat gaat doen lijkt me dat om ongelukken vragen als het om cachen en dergelijke gaat. Wat als de content vernieuwd?
edit: dank voor jullie intelligente antwoorden! <3
edit: dank voor jullie intelligente antwoorden! <3
[Reactie gewijzigd door brabbelaar op vrijdag 12 oktober 2012 00:24]
Als het om JS en CSS gaat is dit meestal pas vernieuwd als het bestand daadwerkelijk is aangepast, er worden wel eens dynamische CSS stylesheets en Javascript aangemaakt, maar dit is volgens mij lang niet altijd het geval.
Het gaat hier ook om het automatisch schalen van foto's. Hoe weet die server hoe groot ze moeten zijn?
Css van een statische pagina is statisch. Maar verschillende pagina's kunnen om verschillende css bestanden vragen onder verschillende omstandigheden, hoe weet die server dat een pagina is aangepast of bij een bepaald template hoort?
Deze module moet toch samengaan met een module die hem met een cms integreert. Voor elk cms een eigen module...
Css van een statische pagina is statisch. Maar verschillende pagina's kunnen om verschillende css bestanden vragen onder verschillende omstandigheden, hoe weet die server dat een pagina is aangepast of bij een bepaald template hoort?
Deze module moet toch samengaan met een module die hem met een cms integreert. Voor elk cms een eigen module...
Nee hoor het werkt puur op basis van de te serveren output. Bv met dat plaatje encodeerd hij in de url de gewenste grootte aan de hand van de height / width attributes of css properties. Op de server wordt het dan geschaald naar die exacte grootte en die haal je dan op.
Volgens mij snap je het niet helemaal.
Een css bestand is toch altijd statisch? Tenzij je een css bestand natuurlijk dynamisch laat genereren, maar zover ik weet is er geen enkel cms wat dat doet.
Door naar de 'modified date' te kijken van een css bestand weet de extensie of het wel of niet is aangepast sinds de laatste keer.
Als de server een ander css bestand vraagt dan krijg je ook een ander css bestand geleverd.
Automatisch schalen van fotos zal niet altijd kunnen, maar als je in de html een tag hebt die aangeeft dat de foto als 200x200 pixels wordt weergegeven, en het bestand is 400x400 pixels, dan kan de server dat schalen om zo een kleiner bestand te hoeven sturen.
Een css bestand is toch altijd statisch? Tenzij je een css bestand natuurlijk dynamisch laat genereren, maar zover ik weet is er geen enkel cms wat dat doet.
Door naar de 'modified date' te kijken van een css bestand weet de extensie of het wel of niet is aangepast sinds de laatste keer.
Als de server een ander css bestand vraagt dan krijg je ook een ander css bestand geleverd.
Automatisch schalen van fotos zal niet altijd kunnen, maar als je in de html een tag hebt die aangeeft dat de foto als 200x200 pixels wordt weergegeven, en het bestand is 400x400 pixels, dan kan de server dat schalen om zo een kleiner bestand te hoeven sturen.
Dat lijkt mij sterk. Als jouw browser normaliter een pagina ophaalt, dan vraagt hij gewoon alle plaatjes op als resources.
Vervolgens gaat jouw browser ze plakken op de juiste plek op de hoogte/breedte wat jij hebt aangegeven, maar bij het ophalen van het plaatje geeft hij nergens aan hoe groot/breed hij hem eigenlijk wil hebben, dus dat kan apache nooit weten.
Of ze zouden in de html/css bestanden moeten loeren, maar dat lijkt mij zeer sterk.
Vervolgens gaat jouw browser ze plakken op de juiste plek op de hoogte/breedte wat jij hebt aangegeven, maar bij het ophalen van het plaatje geeft hij nergens aan hoe groot/breed hij hem eigenlijk wil hebben, dus dat kan apache nooit weten.
Of ze zouden in de html/css bestanden moeten loeren, maar dat lijkt mij zeer sterk.
En dat is dus exact wat deze module doet. Het is een filter in je webserver waar alle output doorheen gaat en als het om HTML gaat, dan gaat hij kijken om wat voor plaatje het gaat, wat de orginele grootte is en hoe groot hij in de pagina gebruikt gaat worden. Hij veranderd de url dan van /images/plaatje.jpg naar /images/plaatje.jpg?w=100&h=100&m=8999019021
(heel simpel weergegeven)
(heel simpel weergegeven)
[Reactie gewijzigd door StM op donderdag 11 oktober 2012 18:35]
Maar als de server het plaatje zelf moet gaan herschalen dan ben je toch je snelheidswinst kwijt?
Ja, eenmalig. Dit wordt namelijk gecached op de server.
Het schalen op de server kost CPU kracht. Het verzenden van meer data kost bandbreedte. Als de tijd die het herschalen kost kleiner is dan de tijd die je wint met de kortere bestand overdracht win je dus. Ook kan het geschaalde plaatje in een cache geplaatst worden zodat je het herschalen maar 1 keer hoeft te doen voor alle requests van die pagina.
Een eenmalige actie kan je dus een snelheidswinst bieden bij alle volgende requests van die pagina en uiteindelijk dus een grote winst opleveren in de belasting van je server.
Een eenmalige actie kan je dus een snelheidswinst bieden bij alle volgende requests van die pagina en uiteindelijk dus een grote winst opleveren in de belasting van je server.
Drupal kan volgens mij wel degelijk dynamisch css bestanden genereren. Deze worden weliswaar gecached zodat het niet telkens opnieuw gegenereerd hoeft te worden, maar dat maakt het niet minder dynamisch.
Tenzij dit CMS gebruikt maakt van LESS-CSSTenzij je een css bestand natuurlijk dynamisch laat genereren, maar zover ik weet is er geen enkel cms wat dat doet.
less wordt uitgestuurd als een apart content-type dus valt waarschijnlijk dan al buiten de boot.
Maar LESS is in principe niet dynamisch; als in, het wordt niet bij elk request opnieuw gegenereerd met andere content, zoals een webpagina dat vaak wel is (zoals deze pagina). LESS wordt gecompileerd naar CSS, maar zelfs als dat niet gedaan wordt (en in de browser naar CSS gecompileerd wordt) is het nog steeds een statische resource.
Er is geen enkele reden waarom een css-bestand statisch zou moeten zijn, het is net als html. Je zou aan de hand van browserdetectie andere CSS kunnen serveren, dat is conceptueel gezien logischer dan een andere html serveren, al blijft browserspecifieke code een slecht gebruik.
Mobiele site? Zelfde html, andere css. Waarom zou je de detectie daarvan in het html-genererende script doen?
Of je kunt ingelogde gebruiker / admins een andere CSS geven zodat ze herkennen dat/hoe ze ingelogd zijn.
Of een andere achtergrondkleur afhankelijk van het jaargetijde of de tijd van de dag
Eigenlijk is het heel simpel: wil je dynamisch iets aan de content van je site veranderen, dan doe je dat in html, wil je dynamisch iets aan de layout veranderen, zou je dat imiddels de css moeten doen.
Dat gezegd hebbende, werkt een cache niet alleen op basis van de url, dat zou inderdaad grote problemen geven. Ook post-requests en cookies tellen mee, anders zou je je forumpost niet terugzien, of pagina's van een andere gebruiker krijgen.
Scripts worden eigenlijk standaard nooit gecached, daar zul je de juiste headers aan mee moeten geven om die te laten cachen.
Mobiele site? Zelfde html, andere css. Waarom zou je de detectie daarvan in het html-genererende script doen?
Of je kunt ingelogde gebruiker / admins een andere CSS geven zodat ze herkennen dat/hoe ze ingelogd zijn.
Of een andere achtergrondkleur afhankelijk van het jaargetijde of de tijd van de dag
Eigenlijk is het heel simpel: wil je dynamisch iets aan de content van je site veranderen, dan doe je dat in html, wil je dynamisch iets aan de layout veranderen, zou je dat imiddels de css moeten doen.
Dat gezegd hebbende, werkt een cache niet alleen op basis van de url, dat zou inderdaad grote problemen geven. Ook post-requests en cookies tellen mee, anders zou je je forumpost niet terugzien, of pagina's van een andere gebruiker krijgen.
Scripts worden eigenlijk standaard nooit gecached, daar zul je de juiste headers aan mee moeten geven om die te laten cachen.
Dit werkt als een output filter. Bijvoorbeeld de css compressen doet hij door alle css urls er uit te filteren en deze te vervangen door een url in een speciale vorm die hij dan weer afvangt. In deze nieuwe url zit onder andere de laatste wijzigingsdatum / bestandshash verwerkt. Veranderd deze, dan veranderd ook de url en zal hij het dus ook weer opnieuw laden. Roep je deze url aan, dan laad hij vanuit een cache de gecompresde versie van je stylesheet. Doordat hij de url veranderd als hij bijgewerkt is kan je heel aggresief gaan cachen. En dit doet hij dus ook met JS en plaatjes.
Het grote voordeel is dat je om dit te laten werken geen ingrijpende aanpassingen hoeft door te voeren in je CMS. Het nadeel is echter dat het relatief veel CPU kracht kost, zeker als je er geen frontend cache als varnish voor hebt staan.
Het grote voordeel is dat je om dit te laten werken geen ingrijpende aanpassingen hoeft door te voeren in je CMS. Het nadeel is echter dat het relatief veel CPU kracht kost, zeker als je er geen frontend cache als varnish voor hebt staan.
[Reactie gewijzigd door StM op donderdag 11 oktober 2012 18:16]
Een web server als Apache weet altijd of content gewijzigd is.
Het is best wel handig als de webserver minification op javascripts toepast want dan hoef jij/CMS het niet te doen en dat heeft weer als voordeel dat je altijd het originele (voor een webmaster leesbare versie) van het javascript bestand gebruikt.
Het is best wel handig als de webserver minification op javascripts toepast want dan hoef jij/CMS het niet te doen en dat heeft weer als voordeel dat je altijd het originele (voor een webmaster leesbare versie) van het javascript bestand gebruikt.
Al dat minifyen is eigenlijk vrij zinloos. De http-compressie haalt de meeste lucht toch al uit de text-files en de persistent connections verminderen de overhead van het doen van meerdere request al.
Er wordt nu werk gestopt in een optimalisatie die nauwelijks iets oplevert.
Het enige voordeel is dat je je html/css/js rijkelijk kunt voorzien van commentaar zonder dat dat extra dataverkeer oplevert.
Maar al die optimalisaties vallen compleet in het niet bij het optimaliseren van images.
Er wordt nu werk gestopt in een optimalisatie die nauwelijks iets oplevert.
Het enige voordeel is dat je je html/css/js rijkelijk kunt voorzien van commentaar zonder dat dat extra dataverkeer oplevert.
Maar al die optimalisaties vallen compleet in het niet bij het optimaliseren van images.
Bijv. mod_deflate kan CSS gzipped over de lijn sturen als de browser aangeeft dat te ondersteunen. Maar de browser gaat die dan weer inflaten voordat hij hem parsed.
Bij minifyen blijft het bestand klein, en zou het parsen in theorie dus ook sneller moeten gaan en minder geheugen gebruiken.
Persistent connections zie je tegenwoordig steeds minder vaak gebruikt worden, omdat dit resources onnodig lang bezet houd.
Bij minifyen blijft het bestand klein, en zou het parsen in theorie dus ook sneller moeten gaan en minder geheugen gebruiken.
Persistent connections zie je tegenwoordig steeds minder vaak gebruikt worden, omdat dit resources onnodig lang bezet houd.
Niet waar. Minder input betekent ook minder zooi dat gecomprimeerd moet worden, dus een kleiner bestand. Pak een boek en comprimeer die, en vergelijk dat met het halve boek dat gecomprimeerd wordt.Al dat minifyen is eigenlijk vrij zinloos.
Iets wetenschappelijker: http://stackoverflow.com/questions/807119/gzip-versus-minify
Klinkt goed, had er nog nooit van gehoord.
Zitten er ook nadelen aan het gebruik van deze modificatie?
Zitten er ook nadelen aan het gebruik van deze modificatie?
Ja, het kost relatief veel CPU kracht omdat bij iedere dynamische pagina request de optimalisaties opnieuw uitgevoerd moeten worden. Statische requests cached hij wel zoveel mogelijk.
Het heeft wel enkele zinnige toevoegingen, maar het grootste deel van de laadtijden voor paginas zit hem tegenwoordig in externe sites, facebook like buttons, tweet buttons, advertenties, etc etc zijn meestal de grootste verslinders.
Daarnaast zijn de meeste van deze dingen ook op te vangen door gewoon een goed website design proces te hebben. Deze modules zijn vooral voor hosting bedrijven interessant waar de klanten weinig tot geen verstand van dit soort zaken hebben.
Daarnaast zijn de meeste van deze dingen ook op te vangen door gewoon een goed website design proces te hebben. Deze modules zijn vooral voor hosting bedrijven interessant waar de klanten weinig tot geen verstand van dit soort zaken hebben.
Belangrijke verschillen:Het heeft wel enkele zinnige toevoegingen, maar het grootste deel van de laadtijden voor paginas zit hem tegenwoordig in externe sites, facebook like buttons, tweet buttons, advertenties, etc etc zijn meestal de grootste verslinders.
* Deze scripts e.d. zijn door Facebook, Twitter e.d. belachelijk goed gecomprimeerd, en de servers waar ze op staan zijn aggresief ingesteld qua caching, dus in het grootste deel van de gevallen komen ze gewoon uit je cache.
* Deze scripts worden async ingeladen, dwz ze worden pas ingeladen als de pagina (= de content) ingeladen en weergegeven is.
Ze hebben invloed op de algemene snelheid van de pagina, maar niet zoveel als, bijvoorbeeld, ongecomprimeerde / slecht gecachte CSS van je eigen server af.
Wat heeft laadsnelheid nou weer te maken met de inhoud/relevantie van een webpagina?
Google wijst er verder op dat de snelheid van een website een belangrijke rol is gaan spelen bij het bepalen van de ranking in zijn zoekmachine. Daarnaast poogt de zoekgigant webontwikkelaars met diverse tools over te halen om hun webservers zo snel mogelijk pagina's te laten serveren. In juli vorig jaar bracht Google ook een eigen content delivery network online. Daarbij worden deels dezelfde technieken gebruikt als die van de module page_speed.
Google wijst er verder op dat de snelheid van een website een belangrijke rol is gaan spelen bij het bepalen van de ranking in zijn zoekmachine. Daarnaast poogt de zoekgigant webontwikkelaars met diverse tools over te halen om hun webservers zo snel mogelijk pagina's te laten serveren. In juli vorig jaar bracht Google ook een eigen content delivery network online. Daarbij worden deels dezelfde technieken gebruikt als die van de module page_speed.
Niets, maar wie zegt dat inhoud/relevantie de enige factoren zijn die een search ranking bepalen?
Als het een eeuwigheid duurt om die inhoud te laden, dan heb ik er niks aan en is die pagina dus niet relevant voor mij. Als twee pagina's een gelijke relevantie qua inhoud hebben, dan ga ik toch echt liever naar de pagina die het snelste is, dus die pagina moet ook hoger in de zoekresultaten staan.
In principe niets, maar ze hebben wel veel te maken met de usability en de 'indruk' die de gebruiker van die pagina heeft.Wat heeft laadsnelheid nou weer te maken met de inhoud/relevantie van een webpagina?
Google zijn belang in deze is ook eenvoudig: snellere paginas = meer pagina's bezocht in kortere tijd = meer ad impressies. Daarom hamert Google zo op snelheid, zowel in hun eigen rankings als de technologie die ze ontwikkelen (dit, SPDY, Chrome, etc). Voor Google is het win-win natuurlijk; meer pageviews (zoals aangegeven), en tegelijk goodwill omdat ze zich inzetten voor een beter internet.
Ik zou zeggen dat er voor google nog een belangrijkere reden is om mij naar snellere sites te sturen.
Als google mij naar snellere sites stuurt dan andere zoekmachines zal ik tevredenere zijn over google dan over andere zoekmachines.
Google wil mij naar de sites sturen waar ik blij mee ben, en er is al vaak aangetoond dat mensen als het gaat om het laden van sites extreem ongeduldig zijn.
Als google mij naar snellere sites stuurt dan andere zoekmachines zal ik tevredenere zijn over google dan over andere zoekmachines.
Google wil mij naar de sites sturen waar ik blij mee ben, en er is al vaak aangetoond dat mensen als het gaat om het laden van sites extreem ongeduldig zijn.
Is er ook een apache windows versie van deze module?
Niet met de inhoud of relevantie, wel met de ranking. Als je verschillende relevante sites hebt, dan komen de snelste eerst.
Deze module gebruik ik nu 16 maanden, vrijwel vanaf het begin. Ik zou niet meer zonder kunnen (en nee ik heb geen aandelen).
Door het gebruik van mod_pagespeed zijn mijn Google-rankings bovendien enorm omhoog geschoten.
Server 1:
WWW -> Varnish -> Apache + mod_pagespeed <-> PHP-FPM + APC + igbinary + Memcache
WWW -> Varnish (afbeeldingengedeelte) -> Nginx
Server 2:
WWW -> Varnish -> Apache + mod_pagespeed <-> PHP-FPM + APC + igbinary + Memcache
Via deze combinatie draai ik op een enkele VPS (3 * CPU, 3 GB RAM) een druk bezochte website met gemiddeld 120 hits per seconde. De server load is 0,02 ('s nachts) tot 0,06 (overdag).
De cache van mod_pagespeed heb ik op tmpfs gezet. APC heb ik ook op SHM gezet en Varnish draait ook vanuit Malloc. PHP-FPM benader ik niet via tcp maar via een .sock in /dev/shm.
Dit betekent dus, dat er GEEN schijfactiviteit is per bezoeker.
Dankzij mod_pagespeed draaien Wordpress- en Joomlasites gevoelsmatig dusdanig veel sneller dat het lijkt alsof de pagina vanaf localhost komt in plaats van vanaf een externe server.
Het enige wat merkbaar CPU-kracht kost is het rewrite_images filter van mod_pagespeed. Wanneer je dit inschakelt raad ik je aan om het maximale aantal gelijktijdige rewrites te beperken tot het aantal CPU-cores wat je ter beschikking hebt.
Overigens is Varnish essentieel. Anno 2012 zou geen enkele website NIET meer achter Varnish moeten zitten. Ik word met 1 website vrij vaak gelinkt vanaf GeenStijl en krijg dan pieken van 700 tot 900 hits per seconde op Varnish binnen. De server load gaat dan omhoog van 0,06 naar 0,08. Zonder Varnish zou dat bij 30 gelijktijdige bezoekers met mijn huidige content al een een load van 2.0 geven.
Dus mod_pagespeed gebruiken = ook Varnish gebruiken (en Varnish zo configureren dat hij ook daadwerkelijk cachet, dus cookies ermee van statische objecten verwijderen e.d.).
Overigens maakt het met Varnish ervoor weinig tot niets meer uit of je nginx of Apache gebruikt voor je statische content, wanneer je mod_pagespeed so instelt dat hij statische content direct vanaf het bestandssysteem leest (ReadFromFile).
Wanneer je "ThreadStackSize 192000" aan je Apache config toevoegt gaat hij ook nog eens bijna 200% efficiënter met je geheugengebruik om.
Door het gebruik van mod_pagespeed zijn mijn Google-rankings bovendien enorm omhoog geschoten.
Server 1:
WWW -> Varnish -> Apache + mod_pagespeed <-> PHP-FPM + APC + igbinary + Memcache
WWW -> Varnish (afbeeldingengedeelte) -> Nginx
Server 2:
WWW -> Varnish -> Apache + mod_pagespeed <-> PHP-FPM + APC + igbinary + Memcache
Via deze combinatie draai ik op een enkele VPS (3 * CPU, 3 GB RAM) een druk bezochte website met gemiddeld 120 hits per seconde. De server load is 0,02 ('s nachts) tot 0,06 (overdag).
De cache van mod_pagespeed heb ik op tmpfs gezet. APC heb ik ook op SHM gezet en Varnish draait ook vanuit Malloc. PHP-FPM benader ik niet via tcp maar via een .sock in /dev/shm.
Dit betekent dus, dat er GEEN schijfactiviteit is per bezoeker.
Dankzij mod_pagespeed draaien Wordpress- en Joomlasites gevoelsmatig dusdanig veel sneller dat het lijkt alsof de pagina vanaf localhost komt in plaats van vanaf een externe server.
Het enige wat merkbaar CPU-kracht kost is het rewrite_images filter van mod_pagespeed. Wanneer je dit inschakelt raad ik je aan om het maximale aantal gelijktijdige rewrites te beperken tot het aantal CPU-cores wat je ter beschikking hebt.
Overigens is Varnish essentieel. Anno 2012 zou geen enkele website NIET meer achter Varnish moeten zitten. Ik word met 1 website vrij vaak gelinkt vanaf GeenStijl en krijg dan pieken van 700 tot 900 hits per seconde op Varnish binnen. De server load gaat dan omhoog van 0,06 naar 0,08. Zonder Varnish zou dat bij 30 gelijktijdige bezoekers met mijn huidige content al een een load van 2.0 geven.
Dus mod_pagespeed gebruiken = ook Varnish gebruiken (en Varnish zo configureren dat hij ook daadwerkelijk cachet, dus cookies ermee van statische objecten verwijderen e.d.).
Overigens maakt het met Varnish ervoor weinig tot niets meer uit of je nginx of Apache gebruikt voor je statische content, wanneer je mod_pagespeed so instelt dat hij statische content direct vanaf het bestandssysteem leest (ReadFromFile).
Wanneer je "ThreadStackSize 192000" aan je Apache config toevoegt gaat hij ook nog eens bijna 200% efficiënter met je geheugengebruik om.
[Reactie gewijzigd door Hans van Eijsden op donderdag 11 oktober 2012 18:51]
Offtopic.
Bedankt voor deze nuttige informatie ! ik kende Varnish namelijk nog niet.
Ik zit alleen nog te twijfelen of ik nu apache of nginx ga gebruiken.
Het verschil is niet zo groot qua snelheid volgens mij, een van de voordelen van apache is dat het stabiel bewezen is (na al die jaren).
Nginx heeft op dit moment ook geen mod_pagespeed van google, wel een port.
Dus het zal voor mij denk ik ook de combinatie:
Varnish -> Apache + mod_pagespeed <-> PHP-FPM + APC + igbinary + Memcach worden.
Waar ik altijd wel bang voor ben is de volgende situatie:
- javascript.js gemaakt op 10 juni 2012 met een cache tot 10 juni 2013
Dan moet er toch iets geupdate worden op bijv. 13 aug 2012 aan javascript.js
Hoe forceer je dan dat de mensen die in de cache tot 10 juni 2013 hebben staan toch de laatste downloaden ?
Of luisteren alle browsers toch dan netjes naar de header: Last-Modified (10 juni 2013)
Bedankt voor deze nuttige informatie ! ik kende Varnish namelijk nog niet.
Ik zit alleen nog te twijfelen of ik nu apache of nginx ga gebruiken.
Het verschil is niet zo groot qua snelheid volgens mij, een van de voordelen van apache is dat het stabiel bewezen is (na al die jaren).
Nginx heeft op dit moment ook geen mod_pagespeed van google, wel een port.
Dus het zal voor mij denk ik ook de combinatie:
Varnish -> Apache + mod_pagespeed <-> PHP-FPM + APC + igbinary + Memcach worden.
Waar ik altijd wel bang voor ben is de volgende situatie:
- javascript.js gemaakt op 10 juni 2012 met een cache tot 10 juni 2013
Dan moet er toch iets geupdate worden op bijv. 13 aug 2012 aan javascript.js
Hoe forceer je dan dat de mensen die in de cache tot 10 juni 2013 hebben staan toch de laatste downloaden ?
Of luisteren alle browsers toch dan netjes naar de header: Last-Modified (10 juni 2013)
Als ik niet afhankelijk zou zijn van mod-pagespeed (lees: niet onder de indruk zou zijn van de verbeteringen) zou ik nginx gebruiken vanwege de lagere systeembelasting en beter geheugengebruik. Maar Apache 2.2 + mod-pagespeed geeft (zeker achter Varnish) een dusdanige verbetering in de gebruikerservaring vergeleken met nginx alleen, achter Varnish, dat het voor mij een no-brainer was om apache + mod-pagespeed in te zetten.
Apache 2.4 is nog beter, maar die dient nog vanaf source gecompileerd te worden omdat er nog geen (in mijn geval) Debian packages voor zijn.
Maar nginx heeft wel de toekomst, dus zodra daar een serieuze mod-pagespeed voor uit is zal ik rustig er volledig op overstappen.
Het forceren dat er een update is, doe je als ik het goed heb met ETag en gaat in de praktijk gewoon goed (volgens mij wordt er namelijk nog wel periodiek een stat gedaan).
Bij mij gaat alles automatisch goed (omdat ik mod-headers en mod-expires ook gebruik).
In ieder geval kun je altijd handmatig mod-pagespeed de cache laten legen:
sudo touch /var/mod_pagespeed/cache/cache.flush
Apache 2.4 is nog beter, maar die dient nog vanaf source gecompileerd te worden omdat er nog geen (in mijn geval) Debian packages voor zijn.
Maar nginx heeft wel de toekomst, dus zodra daar een serieuze mod-pagespeed voor uit is zal ik rustig er volledig op overstappen.
Het forceren dat er een update is, doe je als ik het goed heb met ETag en gaat in de praktijk gewoon goed (volgens mij wordt er namelijk nog wel periodiek een stat gedaan).
Bij mij gaat alles automatisch goed (omdat ik mod-headers en mod-expires ook gebruik).
In ieder geval kun je altijd handmatig mod-pagespeed de cache laten legen:
sudo touch /var/mod_pagespeed/cache/cache.flush
[Reactie gewijzigd door Hans van Eijsden op donderdag 11 oktober 2012 19:13]
Interesting...
waarom denk jij dat nginx 'de toekomst heeft'? Zijn de voordelen niet dingen die Apache ook zal gaan implementeren (noem het competitie)? Of zie je dermate grote verschillen dat dat niet mogelijk is?
waarom denk jij dat nginx 'de toekomst heeft'? Zijn de voordelen niet dingen die Apache ook zal gaan implementeren (noem het competitie)? Of zie je dermate grote verschillen dat dat niet mogelijk is?
Beide webservers hebben voor- en nadelen. Maar nginx heeft vanwege zijn asynchrone structuur een stabieler geheugenbeheer. Apache heeft hier van oudsher problemen mee, hoewel dit met de mpm-event die ik gebruik wel beter is geworden (die standaard is in 2.4 en optioneel in 2.2).
Maar nginx kan op een simpele VPS met 64 MB RAM en geen swap nog steeds honderden gelijktijdige requests dienen. Apache zal dit nooit kunnen halen vanwege de grotere footprint.
De redenen dat ik denk dat nginx "de toekomst" heeft, zijn er 2.
Nog een artikel waarom ik denk dat nginx zeker toekomst heeft: http://royal.pingdom.com/2011/12/01/interview-nginx-team/
Maar nginx kan op een simpele VPS met 64 MB RAM en geen swap nog steeds honderden gelijktijdige requests dienen. Apache zal dit nooit kunnen halen vanwege de grotere footprint.
De redenen dat ik denk dat nginx "de toekomst" heeft, zijn er 2.
- De stijgende lijn qua gebruik: steeds meer websites stappen over van Apache naar nginx
- De opkomst van de duurzaamheid en virtualisatie: besparingen op webservers, energiekosten, dit hangt direct samen met systeembelasting en efficiënt gebruik van resources.
Nog een artikel waarom ik denk dat nginx zeker toekomst heeft: http://royal.pingdom.com/2011/12/01/interview-nginx-team/
Wat ik voor dat soort situaties doe is javascript.js symlinken naar javascript_v2.js en in de HTML de nieuwe bestandsnaam gebruiken. Hierdoor zullen clients hun cache niet kunnen gebruiken en zo een nieuwe versie gebruiken. Eventueel kun je ook de last-modified date in de url gebruiken, iets als javascript.js?lm=2012_06_10 en die dus na een update vervangen door javascript.js?lm=2012_08_13. Door de gewijzigde request parameters in de HTML zullen clients de content opnieuw opvragen en zo dus wel de wijziging binnenkrijgen.
als het goed is doet RubyOnRails dit automatisch, best cool maar vind RubyOnRails verder vreselijk kwa syntax :3
Varnish wordt ook bij tweakers gebruikt zie: reviews: Tweakers.net-serverbeheer: Phoenix
Javascripts zou ik idealiter gecombineerd en minified aanbieden met de versie in de bestandsnaam. Zeker als je een fatsoenlijk buildproces gebruikt is dat goed te doen. Je serveert iedereen dan APPv331.js en na je update APPv332.js. Je kan dat rustig een far future expiring header zetten omdat de browser hem toch opnieuw ophaald.
Javascripts zou ik idealiter gecombineerd en minified aanbieden met de versie in de bestandsnaam. Zeker als je een fatsoenlijk buildproces gebruikt is dat goed te doen. Je serveert iedereen dan APPv331.js en na je update APPv332.js. Je kan dat rustig een far future expiring header zetten omdat de browser hem toch opnieuw ophaald.
Ik vraag me altijd af bij software die minimized of het niet zinvoller om simpelweg HTTP compressie in te schakelen, als je dit combineert met varnish heb je in principe geen behoefte meer aan extra 'optimalisaties' aangezien de output toch al gecached is door varnish.
Is er dan nog wel behoefte voor fpm, apc, igbinary,memcached als je het probleem toch al in varnish aanpakt?
Is er dan nog wel behoefte voor fpm, apc, igbinary,memcached als je het probleem toch al in varnish aanpakt?
Natuurlijk wel. Varnish cached alleen de statische output van requests die aan je Varnish regels voldoen. In een moderne website veranderd veel content regelmatig. Wij cachen bijvoorbeeld thumbnails en andere statische assets gedurende een maand, maar cachen de meeste HTML slechts 60 seconden. Veel sites moeten elke pagina voor elke bezoeker opnieuw opbouwen en kunnen dus alleen bepaalde segmenten cachen.
Het initiële genereren van de output kost gewoon nog wel tijd, net zoals het genereren van de output die niet gecached kan worden. Dit kun je versnellen door allereerst fatsoenlijk programmeren, en door gebruik van bijv. APC, ifbinary en memcached.
FPM helpt vooral in het reduceren van geheugengebruik, door de Apache processen lichter te maken en door meer resources te delen tussen requests. Als geheugen je bottleneck was kan dit je de ruimte geven om meer requests tegelijk te behandelen. Als je deze requests dan ook nog sneller kunt behandelen via bovenstaande methoden, dan heb je op twee vlakken winst geboekt.
Het initiële genereren van de output kost gewoon nog wel tijd, net zoals het genereren van de output die niet gecached kan worden. Dit kun je versnellen door allereerst fatsoenlijk programmeren, en door gebruik van bijv. APC, ifbinary en memcached.
FPM helpt vooral in het reduceren van geheugengebruik, door de Apache processen lichter te maken en door meer resources te delen tussen requests. Als geheugen je bottleneck was kan dit je de ruimte geven om meer requests tegelijk te behandelen. Als je deze requests dan ook nog sneller kunt behandelen via bovenstaande methoden, dan heb je op twee vlakken winst geboekt.
Interessante post! Heb je ook overwogen om Hiphop-php te gebruiken? Dat zou je kunnen gebruiken ipv APC?
Wel overwogen, nog niet verder naar gekeken. Staat nu bovenaan mijn lijst, hartelijk dank! 
Mooie setup. Kunnen veel professionele setups nog een puntje aan zuigen
Maar ik denk niet dat dat je enig verschil zult merken als je mod_pagespeed nu zou uitschakelen, aangenomen dat je css/js vrij statisch is, omdat Varnish deze serveert en requests uberhaupt niet meer bij Apache aankomen.
Kun je dat testen, of weerleggen?
Maar ik denk niet dat dat je enig verschil zult merken als je mod_pagespeed nu zou uitschakelen, aangenomen dat je css/js vrij statisch is, omdat Varnish deze serveert en requests uberhaupt niet meer bij Apache aankomen.
Kun je dat testen, of weerleggen?
De module doet nog veel meer optimalisaties waar je anders nooit bij stil zou staan. Kijk maar eens in Chrome met de Yslow plugin. En schakel dan de module in. Alles ineens groen en Grade A!
Het doet veel meer dan CSS/JS. Kijk maar eens op http://modpagespeed.com voor een kleine greep uit de beschikbare filters.
Het doet veel meer dan CSS/JS. Kijk maar eens op http://modpagespeed.com voor een kleine greep uit de beschikbare filters.
Iemand ook ervaring hiermee icm https?
Gebruik zelf varnish + apache icm de pound reverse proxy voor https. Dus pound (https) -> varnish (http) -> apache. Voordeel hiervan is ten eerste dat het toevoegen van een https domein erg eenvoudig is en gebruik maakt van de normale vhost en vooral dat je het grote voordeel van een caching proxy als varnish behoudt.
Was wel ff wat gedoe met pagespeed, maar de 'trim_urls' filter zorgt ervoor dat er relatieve urls worden gebruikt voor zaken die herschreven worden en eea dus gewoon werkt. Geen idee of dit specifiek is voor mijn setup maar zou me niks verbazen als het op standaard apache + mod_ssl gelijk werkt.
Was wel ff wat gedoe met pagespeed, maar de 'trim_urls' filter zorgt ervoor dat er relatieve urls worden gebruikt voor zaken die herschreven worden en eea dus gewoon werkt. Geen idee of dit specifiek is voor mijn setup maar zou me niks verbazen als het op standaard apache + mod_ssl gelijk werkt.
Ik heb nooit meer iets teruggevonden van die Google CDN. Of bedoelen ze daarmee die dienst die bekende JS libraries zoals Jquery voor je host? Ik verwachtte eigenlijk een service waar je je eigen statisch content zoals images kon hosten.
Staat gewoon gelinked in dit artikel?
https://developers.google.com/speed/pagespeed/service
Is dus meer een proxy die je voor je eigen site hangt. Content die zij nog niet hebben halen ze van jouw server en cachen ze voor de volgende keer.
https://developers.google.com/speed/pagespeed/service
Is dus meer een proxy die je voor je eigen site hangt. Content die zij nog niet hebben halen ze van jouw server en cachen ze voor de volgende keer.
[Reactie gewijzigd door frickY op vrijdag 12 oktober 2012 09:29]
even een praktische vraag: is het een beetje makkelijk om dit op je apache webserver toe te voegen? gewoon mod downloaden, aanzetten en klaar? of is het configgen nog een heel gedoe?
het klinkt namelijk allemaal erg mooi, maar ik durf niet zo goed zitten er nog grote adders onder het gras?
het klinkt namelijk allemaal erg mooi, maar ik durf niet zo goed
zitten er nog grote adders onder het gras?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
