nederlands

Drupal en de kunst van snelheid

dit artikel is als gast blog verschenen op true.nl/blog

De meeste bedrijven die een website online hebben, hebben als doel om er geld mee te verdienen. Voor sommige websites is dat een directe manier van geld verdienen, omdat ze een webshop hebben, donaties verkrijgen of leadgeneratie hebben. En voor vele bedrijven is het een vorm van marketing, om gevonden te worden door hun prospects. Webperformance is dus niet een technisch trucje, maar een must voor een ieder. Als je geld verdient online, verlies je dat door een langzame website!

Snelle website

Content Management Systemen als Drupal zijn geweldig voor een gebruiker, zowel de redacteur als de bezoeker kan eenvoudig content toevoegen. Plaatjes worden automatisch geschaald en de tienduizenden modules leveren vaak de gevraagde functionaliteit. Maar dat komt met een prijs, ook in opensourceland. Voor elke pagina die het systeem samenstelt, moet de inhoud uit de database gehaald worden. Elke pagina die overzichtslijsten heeft (views) is een query naar de database. Elke pagina van een grotere website kan zo al snel honderden queries bevatten, enkel om een enkele pagina aan een enkele gebruiker te serveren. En dus ook met een snelle database vele seconden om de pagina aan de gebruiker te leveren. Een statische HTML-pagina serveren, is vele malen sneller.

Snelheid is de som van alle elementen

Dus aan de ene kant wil de business flexibiliteit om met een CMS content te kunnen veranderen. En aan de andere kant is het een eis dat een pagina binnen enkele seconden bij de gebruiker op het scherm staat. Om dit probleem op te lossen, is er niet een enkele actie die je kunt doen. Snelheid is de som van alle elementen tussen content en browser, de oplossing raakt dus ook alle elementen in deze keten; netwerk, operating systeem, het CMS, http en HTML. De enige oplossing om de performance te verbeteren van elke website – ongeacht het CMS – is dan ook er voor te zorgen dat de gehele keten wordt geanalyseerd en verbeterd waar noodzakelijk.

CSS en JS aggregate

Voor Drupal geldt dat het natuurlijk standaard is dat je CSS en JS aggregate gebruikt, hierdoor worden de tientallen CSS- en Javascript-bestanden samengevoegd en geminimaliseerd. Mooi. Tientallen minder hits is een aantal seconden sneller door een paar vinkjes. Maar nu begint het grijpen naar het hoger gelegen fruit. Hieronder staan enkel van de best practises, zoals deze geleerd zijn in de gemeenschap.

Minder hits

Vanuit de klant is het vaak gewenst om veel derde diensten te integreren, te meten met analystics en te delen via share this en a/b testing met Optimizely. Allemaal valide, maar elk Javascript-bestand is een extra DNS-request, een extra hit en extra parsing aan de browserzijde. Probeer de klant te overtuigen dat minder hits beter is Deze stap is waarschijnlijk het ingewikkeldste te realiseren, maar wel een die van belang is.

Caching in Drupal

Standaard heeft een CMS als Drupal caching staan in de database, het verste weg van de gebruiker vandaan. Dus alles wat deze caching kan verbeteren, is noodzakelijk. Dit kan door views en blokken te cachen.

Memcache en Varnish

Maar het verder ‘naar voren brengen’ van de cache, zodat deze niet in de database komt of zelfs Drupal ‘raakt’, is nog beter. Memcache is een goede methode, een platte tabel in het geheugen die direct door de webserver geraadpleegd wordt en waarvoor een Drupal module bestaat. Nog beter is het om Varnish te gebruiken, een reverse proxy, waardoor de verzoek nooit bij het CMS komt, maar direct geserveerd wordt. Dit werkt echter enkel voor niet ingelogde gebruikers en wil je in het CMS meten hoe vaak een artikel gelezen is in Drupal dan moet je hier dus omheen werken met een extra Javascript-call bijvoorbeeld. Typisch kan je met Varnish honderden keren meer gelijktijdig bezoek verwerken, terwijl het maken van de ‘index,html’-pagina onder deze druk van seconden naar 20 milliseconde gaat.

SSL-decrypter

