De OliNo.org website is recent veel sneller geworden. Om precies te zijn: meer dan 80x zo snel. Hoe dit komt kun je lezen in het volgende artikel…

Misschien hadden jullie het ook gemerkt. De afgelopen maanden is de OliNo.org website steeds trager geworden. Op de achtergrond zijn we druk bezig geweest om te oorzaak te vinden maar tot voor kort konden we geen technische verklaring vinden.

Voordat ik nu direct ga vertellen wat er aan de hand was eerst wat
meer achtergrond informatie over de techniek achter de OliNo.org website.

Dynamische website

Zoals je kunt zien is de OliNo.org website een heel dynamische website. Er worden continue nieuwe artikelen geplaatst, commentaar gegeven op bestaande artikelen, er wordt bijgehouden (tot op de minuut) wanneer artikelen geplaatst zijn, archieven bijgehouden, categorieën aangemaakt en ge-update, etc.. Al deze informatie komt uit een centrale database.

Database

Voor het opbouwen van deze dynamische web pagina’s gaat de web applicatie software elke keer de informatie ophalen uit de database en gebruikt deze informatie dan om hiermee een standaard HTML pagina te genereren.

Deze HTML pagina kan dan worden getoond aan de bezoeker van de website. Voor elke pagina worden er ongeveer 90 verzoeken, in technische termen SQL queries, verzonden naar de database. Het ophalen van deze informatie uit de database kost relatief veel tijd. Om een idee te krijgen, het tonen van een statische HTML pagina gaat ongeveer 100-1000 keer zo snel dan het genereren van een dynamische pagina op basis van gegevens uit de database.

Nu zou het jammer zijn als we dit opzoeken in database voor elke bezoeker moeten doen omdat de database informatie niet elke seconde veranderd. Met andere woorden, het grootste gedeelte van de tijd is de informatie in de database niet veranderd en zou je dus dezelfde informatie kunnen tonen bij verschillende bezoekers. Echter soms is (een deel) van de informatie wel veranderd en die wil je dan wel onmiddellijk tonen aan de bezoekers. Je kunt dit op lossen door gebruik te maken van slimme caching.

Slimme caching

Door het gebruik van een cache mechanisme kun je dynamische informatie toch op een snelle manier tonen aan de bezoekers. Een goed cache systeem is slim genoeg om te zien of de informatie die in de cache staat nog geldig is. Indien de informatie niet meer geldig is zal de software alsnog de nieuwste informatie uit de database halen en deze tonen. Tevens wordt de cache dan ge-update met deze nieuwe informatie. Bij het weer opnieuw ophalen van de pagina kan dan direct cache informatie getoond worden. Vaak is het zelfs zo dat een pagina maar gedeeltelijk ververst hoeft te worden Oftewel er hoeven maar een paar queries richting de database gestuurd te worden. Een slim cache systeem houdt ook rekening met gedeeltelijke pagina updates. Gelukkig maken wij voor de OliNo site gebruik van Typo. Typo is een gratis blogging engine op basis van het “Ruby on Rails” framework. En in dit Rails framework zit standaard zo’n slim caching mechanisme.

Technische details

Voor diegene die interesse hebben, hierbij de technische details van de achterliggende techniek van de OliNo.org website

Blogging applicatie	Typo
Web applicatie framework	Ruby on Rails
Database	MySQL
Web server front-end	Apache
Web server backend-end	Lighttpd
Operating system	FreeBSD
Internet provider	SoftNow
Datacenter	Frankfurt (Duitsland)
Internet backbone type	OC 48
Internet backbone bandbreedte	2.5 Gbps

Benchmarks

Om te kijken hoe traag de website is hebben we een eenvoudige benchmark uitgevoerd. Vanuit Linux kan dit heel simpel met het volgende commando (dit kun je thuis proberen) :

time wget http://www.olino.org

Hiermee meet je hoe lang het duurt voordat de hoofd pagina van de OliNo website gedownload wordt. Wat bleek. Dit was extreem langzaam. Het duurde tussen de 6-22 seconden! Ons vermoeden was dus juist. Dit soort getallen zijn volledig onacceptabel voor een website.

De oorzaak

Een hint die we hadden was het feit dat de site de afgelopen maanden steeds een beetje trager is geworden. In het begin was de snelheid van de website prima. Deze langzame vertraging kan twee oorzaken kunnen hebben:

• Het aantal bezoekers van de OliNo website is gestegen waardoor er steeds meer bandbreedte gebruikt wordt en de server zwaarder belast wordt.
• De hoeveelheid informatie op de OliNo website is toegenomen en hierdoor krijgt de database het steeds zwaarder als deze alle dynamische informatie gaat ophalen.

Zoals je uit de technische details kunt halen is de OliNo.org webserver aangesloten op een extreem snelle internet verbinding. Het kan dus geen tekort aan bandbreedte zijn.

Blijft over de server belasting. Deze is toegenomen doordat meer bezoekers (gelijktijdig) de pagina’s opvragen en omdat de hoeveelheid informatie in de database groter is geworden.

Maar juist hiervoor hadden we toch dat slimme cache mechanisme.
Het lijkt er dus op dat het caching mechanisme niet (goed) werkt.

Bij een nadere inspectie bleek dat de cache directorie leeg was! Dat kan natuurlijk nooit. De OliNo site wordt dagelijks door veel verschillende bezoekers bezocht en je zou dus verwachten dat er ook informatie in de cache hoort te staan.

De oorzaak bleek een klein foutje in de configuratie te zijn. De gebruiker waaronder de Rails applicatie draait had geen rechten op het filesysteem om in de ../tmp/cache directory zijn bestanden weg te schrijven. Hierdoor werd de applicatie gedwongen voor elke pagina opvraag 90 SQL queries af te vuren op de database. Dit geeft natuurlijk een extreme vertraging. Het rechtzetten van de permissies was met een simpel (unix) commando snel verholpen. En voila, de site is ineens veel sneller geworden.

Hoe snel?

Natuurlijk waren we benieuwd hoe de snel de OliNo.org website nu is.

 jeroena@eagle:~> time wget http://www.olino.org
 --21:45:24--  http://www.olino.org/
           => 'index.html.5'
 Resolving www.olino.org... 213.198.89.64
Connecting to www.olino.org|213.198.89.64|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

    [ <=>                                 ] 18,058        --.--K/s

21:45:24 (850.57 KB/s) - `index.html.5' saved [18058]

real    0m0.068s
user    0m0.004s
sys     0m0.000s

Het ophalen van een pagina duurt nu nog maar 0.068 sec. Deze simpele benchmark test laat zien dat de website meer dan 80x zo snel geworden is.

Conclusies:

• Een kleine configuratie foutje kan grote gevolgen hebben.
• Het slimme caching systeem in “Ruby on Rails” werkt geweldig.
• Vaker in de logfile kijken kan veel problemen voorkomen (zie comments).