Om er voor te zorgen dat de content zo ‘vers’ mogelijk blijft, dien je de expiratie-headers in de webserver zo te zetten dat de caching lang genoeg is, zonder dat de site gedateerd wordt en kan je de purge-module gebruiken. Je doet er goed aan om in de headers van de site te controleren dat het verzoek ook daadwerkelijk gecachet wordt en uit Varnish geserveerd wordt. Sommige modules en maatwerk willen dit nog wel eens voorkomen. Als jouw website https gebruikt, kan deze niet door Varnish gecachet worden. Hiervoor kan je een SSL-decrypter gebruiken voor Varnish, bijvoorbeeld pound, zodat Varnish toch gewoon http-verkeer ziet.

Zoekfunctionaliteit

Als de website een zoekfunctionaliteit heeft en je deze eigenlijk wil uitbreiden naar zoeken in binaire bestanden (PDF, MS-Word etc), neem dan een extra virtuele server met SOLR, installeer de module. En meest van belang, zorg dat de interne search de content niet meer indexeert, want de searchtabel is vaak de helft van de omvang van de database.

SPDY

Als je https gebruikt, denk dan ook aan de optie SPDY te gebruiken, de opvolger van het oude stateless http-protocol en de kandidaat voor http/2.0. Talloze browsers ondersteunen dit protocol al. Met SPDY worden de elementen van de pagina in een keer in een request gecomprimeerd geserveerd en dit kan zeker bij netwerken met een hoge latency het laden van een pagina halveren. Voor vele webservers (waaronder Apache en Nginx) zijn modules voor SPDY beschikbaar. Als dit nog geen optie is, kan je kijken naar de Google module ‘pagespeed’. Deze beschikt over een keur van opties; on the fly Javascript en CSS in de HTML injecteren als dat sneller is, lazyloading van plaatjes ‘onder de vouw’, het genereren van sprites en talloze andere opties die je site aanzienlijk sneller kunnen maken.

CDN

Een CDN kan een oplossing zijn voor tal van problemen: DDoS-bescherming, lagere roundtrip-tijden voor internationale gebruikers, maar ook meerdere requests serieel doen om de site sneller te laden. Dit kan je ook doen, zonder een echt CDN te gebruiken. De meeste browsers hebben een laag maximum aan het aantal requests dat men een dergelijke tijd kan doen naar een enkele server. Dus voor een pagina met 40 plaatjes vuurt de browser bijvoorbeeld 16 requests op de webserver af en wordt het volgende request pas geplaatst als er een succesvol is verwerkt. Hiervoor zou men dus kunnen werken subdomainen, om de pagina voor example.com te serveren gebruikt men CNAMES als images1.example.com en images2.example.com en doet men round robin loadlbalancing over deze namen. Hierdoor kan de browser nu 16 requests naar images1 sturen en 16 naar images2 op het zelfde moment. Er is een Drupal-module die dit voor je doet en ook kan integreren met de grote echte CDN’s als Akamai. Deze truc heeft enkele nadelen, je moet voorkomen dat searchengines images1.example.com gaan indexeren en er is een tradeoff omdat een extra DNS-request ook tijd vergt. Daarbij zal in de toekomst mede door SPDY deze techniek snel overbodig zijn.

Tips op servergebied

Op het gebied van de server zelf zijn er ook tal van tips van toepassing, al is dit verre van laaghangend fruit. Door bijvoorbeeld het renderbare deel van de pagina binnen de 1400 bytes te houden, kun je ervoor zorgen dat dit binnen een packet valt voor een ethernetverbinding. Het veranderen van de TCP slowstart-paramaters is een kernel hacking-ervaring, maar draagt ook bij aan een snellere website. Als gesteld, op elk gebied van business tot ethernet-frames dient men integraal webperformance te analyseren en verbeteren.

Meten van de snelheid

Er zijn vele tools die je kunnen helpen bij het meten van de snelheid en dit te verbeteren. Webpagetest en Yslow! zijn goede punten om te beginnen. Steve Souders is de autoriteit op dit gebied wereldwijd en zijn blog heeft tal van goede aanknopingspunten, 2bits heeft veel Drupal-specifieke artikelen online.

Bert Boerland en de Icebucket Challenge

Hoe het voelt om als allerlaatste Nederlander genomineerd te worden voor de icebucketchallenge? Zie dat in deze video

Bodemllijn: Ik doneer aan Aaron Winbord (fund), een #drupal vriend die aan ALS lijdt. En ik nomineer Paus Franciscus, permier Mark Rutter en Koning Willem Alexander.

Vader en dochter, animatiefilm

Vader en Dochter (Father and Daughter) is oorspronkelijk een animatiefilm van Michael Dudok de Wit uit 2000. De film kreeg een groot aantal prijzen, waaronder de Oscar voor beste animatiefilm in 2001. In 2007 kreeg deze film een plek in de canon van de Nederlandse film. De film heeft bijzondere geluidseffecten.

Als papa die al 10 jaar "op een mooie pinksterdag" neuriet als ik met dochter (en zoon lief) aan lopen ben, geweldig!

RIP mama ( Anna Maria Catharina Christina Boerland Smit 1924 2014)

Mijn afscheidstekst uitgesproken op de crematie dienst:

Woord van Dank zegging


Er staat nu „woord van dank zegging” in het programma. Ik zeg het nog een keer om het goed te laten bezinken: „woord van dank zegging”.
Een cabaratier zou er een grap over kunnen maken. Woord van dank zegging.
Een priester, pastoor of dominee zou er een een preek over kunnen houden. Het Woord van dank zegging.
En een zoon, een zoon zou een „woord van dank zegging” kunnen zeggen.


Zussen, Familie. Ik wil dank zeggen. Dank.


Maar meer dan „dank” wil ik zeggen waarom ik dank wil zeggen.


Het menselijk brein is raar. We herinneren ons veel, soms te veel.


We betrekken tijd in deze herinnering. Het recente verleden krijgt daardoor extra invloed, extra gewicht in onze herinneringen over handelingen, gedachten en mensen.


En daardoor zijn onze herinneringen gekleurd door de tijd. Als een polaroid vergeelt de tijd, het recente verleden minder dan de historiek.
De polaroid van mama in Italia voor de Fiat 500 staat minder scherp dat de recente foto's van haar in de rolstoel.


Een voetbal trainer is zo goed als zijn laatste wedstrijd, niet als zijn seizoen.
Een verkoper zo goed als zijn laatste contract. Niet als zijn carrière.
Maar mama wil ik niet alleen herinneren als hoe ze hier nu ligt.
Ik wil mama niet alleen herinneren als de oudere dame die haar laatste jaren in Boerhaave werd verzorgd.


Ik wil mama herinneren als mijn moeder.
Mijn moeder die kopjes thee bracht als ik met mijn vrienden op zolder tenten bouwde.
Mijn moeder die mij elke woensdag met me naar de bieb in het naburige Vries fietste zodat ik haar voorliefde voor literatuur mocht proeven.
Mijn moeder die me op padvinderij bracht zodat ik weet waar „hudo” voor staat.
Mijn moeder die me de kansen gaf te worden wie ik ben.
Mijn moeder die het beste in mijn naar boven haalde.


Daarvoor wil ik dank zeggen.
Mama, dank

Een dag die in mijn geheugen zal blijven...

Meer foto's van de crematie en de mooste begraafplaats/crematorium van Nederland op flick.

Beste wel snel, 250 km per uur over de snelweg (mashup van open data op een google maps)


Vandaag kwam ik op bestwelsnel.nl, een eenvoudige mashup waarbij data van hoe snel mensen rijden geplot wordt op een google maps.

Op de uitleg pagina staat hoe men aan de data komt. En dat wist ik niet, het is gewoon open(bare) data.

Op meer dan 24.000 meetlocaties worden dag en nacht autosnelheden gemeten. De Nationale Databank Wegverkeersgegevens (NDW) stelt deze informatie beschikbaar als 'open data'. Nuttig voor het vermijden van files, maar het geeft ook inzicht in hoe hard er soms in Nederland gereden wordt.
De waarden op de kaart zijn gebaseerd op NDW meetgegevens over gemiddelde snelheden. Deze worden door lokale overheden en Rijkswaterstaat aan het NDW aangeleverd. De waarden worden meestal gemeten doormiddel van detectielussen. Een 'luspaar' waarbij twee detectielussen op bijvoorbeeld 2,5 meter van elkaar in het wegdek zijn geplaatst kan de voertuigsnelheid bepalen door het tijdverschil tussen detectie op de twee lussen te meten.
Wanneer er in een minuut over een luspaar op een rijstrook maar een enkele auto of motor rijdt, zal dit door het meetstation gemeld worden als:

gemiddelde snelheid: 175km/h aantal voertuigen: 1
Dit zijn de metingen waarmee bestwelsnel.nl werkt.

Meer informatie over de data kan je vinden op NDW.

XML feed