Ontwikkelen van een nieuwe site voor de standaard & onderzoek naar het opzetten van een distributed cache

ONTWIKKELEN VAN EEN NIEUWE SITE
VOOR DE STANDAARD
&
ONDERZOEK NAAR HET OPZETTEN VAN
EEN DISTRIBUTED CACHE
Niels Timmermans
STAGERAPPORT
PROF. BACH.ICT 3

Stagerapport 2
Kaho St. Lieven 2013 | Opleiding Elektronica-ICT richting ICT

Stagerapport 3
STAGEGEGEVENS
Stagiair: Niels Timmermans
Opleiding: Professionele Bachelor Elektronica-ICT afstudeerrichting ICT
Academiejaar: 2012 – 2013
Stageperiode: Van 14/02/2013 tot 23/05/2013
Stagebegeleider: Knockaert Sven
Stageplaats: CORELIO
A.Gossetlaan 30
1702 Groot-Bijgaarden
02 467 25 08
Mentor: Vandevyvere Martijn

Stagerapport 4
SAMENVATTING
In het kader van mijn opleiding liep ik gedurende 3 maanden stage op het Digital Competence Center
van Corelio. Hier worden technologische vernieuwingen aangaande De Standaard, Het Nieuwsblad, …
gerealiseerd.
De opdracht die ik tijdens deze stage uitvoerde bestond uit twee delen. Enerzijds het uitwerken van
een aantal features van de nieuwe site van De Standaard en anderzijds het uitvoeren van een
onderzoek naar het opzetten van een distributed cache binnen De Standaard.
Tijdens het eerste luik van de stage ontwikkelde ik een tagoverzichtspagina. Op deze pagina worden
alle tags die binnen De Standaard worden gebruikt weergegeven.
Daarnaast werkte ik het onderdeel rond auteursprofielen uit. Ik ontwikkelde een pagina waar de
auteursinformatie en diens artikels worden weergegeven. Ook zorgde ik ervoor dat op de
detailpagina van een artikel een lijst van de auteurs onder de inhoud van het artikel wordt getoond.
Ook werkte ik een archief uit waar alle artikels op datum kunnen worden opgevraagd. Dit met het
oog op Search Engine Optimization zodat alle artikels door zoekmachines geïndexeerd kunnen
worden.
Een laatste onderdeel dat ik uitwerkte was het beursgedeelte binnen de nieuwe site. Ik ontwikkelde
een service die alle data aan de applicatie aanbiedt. Vervolgens werkte ik ook de beurspagina’s uit en
ontwikkelde ik verscheidene widgets die de service aanspreken.
Het tweede luik van de stage bestond uit het uitvoeren van een onderzoek naar het opzetten van
een distributed cache. Een distributed cache is het abstraheren van de caching uit de applicatie in
een logische laag die uit verschillende servers bestaat.
Tijdens dit onderzoek vergeleek ik deze manier van caching met de traditionele manier. Daarnaast
zocht ik welke mogelijkheden er zijn om deze cache op te zetten en ook welke technologieën er
hiervoor bestaan. Deze technologieën werden getest en met elkaar vergeleken.
Met deze stage werd mij een unieke kans geboden om mee te werken aan de ontwikkeling van één
van de grootste sites binnen België. Door de omvang van de applicatie leerde ik omgaan met
problemen i.v.m. schaalbaarheid en performantie. Op zeer korte tijd leerde ik zeer veel bij en
verwierf verschillende competenties die mij met een voldaan gevoel doen terugblikken op deze
stage.

Stagerapport 5
WOORD VOORAF
Mijn grote dank gaat uit naar Martijn Vandevyvere die me de kans gaf stage te lopen bij Corelio. Aan
het begin van de stage gaf hij me de kans om mee te werken aan het project om een nieuwe site
voor De Standaard te bouwen. Gedurende de hele stage stond hij klaar om al mijn vragen te
beantwoorden en mij zijn kennis over te dragen.
Daarnaast wil ik ook prof. Sven Knockaert bedanken om mij gedurende mijn stage te begeleiden en
mijn stageverslag te controleren.
Ten slotte gaat mijn dank ook uit naar alle collega’s bij Corelio. Gedurende 3 maanden heb ik de eer
gehad met hen te mogen samenwerken en veel van hen te mogen opsteken. In het bijzonder gaat
mijn dank uit naar Jan Kinable en Geoffrey Samper om mij hun kennis over te dragen en bij te staan
gedurende mijn stage. Ook wil ik Thomas Van den Bossche speciaal bedanken voor de aangename
samenwerking tijdens het uitwerken van het beursgedeelte van de nieuwe site.

Stagerapport 6
INHOUD
Stagegegevens......................................................................................................................................... 3
Samenvatting........................................................................................................................................... 4
Woord vooraf .......................................................................................................................................... 5
Inhoud ..................................................................................................................................................... 6
Lijst met gebruikte afkortingen............................................................................................................... 8
1 Voorstelling van het stagebedrijf..................................................................................................... 9
1.1 Onstaan en geschiedenis......................................................................................................... 9
1.2 DCC vs. ICT............................................................................................................................... 9
1.3 Merken .................................................................................................................................... 9
2 Stageopdracht................................................................................................................................ 10
2.1 Tagsoverzicht......................................................................................................................... 10
2.2 Profielen ................................................................................................................................ 10
2.3 Archief ................................................................................................................................... 10
2.4 Biz .......................................................................................................................................... 11
2.5 Distributed Cache Research .................................................................................................. 11
3 Actieplan ........................................................................................................................................ 12
4 Voorstudie...................................................................................................................................... 13
4.1 Distributed cache .................................................................................................................. 13
5 Praktische uitwerking..................................................................................................................... 32
5.1 Tagsoverzicht......................................................................................................................... 32
5.2 Profiel .................................................................................................................................... 36
5.3 Archief ................................................................................................................................... 41
5.4 Biz .......................................................................................................................................... 46
5.5 Distributed Cache.................................................................................................................. 62
Algemeen besluit................................................................................................................................... 97
Bibliografie ............................................................................................................................................ 98

Stagerapport 7
Bijlagen................................................................................................................................................ 102
1. Redis server scripts.................................................................................................................. 102
2. Distributed Cache Benchmarks ............................................................................................... 109

Stagerapport 8
LIJST MET GEBRUIKTE AFKORTINGEN
ACID Atomic Consistency Isolated Durability
BIZ Beursnieuws
DCC Digital Competence Center
DDD Domain Driven Design
DRY Don’t repeat yourself
DSO De Standaard Online
HA High Availability
HDD Hard disk drive
JS Javascript
OSI Open Systems Interconnection
POC Proof of Concept
REST Representational state transfer
SEO Search Engine Optimization
SPROC Stored Procedure
URL Uniform Resource Locator
VM Virtuele machine
VUM Vlaamse Uitgeversmaatschappij
XML Extensible Markup Language

Stagerapport 9
1 VOORSTELLING VAN HET STAGEBEDRIJF
1.1 ONSTAAN EN GESCHIEDENIS
Corelio werd in 2006 de naam van de Vlaamse Uitgeversmaatschappij nadat de groep Médiabel met
Les Editions de L’Avenir en Passe-Partout werd overgenomen en de VUM zo een nationale
mediagroep werd.
De VUM zelf ontstond in 1976 toen André Leysen de failliete Standaard Groep met Het Nieuwsblad,
De Standaard en De Gentenaar overnam. Diens zoon Thomas is sinds 2008 bestuursvoorzitter.
In 2011 nam Corelio samen met Sanoma en de top van De Vijver SBS Belgium, de overkoepelende
organisatie van toenmalige televisiezenders VT4 en VijfTv (nu VIER en VIJF), over.
1.2 DCC VS. ICT
Binnen Corelio zijn er twee IT-diensten. Enerzijds is er het DCC en anderzijds ICT.
ICT is de dienst die instaat voor het onderhoud van servers en dergelijke. Ook de service desk die
dient ter ondersteuning van andere organen binnen het bedrijf met betrekkingen tot infrastructurele
zaken vallen hieronder.
Daartegenover is het DCC de afdeling die instaat voor de realisatie van ideeën over technologische
vernieuwingen binnen de hele organisatie. Hieronder vallen bv. vernieuwingen van de verschillende
(mobiele) sites, integratie van externe services, ontwikkeling van tools voor de redacties, …
Het is op deze afdeling dat de stage zal doorgaan.
1.3 MERKEN
Figuur 1.3-1 Corelio logo's

Stagerapport 10
2 STAGEOPDRACHT
De stageopdracht bestaat uit twee grote delen. Enerzijds het implementeren van een aantal
vernieuwingen binnen DSO die opgesplitst kunnen worden onder:
 Tagsoverzicht
 Profielen
 Archief
 Biz
Bij dit deel van de stage zal ik meedraaien als lid van het SCRUM team dat verantwoordelijk is voor
de vernieuwing van DSO.
Anderzijds zal tijdens het tweede deel van de stage onderzoek worden gedaan naar het opzetten van
een Distributed Cache.
2.1 TAGSOVERZICHT
In opdracht van de traffic manager moet er een overzichtspagina van alle tags die gebruikt worden
binnen DSO worden gemaakt. Deze linken door naar de overzichtspagina van de tag zodat alle
tagoverzichtpagina’s geïndexeerd worden door zoekmachines (SEO).
Daarnaast dient er paginering voorzien te worden van zodra er meer dan 50 tags zijn.
2.2 PROFIELEN
Aan een artikel kunnen profielen (van de auteurs) gelinkt worden. Het is de bedoeling om een
overzichtspagina voor een profiel te maken met de informatie van de auteur en een lijst van diens
artikels.
Daarnaast moet er ook worden gezorgd dat op een artikeldetailpagina onder het artikel een lijst
komt van de profielen die aan het artikel gelinkt zijn. In de hoofding van het artikel wordt er gelinkt
naar de profielpagina indien er een profiel gekoppeld is aan het artikel.
2.3 ARCHIEF
Naar analogie van het tagsoverzicht moet er een indexeerbaar archief aangemaakt worden van alle
artikels die gebruikt worden binnen DSO met een link naar de detailpagina van een artikel (SEO).

Stagerapport 11
2.4 BIZ
In oude site van De Standaard bestaan de beurspagina’s uit iFrames van een externe site. Het is de
bedoeling dat dit herwerkt wordt zodat de beurspagina’s bestaan uit widgets die zelf beheerd
worden en hun data verkrijgen op basis van een eigen service.
2.5 DISTRIBUTED CACHE RESEARCH
Momenteel maakt elke webserver gebruik van zijn eigen lokale cache. Het is de bedoeling dat er
onderzoek wordt gedaan of een omschakeling naar een Distributed Cache zijn voordelen heeft t.o.v.
het huidige systeem en hoe dit systeem het best opgezet kan worden.

4 VOORSTUDIE
4.1 DISTRIBUTED CACHE
A distributed cache is an extension of the traditional concept of cache used in a single locale.
A distributed cache may span multiple servers so that it can grow in size and in transactional
capacity. It is mainly used to store application data residing in database and web session
data. [1]
Caching is een heel belangrijk aspect bij het ontwikkelen van applicaties. Het zorgt ervoor dat data
sneller toegankelijk is en dat mogelijke bottlenecks onderuit worden gehaald. Een distributed cache
gaat hierin nog een stapje verder. Daar waar bij traditionele caching alle servers hun eigen lokale
cache hebben, is een distributed cache een cachinglaag die verspreid wordt over en toegankelijk is
door verschillende servers.
4.1.1 WAAROM KIEZEN VOOR EEN DISTRIBUTED CACHE?
PERFORMANTIE
Bij het gebruiken van een lokale cache gaat iedere node zijn eigen cache opbouwen en onderhouden.
Het nadeel van deze structuur is dat dezelfde data door de verschillende servers wordt opgehaald en
opgeslagen. Hierdoor zal de onderliggende datastructuur meerdere malen worden aangesproken.
Deze onderliggende datastructuur kan bv. een database zijn, maar evengoed een externe service.
Wanneer deze onderliggende datastructuur hevig belast wordt, kan dit gevolgen hebben voor de
performantie van de hele applicatie. Op deze manier kan de caching een bottleneck zijn binnen de
applicatie.
SCHAALBAARHEID
Daarnaast ontstaat het probleem dat bij grote applicaties het gebruik van de lokale caches absoluut
niet schaalbaar is. Stel dat de cache uitgebreid moet worden, moet dit voor iedere server individueel
gebeuren. Daar waar bij een distributed cache dit maar één keer (of bij eventuele replicatie twee
keer) zal moeten gebeuren. En aangezien men over grootschalige applicaties spreekt is dit een niet te
verwaarlozen issue.
Men zegt dat een distributed cache horizontaal schaalbaar is (in de breedte) terwijl lokale caching
enkel verticaal schaalbaar is.
Daardoor zal de kost bij de uitbreiding van het geheugen van een lokale cache lineair toenemen in
functie van het aantal servers, terwijl bij een distributed cache de kost constant zal blijven.

Stagerapport 14
Figuur 4.1-1 Kost uitbreiding cache
AVAILABILITY
The ratio of (a) the total time a functional unit is capable of being used during a given interval
to (b) the length of the interval. [2]
Het bereiken van een zo hoog mogelijke availability of beschikbaarheid van een applicatie is één van
de grootste streefdoelen bij de ontwikkeling ervan. Het ultieme doel is natuurlijk dat een applicatie
altijd beschikbaar is, maar in de praktijk is dit echter niet in alle scenario’s mogelijk.
Bij een applicatie zoals een beursservice waar constant aandelen verhandeld worden, zouden bv. een
paar seconden downtime rampzalige gevolgen kunnen hebben. Algemeen wordt er gesproken over
de five nines waarbij gestreefd naar een availability ratio van 99,999%.
Figuur 4.1-2 HA [3]
Een distributed cache kan de availability van de applicatie positief beïnvloeden. Stel dat bij lokale
caching een webserver nadat deze down is geweest, terug opgestart wordt, dan zal deze zijn cache
terug opnieuw moeten opbouwen. Dit zorgt ervoor dat requests die op deze server terecht zullen
komen veel calls naar de onderliggende datastructuur zullen veroorzaken en zullen de requests
langer, mogelijks te lang, duren.
K
o
s
t
# Servers
Lokale caching
Distributed caching

Stagerapport 15
Een distributed cache kan dit probleem opvangen doordat er verschillende replicatie topologieën
mogelijk zijn wat redundantie waarborgt en kunnen er aparte caching servers gebruikt worden. Deze
replicatie topologieën worden later besproken.
DATACONSISTENTIE
Een ander probleem dat optreedt bij gescheiden caches is de synchronisatie van data. Aangezien
iedere node zijn eigen cache heeft, heeft deze geen weet van eventuele veranderingen van dezelfde
data in een andere cache wat in sommige gevallen cruciaal (ACID) is.
Bij lokale caching kan men dit probleem verhelpen door de verantwoordelijkheid hierover te
verschuiven naar applicatie zelf of de onderliggende datastructuur. Maar dit zou niet de
verantwoordelijkheid van deze mogen zijn. [4]
ISOLATION
Bij lokale caching zit de caching verweven in het geheugen van het proces van de applicatie. Het
voordeel hiervan is de caching zeer snel is omdat er geen vertaling moet gebeuren wanneer data
weggeschreven of opgehaald wordt uit de cache.
Het nadeel hiervan is dat het cachen van de objecten verweven zit met applicatie terwijl dit eigenlijk
een aparte laag is net zoals de datalaag.
Een concreet voorbeeld waarbij dit naarboven komt, is bij het analyseren van een geheugendump
van het proces in geval van een bug of probleem. Doordat de caching verweven zit in hetzelfde
proces zal deze geheugendump veel onnodige informatie bevatten wat de efficiëntie van het
debuggen en het nemen van snapshots naar beneden haalt.
Daarnaast is caching zoals eerder aangehaald niet de verantwoordelijkheid van een applicatie en zou
dit uit de applicatie geabstraheerd moeten worden, wat bij distributed cache wordt bewerkstelligd
door het creëren van een aparte caching layer.
Figuur 4.1-3 Layers
Application layer
Caching
Data

Stagerapport 16
Een bijkomend voordeel is dat aangezien de caching uit de applicatie getrokken is, deze ook door
andere applicaties en services benaderd kan worden. Denk maar een taskservice die indien er
wijzigingen gebeuren aan data op datalaag niveau, deze data meteen doorstuurt naar de caching
laag. Ook kunnen hieraan dan meteen enkele andere acties worden gekoppeld. Data kan ook
preventief ververst wordt zodat wanneer data in de cache vervalt, er geen cache miss optreedt met
bijhorende vertraging.
Bv. Stel dat een redacteur een artikel geschreven heeft, dan wordt dit automatisch in de cache
geladen en wordt ook de data van de meest recent gelezen artikels geüpdateted.
PRIMING
Primed Cache alleviates the problem of slow, incremental cache population exhibited by the
Demand Cache pattern. The primary difference is that a primed cache explicitly populates the
cache with an anticipated subset of data before making any database requests. A single
comprehensive query primes the cache with a single, relevant set of data that the application
is likely to reference. Most of the time this single query is much faster than the sum of the
smaller queries requires to populate the cache on demand. [5]
Doordat een distributed cache geïsoleerd is van een applicatie kunnen aparte services de cache
proactief gaan vullen. Dit zorgt ervoor dat de hit rate bij de start van een applicatie meteen hoger ligt
en dus de performantie meteen een stuk hoger zal liggen.
Daarnaast kan men data die uit de cache verwijderd zou worden omwille van de expirationtime
preventief heringeladen worden.
TRANSLATION PENALTY
Zoals eerder aangehaald zit bij lokale caching de data verweven in het proces van de applicatie zelf.
Wanneer we echter de caching uit dit proces halen zal er een vertaling moeten gebeuren wanneer er
naar de cache geschreven of van de cache gelezen wordt.
Wanneer het gaat om objecten zullen deze ge(de)serialiseerd moeten worden wat meer CPU-kracht
zal vergen van de webservers. Daarnaast zal een upgrade van de applicatie mogelijks als gevolg
hebben dat de geserialiseerde gegevens niet langer compatibel zullen zijn met de nieuwe
datastructuren. Zeker in een omgeving waar men actieve updates wil doen zal dit een aanpassing
vragen van de manier waarop de applicatie ontwikkeld wordt.
NETWORK ROUNDTRIP PENALTY
Een bijkomend nadeel van een gedistribueerde cache is de network roundtrip penalty. Doordat de
cache verspreid zit over meerdere servers zal ook de data verspreid liggen over verschillende servers
en indien er data opgehaald wordt zal dit over het netwerk gebeuren.
Een mogelijke tweak hiervoor is een combinatie van lokale caching voor de frequently used data die
over alle servers synchroon worden gehouden, en de distributed cache.

Stagerapport 17
SAMENGEVAT
Distributed cache Lokale cache
Schaalbaarheid
Performantie
Availability
Ease of use
Translation penalty
Network roundtrip penalty
Tabel 4.1-1 Distributed cache vs lokale cache

Stagerapport 18
4.1.2 CLIENT-SERVER OPSTELLINGEN
Een distributed cache kan op verschillende manieren opgesteld worden. Deze verschillende
mogelijkheden zullen we overlopen en met elkaar vergelijken.
Onder client verstaan we hier een node die gebruikt maakt van de distributed cache. Onder server
verstaan we een node die onderdeel is van de cachecluster.
CLIENT = SERVER
De clients kunnen ook als server geconfigureerd worden. In het geval van een webapplicatie zullen
de webservers samen (of een deel ervan) de distributed cache vormen.
In deze situatie wordt de caching uit het applicatieproces getrokken en zal op de webservers ook een
proces draaien dat verantwoordelijk is voor de caching. Één van de voordelen om webservers ook als
caching servers te gebruiken is dat de network roundtrip penalty in deze situatie voor een deel
getackeld wordt aangezien een deel van de cache lokaal zal staan. Naarmate het aantal servers stijgt,
zal dit voordeel vervallen. Ook hoeven er geen aparte servers worden geïnstalleerd of onderhouden
worden aangezien web- en cacheservers dezelfde nodes zijn.
Figuur 4.1-4 Network roundtrip penalty (client = server)
Daartegenover zullen de webservers naast de webrequests ook moeten instaan voor het afhandelen
van cacherequests. Hou in deze situatie rekening dat wanneer data die zwaar belastend is voor de
applicatie op één server terecht, deze ook alle trafiek zal moeten kunnen verwerken. Mogelijke
oplossingen hiervoor zijn om deze cruciale en veelgebruikte data alsnog op iedere webserver lokaal
te cachen.
Men kan ook op applicatieniveau zelf regions gaan definiëren en vanuit de applicatie bepalen op
welke server welke data terecht komt. Al gaat dit resoluut in tegen het grote idee van een distributed
cache, namelijk de caching en diens organisatie uit de applicatie te gaan wegtrekken.
0
10
20
30
40
50
60
70
80
90
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
%
# Servers

Stagerapport 19
Een bijkomend nadeel is dat de structuur waarop de cache gebouwd is dezelfde moet zijn als die van
de webservers. Ik denk bijvoorbeeld aan een .NET applicatie waarvoor onderliggend Windows vereist
is. Dan zal de onderliggende cache ook op Windows gebaseerd moeten zijn.
Web Server
Web Application
Web Server
Web Application
Web Server
Web Application
persistent or non-persistent distributed cache
Figuur 4.1-5 Client = Server [6]
CLIENT != SERVER
In deze opstelling zullen er aparte nodes zijn die de distributed cache zullen vormen.
Bij deze opstelling bewerkstelligd men een strikte scheiding tussen de applicatie- en cachelaag
aangezien de nodes die verantwoordelijk zijn verschillen van diegene die verantwoordelijk zijn voor
het aanbieden van de applicatie.
Het grote voordeel dat deze opstelling biedt is dat de nodes specifiek kunnen worden
geoptimaliseerd voor hun gebruik. Zo kunnen de caching servers onderliggend op een platform

Stagerapport 20
draaien dat specifiek geconfigureerd is om te gaan cachen. Daarnaast opent dit ook mogelijkheden
om in het geval van bv. een .NET applicatie de caching te laten draaien op een Linux platform. Zo
sluiten we oplossingen die enkel voor Linux beschikbaar zijn niet uit. Vaak zijn deze opensource en
low cost oplossingen wat zijn voordelen heeft. Voorbeelden hiervan worden later besproken.
Één van de nadelen van deze opstelling is de network roundtrip penalty. Aangezien de caching op
andere servers staat zal er voor iedere call over het netwerk moeten worden gegaan. Hiermee zal
rekening moeten worden gehouden indien voor deze opstelling worden gekozen. Naarmate het
aantal servers stijgt zal dit nadeel ten opzichte van een opstelling waar client en server dezelfde zijn,
verminderen.
Figuur 4.1-6 Network roundtrip penalty (client != server)
Een bijkomend minpunt is dat er extra servers nodig zijn wat extra licentiekosten en onderhoud met
zich mee brengt. In het geval van opensource oplossingen kan het nadeel van de extra licentiekosten
vervallen. Daarnaast zullen de webservers in deze opstelling minder resources nodig hebben en
gedownscaled kunnen worden aangezien de verantwoordelijkheid voor de caching op deze vervalt.
0
10
20
30
40
50
60
70
80
90
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
%
# Servers

Stagerapport 21
Web Server
Web Application
Web Server
Web Application
Web Server
Web Application
Cache server Cache server
non-persistent distributed cache
Figuur 4.1-7 Client != Server [6]
HYBRIDE OPSTELLING
Het is ook mogelijk om voorgaande opstellingen te combineren. Er kan zelfs gekozen worden om de
distributed cache te combineren met de lokale cache.
Een belangrijk aspect waarmee rekening moet worden gehouden wanneer men voor zo een
opstelling kiest is de synchronisatie van de verschillende componenten van de cache.
Een mogelijke oplossing hiervoor is een master-slave opstelling waarbij de master de slaves gaat
aansturen en op deze manier de synchronisatie tussen de nodes gewaarborgd blijft.

Stagerapport 22
VERGELIJKING
Client = Server Client != Server Hybride
Isolation
Mogelijkheden
Moeilijkheid
Cost
Performantie
Tabel 4.1-2 Client-Server opstellingen

Stagerapport 23
4.1.3 SERVER TOPOLOGIEËN
Hoe de nodes onderling communiceren en hoe de data binnen de cache gestructureerd wordt kan op
verschillende manieren geconfigureerd worden.
De keuze voor welke configuratie er gekozen zal worden zal naargelang de context waarin de cache
gebruikt wordt verschillen. Deze zal afhankelijk zijn van de noden inzake snelheid en redundantie.
De testen zijn uitgevoerd door Alachisoft, het bedrijf achter NCache, waarbij remote clients de cache
cluster benaderden.
MIRRORED CACHE
Bij een Mirrored Cache bestaat de cache uit twee nodes (active/passive). Alle requests worden door
de actieve node verwerkt die deze wijzigingen doorsluist naar de passieve node. Als de actieve node
faalt, komt de passieve node actief en aangezien deze synchroon is met de falende node zal de
applicatie hiervan geen hinder ondervinden.
Het grote nadeel bij deze configuratie is dat deze niet horizontaal schaalbaar is wat ervoor zorgt dat
bij grootschalige applicaties niet voor deze topologie gekozen zal worden.
Figuur 4.1-8 Mirrored Cache Benchmarks [7]
Aangezien deze opstelling niet schaalbaar is, zijn de resultaten vrij straightforward.
REPLICATED CACHE
Een andere mogelijkheid is het opstellen van een Replicated Cache. Hierbij zullen alle nodes over
dezelfde data beschikken. Bij het toevoegen van nodes zal de totale geheugencapaciteit van de cache
dus niet toenemen.

Stagerapport 24
Figuur 4.1-9 Replicated Cache Benchmarks [7]
We zien dat naarmate er meerdere nodes aan de cluster worden toegevoegd, de leesperformantie
lineair stijgt. Aangezien de data over alle nodes gerepliceerd wordt, beschikken alle nodes over de
volledige data en kunnen bijgevolg alle nodes op alle calls antwoorden.
Daarnaast zien we dat de schrijfperformantie sterk daalt naarmate het aantal nodes toeneemt. Dit is
logisch want wanneer er iets wordt weggeschreven naar de cache moet deze wijziging ook bij de
andere nodes gedaan worden wat de duur van een schrijfoperatie verlengd.
PARTITIONED CACHE
Een Partitioned Cache is een cachestructuur waarbij iedere node een deel van de data bevat. Deze
data is dan enkel op die specifieke node beschikbaar en wordt niet gerepliceerd.
Het grote voordeel hiervan is dat wanneer er nodes toegevoegd worden aan de cluster de
lees/schrijfperformantie lineair stijgt. Daarnaast zorgt deze opstelling er ook voor dat de cluster
horizontaal schaalbaar is en dat als er een node wordt toegevoegd aan de cluster, de
geheugencapaciteit van de cache mee stijgt.
Het grote nadeel van deze opstelling is dat de data niet redundant opgeslagen wordt. Elk stukje data
is maar op één node beschikbaar dus wanneer er een node faalt, zal deze data opnieuw in de cache
moeten worden opgeslagen.

Stagerapport 25
Figuur 4.1-10 Partitioned Cache Benchmarks [7]
PARTITIONED-REPLICA CACHE
Een Partitioned-Replica Cache is eigenlijk een combinatie van de vorige twee opstellingen. Nodes
gaan zich gaan groeperen en samen verantwoordelijk zijn voor een deel van de data. Op die manier
wordt er redundantie gegarandeerd wordt, maar anderzijds ook de performantie van een Partitioned
Cache gaat overnemen.
Ook de schrijf acties blijven performant aangezien de replicatie tussen de nodes onderling
asynchroon gebeurd en niet sequentieel zoals bij een Replicated Cache aangezien de replica passief
is. Dit betekent dat de applicatie niet zal wachten tot de data naar de replica weggeschreven is, maar
dat dit asynchroon gebeurd.
Figuur 4.1-11 Partition-Replica Cache Benchmarks [7]
PARTITION-REPLICA (SYNC-REPLICATION)
Bij een Partition-Replica (Sync-Replication) cache zal bij het schrijven naar de cache de verwerking
naar de replica’s synchroon gebeuren. Dit wil zeggen dat de applicatie zal wachten tot de wijziging

Stagerapport 26
ook op de replica zijn weggeschreven. Dit zorgt ervoor dat de schrijfperformantie lager is dan bij de
Partitioned-Replica Cache aangezien dit daar asynchroon gebeurd.
Op de leesperformantie heeft dit geen invloed.
Figuur 4.1-12 Partition-Replica (Sync-Replica) Benchmarks [7]
MASTER-SLAVE
Daarnaast kan men ook opteren voor een master-slave topologie. Hierbij zorgt de master ervoor dat
de data wordt gerepliceerd naar de slaves. Indien de master zou falen kan één van de slaves deze rol
overnemen en kan de cache actief blijven ondanks het falen. Dit is soort van mirrored cache.
VERGELIJKING
Snelheid Redundantie
Mirrored Cache
Replicated Cache
Partitioned Cache
Partitioned-Replica Cache
Partition-Replica (Sync-Relation)
Master-slave
Tabel 4.1-3 Server topologieën

Stagerapport 27
4.1.4 VOORBEELDEN
REDIS
Redis is een opensource key-value store wat het uitermate geschikt maakt om te gebruiken als
cache. Het is vergelijkbaar met Memcached maar biedt ondersteuning voor replicatie (master-slave
topologie). Daarnaast heeft het een uitgebreidere featureset. Zo ondersteunt Redis om meerdere
datatypes op te slaan zoals sets en lists, en kan data in de cache op verschillende manieren
gemanipuleerd worden.
VOORDELEN
Het is een opensource oplossing die zeer performant is en uitermate geschikt om een distributed
cache mee op te zetten. Er is ook een port beschikbaar naar Windows die developers toelaat om in
een eenvoudige klik de cache lokaal op te zetten. Daarnaast is er ondersteuning om de cache
persistent te maken wat ervoor zorgt dat je nooit met cold cache zit bij een eventueel falende node.
NADELEN
Het nadeel van Redis is dat de versie die geschikt is voor productie op Linux draait wat in het geval
van .NET applicaties ervoor zorgt dat er aparte cacheservers moeten worden voorzien.
Daarnaast zijn er geen geïntegreerde monitoringtools.
REDIS KEYSPACE NOTIFICATIONS
Redis biedt ook ondersteuning voor notificaties via Redis Keyspace Notifications. Keyspace laat
clients toe om verbinding te maken met een kanaal waarlangs notificaties worden kunnen worden.
REDIS SENTINEL
Redis Sentinel is een service die Redis aanbiedt voor automatische failover van nodes. Deze service
wordt met Redis meegeleverd.
REDIS CLUSTER
Redis Cluster is een platform dat momenteel nog in bèta-fase is en verwacht wordt voor het derde
kwartaal van 2013. Dit platform moet ondersteuning bieden voor het opzetten van een Redis cluster.
MEMCACHED
Memcached is een opensource distributed cache systeem die data key-value opslaat. Het is een zeer
eenvoudig platform, maar daar staat een hoge performantie tegenover. Daarnaast is Memcached
cross-platform en is zijn API beschikbaar voor de meeste populaire talen.
VOORDELEN

Stagerapport 28
Voordelen van Memcached zijn dat het een opensource product is dat dus zelf naar eigen noden aan
te passen is en dus een low cost oplossing biedt bij het opzetten van een distributed cache.
NADELEN
Het grote nadeel aan Memcached is dat er standaard geen ondersteuning is voor replicatie of het
opzetten van een cluster.
REPCACHED
Repcached is een uitbreiding van Memcached waarbij replicatie wordt ondersteund. Hierbij bestaat
de cluster uit 2 nodes volgens een master-slave topologie.
MOXI
Moxi is een proxy voor een Memcached distributed cache om failover te voorzien. Deze vertraagt de
cache aanzienlijk.
COUCHBASE
Couchbase is een NoSQL database die ook als distributed cache kan worden opgezet. Het is een
makkelijk schaalbaar platform die een consistente hoge performantie garandeert. Naast de
uitgebreide featureset zijn er ook uitgebreide monitoringtools beschikbaar.
VOORDELEN
Couchbase is zeer makkelijk op te zetten en eenvoudig configureerbaar. Daarnaast biedt het ook een
uitgebreide featureset aan.
NADELEN
Aan al dit moois hangt een groot kostenplaatje.
NCACHE
NCache is een betalende oplossing voor het opzetten van een distributed cache. Het is extreem snel
en lineair schaalbaar met ondersteuning voor replicatie, failover en monitoring. Daarnaast biedt het
een diepgaande ondersteuning voor .NET applicaties. Volgende features zorgen hier o.a. voor:
 ASP.NET Session storage
 Entity Framework cache
 NHibernate L2 Cache

Stagerapport 29
Figuur 4.1-13 NCache Monitor [7]
VOORDELEN
Het voordelen van NCache zijn de uitgebreide featureset, hoge performantie en schaalbaarheid.
Daarnaast is het opzetten ervan zeer eenvoudig.
NADELEN
Aan al deze voordelen hangt natuurlijk een enorm kostenplaatje wat deze oplossing minder
aantrekkelijk maakt dan opensource oplossingen.
WINDOWS APPFABRIC
Windows AppFabric is een set technologieën die ontwikkeld zijn door Microsoft ter ondersteuning
van het bouwen en onderhouden van schaalbare webapplicaties. Één van deze technologieën is de
AppFabric Caching.
AppFabric Caching biedt de mogelijkheid om een Distributed Cache op te zetten. Hierin worden
objecten geserialiseerd opgeslagen. Het configureren en beheren van de AppFabric Caching kan via
Windows PowerShell.
Er zijn caching providers voorzien ter ondersteuning van ASP.NET applicaties voor sessions op te
slaan en ook voor output caching. Het aanspreken van de cache gaat via de Cache API.
VOORDELEN

Stagerapport 30
Windows AppFabric heeft als grote voordeel dat het ontwikkeld is door een grote speler als
Microsoft die de middelen heeft om dit uit de te bouwen tot een stabiel platform. Daarnaast biedt
het een nauwe interactie met bestaande technologieën van Microsoft zoals ASP.NET, Windows
Azure, Windows Server, …
NADELEN
De performantie van deze oplossing is beneden alle peil i.v.m. andere oplossingen.
VERGELIJKING
Snelheid Redundantie Kost
Windows AppFabric
Memcached
NCache
Couchbase
Redis
Tabel 4.1-4 Distributed cache voorbeelden

Stagerapport 31
4.1.5 CONCLUSIE
De kosten die de verschillende platformen met zich meebrengen liggen verspreid. Daar waar
opensource producten extra hardware vereisen doordat ze meestal op linux draaien, wegen de
licentiekosten van andere producten zwaar door.
Uit deze voorstudie lijkt Redis de meest geschikte kandidaat. Het is een opensource oplossing met
een uitgebreide featureset. De verschillende oplossingen zullen verderop uitgebreid getest worden.

Stagerapport 32
5 PRAKTISCHE UITWERKING
5.1 TAGSOVERZICHT
Een eerste opdracht is het maken van een tagsoverzicht voor de nieuwe site. Binnen DSO kunnen
tags aan artikels gekoppeld worden. Zo kunnen articlelistwidgets op basis van een tag worden
aangemaakt of zijn er tagoverzichtpagina’s.
Ter bevordering van SEO is het de bedoeling om een overzicht te maken waarin alle tags met links
naar hun tagoverzichtspagina worden weergegeven. Zo worden alle links bij het bezoek van een web
crawler geregistreerd.
5.1.1 OPDRACHT
 URL /tags
 Navigatie door een lijst van nummers/letters die bij het klikken naar een gefilterd overzicht
gaan
 Paginering wanneer er meer dan 50 tags zijn
 In het geval van paginering, moet er in vanaf pagina 2 volgende header worden toegevoegd:
<meta name="ROBOTS" content="NOINDEX,FOLLOW">
5.1.2 UITVOERING
Allereest werden de routes geregistreerd. Een route bepaalt welke url’s waar naar verwijzen.
Daarnaast werd ervoor gezorgd dat er in het backend systeem geen pagina’s konden worden
aangemaakt die verwezen naar deze routes.
Het ophalen van de tags gebeurt via een repository. Deze zal onderliggend kijken of de data
beschikbaar is in de cache en deze hieruit ophalen. Indien de data niet in de cache zit, zal de
repository de database aanspreken via een stored procedure. Het resultaat dat via een mapper
vertaald wordt op objecten, wordt vervolgens opgeslagen in de cache.
Figuur 5.1-1 Data flow
Application Repository
HttpRuntime
Cache
Stored
Procedue

Stagerapport 33
DATA
Bij het onderzoeken van de repository structuur werd al snel op een code smell gebotst. De
onderliggende structuur was zo opgezet dat aan iedere repository slechts één sproc gekoppeld kon
worden aangezien deze op klasseniveau gedefinieerd werd. Ook werd het type dat deze sproc terug
gaf verbonden met de repository klasse waardoor een repository slechts één type objecten terug kan
geven hoewel er voor eenzelfde entiteit meerdere datamodellen kunnen bestaan.
Deze code smell zorgde ervoor dat functionaliteit om data op te halen in de overervende klassen
herhaald werd, maar zonder dat deze gecached werden.
Vooraleer verder werd gegaan met het tagsoverzicht werd besloten om eerst de onderliggende
structuur voor de CachedEntityRepository klassen from scratch te herschrijven. Hierbij werden de
sprocs niet langer op klasseniveau bepaald, maar wel op methode niveau. Deze basisstructuur werd
herleid tot één generieke get methode die op basis van het returntype, een meegegeven
mappermethode en het uit te voeren statement de benodigde data gaat ophalen.
Dit maakt de code in de overervende klassen veel eenvoudiger en duidelijker. Daarnaast zit de
functionaliteit die verantwoordelijk is voor het ophalen van de data zo volledig afgescheiden.
De bestaande tagrepository werd herschreven zodat deze overerfde van de vernieuwde
CachedEntityRepository klasse.
Voor het ophalen van de tags werd de benodigde sproc geschreven die op basis van het eerste
karakter de tags gaat gaan ophalen. Daarnaast zijn er ook parameters voorzien om de pagina en de
paginagrootte mee te geven.
APPLICATIE
Het aanspreken van de tagrepository gebeurt op basis van het eerste karakter van de tags. Deze
wordt samen met de huidige pagina uit de url gehaald.
De pagina zelf bestaat uit drie delen:
 Navigatie
 Tags
 Paginering
NAVIGATIE
Voor de navigatie worden alle geldige karakters weergegeven. Deze linken door naar het gefilterde
tagsoverzicht.
TAGS
De tags worden opgehaald uit de tagrepository zoals eerder vermeld. Op de pagina worden deze
weergegeven. Deze linken door naar de overzichtspagina van de tag.
PAGINERING

Stagerapport 34
De bestaande paginering bevatte enkel een boolean die bijhield of er nog een volgende pagina
bestond. Aangezien er paginering met paginanummers gevraagd werd diende deze uitgebreid te
worden.
Hiervoor werd het bestaande pagineringmodel uitgebreid met volgende functionaliteit:
 Totaal aantal items
 Items per pagina
 Aantal weer te geven pagina’s
 Implementeert IEnumerable<int>
 Het koppelen van een route aan het paginamodel
 Volledige compatibiliteit met de vorige implementatie
5.1.3 RESULTAAT
Het resultaat kan gevonden worden op http://www.standaard.be/tags
Figuur 5.1-2 Screenshot tagsoverzicht

Stagerapport 35
Figuur 5.1-3 Screenshot tagsoverzicht paginering
Figuur 5.1-4 Sourcecode www.standaard.be/tags?page=2

Stagerapport 36
5.2 PROFIEL
Één van de nice-to-have features binnen dit project was het integreren van de auteursprofielen met
de artikels. Het is de bedoeling dat de gekoppelde profielen onder het artikeldetail worden opgelijst
en deze doorlinken naar een profielpagina waar de auteursinformatie en diens artikels worden
weergegeven.
5.2.1 OPDRACHT
PROFIELLIJST
Onder de detailpagina van een artikel moet er een lijst getoond worden van alle profielen die aan dit
artikel gelinkt zijn.
AUTEURSINFORMATIE
 Naam
 Foto
 Beschrijving
 Link "alle artikels" (naar profielpagina)
ARTIKELINFORMATIE
Onder de titel van een artikel staat informatie van het artikel.
Bv. 01/02/2013 om 12:42 door llo | Bron: VRT, asetniop.com
Indien er één of meerdere profielen gelinkt zijn aan het artikel, moet de naam van de auteur
vervangen worden door de naam van de profielen die doorlinken naar de bijhorende profielpagina.
REL = AUTHOR
De links naar de profielpagina krijgen het “rel” attribuut met value “author”
Bv. <a href="/auteur/andy-stevens" rel="author">Andy Stevens</a>
PROFIELPAGINA
 URL /auteur/[slugName]
AUTEURSINFORMATIE
 Naam
 Omschrijving
 Foto
 Social

Stagerapport 37
o Facebook
o LinkedIn
o Twitter
o Flickr
o Website
o Google+ : voeg rel="me" toe aan deze link
ARTIKELLIJST
Onder de auteursinformatie komt een lijst van diens meest recente artikels. Als een artikel een plus
artikel is, krijgt deze een extra klasse “article--plus”. Er moet ook paginering worden voorzien met
pagina’s van 25 artikels.
5.2.2 UITVOERING
PROFIELLIJST
De profiellijst is een lijst van alle profielen die gekoppeld zijn aan een artikel. Deze wordt onder het
artikel weergegeven en linken door naar de profielpagina van de auteur.
Om deze functionaliteit te implementeren werd de articledetailwidget uitgebreid. Hieraan werd een
methode toegevoegd die de profielen die aan het artikel gekoppeld zijn, gaat ophalen. Dit gebeurt
a.d.h.v. een id die uit de context wordt gehaald. Deze context wordt geregistreerd op een hoger
niveau waar de gegevens uit de url worden gehaald.
Om deze profielen op te halen werd een profilerepository gemaakt op dezelfde wijze als dit bij de
tagrepository is gebeurd.
Het ophalen van de afbeelding gebeurt via de cdnservice.
Daarnaast diende de methode in de articledetailwidget die verantwoordelijk is voor het renderen
van de artikelhoofding te worden aangepast. Wanneer er profielen gekoppeld zijn aan het artikel zal
deze de namen van deze weergeven die doorlinken naar de detailpagina van het profiel.
Als laatste werd ervoor gezorgd dat dit een aparte widget werd door routes van deze widgets door te
verwijzen naar de aangemaakte methode.
PROFIELPAGINA
De profielpagina bestaat uit twee delen. Enerzijds is er een profilewidget met informatie over het
profiel en anderzijds een articlelistwidget die op basis van het profiel artikels weergeeft.
In de controller van de profielpagina wordt de naam van het profiel uit de url gehaald. Op basis
hiervan wordt het profiel opgehaald en opgeslagen in de context zodat de widgets aan deze data
kunnen.

Stagerapport 38
Page
Zone
Block
Widget
Hiervoor werd de profilerepository uitgebreid zodat deze een profiel op basis van de profielnaam kan
ophalen.
Vervolgens werd de profilewidget gemaakt waarin de data uit de profilecontext wordt opgehaald en
weergeeft in een view.
Daarnaast werd de articlelistwidget uitgebreid zodat deze op basis van een profiel een lijst van
artikels kan generen. Hiervoor werden verschillende sprocs geschreven om al dan niet paginering te
voorzien en om artikels al dan niet te sorteren op het aantal keer dat ze gelezen zijn.
Vervolgens werd de profielpagina zelf aangemaakt. De views worden in de database opgeslagen
zodat deze dynamisch aangepast kunnen worden.
Figuur 5.2-1 Pagina structuur

Stagerapport 39
RESULTAAT
PROFIELLIJST
Een voorbeeld kan gevonden worden op http://www.standaard.be/cnt/DMF20111220_055
Figuur 5.2-2 Profilelist http://www.standaard.be/cnt/DMF20111220_055
Figuur 5.2-3 Articletitle met profiel http://www.standaard.be/cnt/DMF20111220_055

Stagerapport 40
PROFIELPAGINA
Een voorbeeld kan gevonden worden op http://localhost:9000/auteur/andy-stevens
Figuur 5.2-4 Profielpagina

Stagerapport 41
5.3 ARCHIEF
Ook de archiefpagina diende in een nieuw jasje te worden gestoken. Deze pagina is vooral voor SEO
zodat alle links naar detailpagina’s van artikels geregistreerd worden door zoekmachines.
5.3.1 OPDRACHT
HOOFDPAGINA INDEXEERBAAR ARCHIEF
 URL: /archief/cnt
 Concept: overzicht omgekeerd sequentieel (recentste maand bovenaan: februari, januari)
 Pagina titel: "Archief - De Standaard"
 Zichtbare titel <h1>: "Overzicht archief De Standaard Online"
 Oude site:
o 201301
o 201302
o …
 Nieuwe site:
o Februari 2013
o Januari 2013
o …
 Tussentitel per jaar (2013, 2012, …)
 Meta tags
o <meta name="robots" content="noindex, follow">
MAANDOVERZICHT
 URL: /archief/cnt/2012/01
 Concept: dagen van die maand sequentieel getoond (di 1 januari 2013, wo 2 januari 2013, …)
 Page title: "Archief januari 2013 - De Standaard"
 Zichtbare titel <h1>: "Overzicht januari 2013"
 Oude site:
o 20130101
o 20130102
o ...
 Nieuwe site:
o di 1 januari
o wo 2 januari
o …
 Meta tags
DAGOVERZICHT

Stagerapport 42
 URL: /archief/cnt/2012/01/04
 Concept: dagoverzicht
 Page title: "Archief 1 januari 2013 - De Standaard"
 Zichtbare titel <h1>: "Overzicht 1 januari 2013"
 Oude site:
o BLDAL_20130101_001
o BLKDE_20121209_001
o ...
 Nieuwe site:
o Groen Herent kiest voor vernieuwing
o HOW TO. After Party Detox
o …
 Meta tags
5.3.2 UITVOERING
Voor het maken van de hoofdpagina wordt er een model gecreëerd dat tussen een interval van jaren
voor iedere maand een datum genereert en deze opslaat in een dictionary. Deze datums worden in
de view overlopen en weergegeven.
MAANDOVERZICHT
Voor het maken van het maandoverzicht wordt er een model aangemaakt dat alle datums van die
bepaalde maand genereert. Deze datums worden in de view overlopen en weergegeven.
DAGOVERZICHT
Voor het dagoverzicht moeten alle artikels van een bepaalde datums alfabetisch worden
weergegeven en doorlinken naar de detailpagina van het artikel.
Aangezien hiervoor enkel de titel van het artikel en diens id vereist zijn, werd er een repository
aangemaakt die dit soort modellen teruggeeft. Daarnaast werd ook de sproc geschreven die deze
data ophaalt en vanuit de repository aangesproken wordt.
In de view worden al deze artikels overlopen en weergegeven.

Stagerapport 43
5.3.3 RESULTAAT
Een voorbeeld kan gevonden worden op http://www.standaard.be/archief/cnt
Figuur 5.3-1 Screenshot hoofdpagina indexeerbaar archief

Stagerapport 44
MAANDOVERZICHT
Een voorbeeld kan gevonden worden op http://www.standaard.be/archief/cnt/2013/4
Figuur 5.3-2 Screenshot maandoverzicht archief

Stagerapport 45
DAGOVERZICHT
Een voorbeeld kan gevonden worden op http://www.standaard.be/archief/cnt/2013/5/8
Figuur 5.3-3 Screenshot dagoverzicht archief

Stagerapport 46
5.4 BIZ
Ook heel het beursgedeelte van de site van De Standaard wordt vernieuwd. In de oude site wordt
alle data weergegeven in iFrames van de Vwd groep. Deze biedt ook een webservice aan om
beursdata op te vragen.
Het begrijpen van volgende termen is belangrijk om volgend hoofdstuk te begrijpen:
 Beurs / StockMarket
 Index / StockIndex
 Aandeel / Share
Een beurs is een verzameling van aandelen. Zo is er bv. Euronext-Brussel die alle aandelen die in
Brussel verhandeld worden omvat.
Een index is een verzameling van aandelen die zo is samengesteld dat ze een bepaald deel van de
markt vertegenwoordigt bv. de Bel 20 is de verzameling van de 20 belangrijkste aandelen op de
Euronext beurs.
Een aandeel is vervolgens wat er op de beurzen verhandeld wordt. Het is mogelijk dat eenzelfde
aandeel op verschillende beurzen verhandeld wordt. Het is ook echter mogelijk dat een aandeel van
eenzelfde beurs in verschillende indexen voorkomt. Daarnaast is het ook nog mogelijk dat er van
hetzelfde bedrijf verschillende aandelen bestaan.
5.4.1 OPDRACHT
Het is de bedoeling in de nieuwe site om een eigen interne service te bouwen die enerzijds interne
data en anderzijds data die via Vwd binnengehaald wordt, aanbiedt. Deze service zal gebruikt
worden door de verschillende beurswidgets die de iFrames zullen vervangen. Daarnaast zullen ook
de verschillende beurswidgets gemaakt moeten worden en de bijhorende beurspagina’s.
Het grote voordeel hiervan t.o.v. de oude implementatie is dat de presentatie van de beursdata
volledig zelf beheerd wordt.
5.4.2 UITVOERING
De beurspagina’s dienen de beursinfo van volgende beurzen weer te geven:
 BEL20
 AEX
 CAC40
 DAX30
 DOW
 NASDAQ
Contractueel gezien zal de data voor de eerste drie Delayed worden aangeboden (vertraging van 15
minuten) en de andere EndOfDay (resultaten van de vorige beursdag).

Stagerapport 47
SERVICE
Zoals eerder vermeld zal er een interne service moeten worden ontwikkeld die data over de
verschillende beursentiteiten zal aanbieden. Intern zal o.a. de data opgeslagen die nodig is om
requests naar Vwd te maken, opgeslagen worden. Daarnaast zal er ook caching moeten worden
voorzien volgens de overeenkomst met Vwd.
INTERN
In de database zal volgende data van de verschillende beursentiteiten worden opgeslagen:
 Naam
 Naam die in de url gebruikt zal worden
 Tag
 Data om externe service aan te spreken
EXTERN
De service die Vwd aanbiedt is een ASP service die op basis van XML requests XML data terugstuurt.
Het specifiëren van de benodigde data gebeurt enerzijds via een id of andere code van Vwd en
anderzijds het DeliveryType. Deze laatste waarde werd zoals eerder vermeld contractueel bepaald en
zal bepalen hoe de data zal worden opgehaald (Realtime, Delayed of EndOfDay).
ANALYSE
In een eerste fase diende de structuur van de service opgesteld te worden en moest ook uitgezocht
worden waar de verschillende componenten binnen het domeinmodel thuishoorden.
Figuur 5.4-1 Structuur service

Stagerapport 48
De data wordt uit twee verschillende bronnen gehaald. Voor de data uit de database zal er een
repository gemaakt worden.
Daarnaast moet er een structuur voorzien worden om de externe data op te vragen en te verwerken.
De client is verantwoordelijk voor het opstellen, versturen en ontvangen van requests. Aangezien de
Vwd service XML genereert moet deze data ook nog verwerkt worden. Hiervoor zal de proxy zorgen.
Deze zal de data mappen op objecten.
Om deze beide datasources aan te spreken en de data aan te bieden aan de applicatie is er gekozen
voor een adapter.
Daarnaast diende er ook caching voorzien te worden. Er is gekozen om dit op het niveau van de
proxy en de repository te doen. De reden hiervoor is dat de aard van de data die beide providers
aanbieden verschillend is. Daar waar de data uit de repository eerder statisch en weinig onderhevig
aan veranderingen is, is de data verkregen uit de proxy dynamisch. Hierdoor zullen er verschillende
caching-tijden geconfigureerd worden.
IMPLEMENTATIE
Aangezien de verschillende beursentiteiten onderlinge referenties bevatten, diende er ook bepaald
te worden hoe deze data ingeladen ging worden.
Figuur 5.4-2 Stockentity loading model

Stagerapport 49
Er is gekozen om de verwijzing naar de StockMarket in te laden van zodra een StockIndex of Share
opgehaald wordt uit de database. Dit werd gedaan omdat de data van de StockMarket van een
StockIndex of Share altijd gebruikt wordt. Enerzijds om de url op te bouwen en anderzijds om de
request naar Vwd op te stellen. De verwijzing naar de StockIndex van een Share dient manueel
ingeladen te worden omdat deze data in de applicatie niet altijd vereist is.
CLIENT
De client bouwt op basis van meegegeven parameters de request op. Daarnaast is er een wrapper
geschreven rond de System.Net.WebRequest klasse met het oog op de testbaarheid van de code.
Via deze wrapper worden de eigenlijke requests gedaan. De client leest de responsestream in en zet
deze om naar xml. Ook is er validatie en logging voorzien.
CLIENTPROXY
De proxy is het aanspreekpunt voor de adapter om data uit de externe service te verkrijgen. Deze
gaat onderliggend de client aanspreken en de teruggekregen xml mappen op objecten. Daarnaast
voorziet deze ook caching.
REPOSITORY
De repository is opgebouwd zoals andere repositories en zal de data uit de database mappen op
objecten. Ook hier is er caching voorzien.
ADAPTER
De adapter is het aanspreekpunt van de applicatie. Deze zal de repository aanspreken om data uit de
database te halen en hieruit de benodigde data halen om de proxy aan te spreken. De verkregen
data uit de proxy en de repository wordt vervolgens gebruikt om de objecten aan te maken die in de
applicatie gebruikt zullen worden.
ANALYSE
Één van de Agile methodologieën is het reviewen van code. Deze stelde de structuur van de service
in vraag en samen met enkele teamleden werd deze herbekeken. De naamgeving van de
verschillende componenten werd in vraag gesteld en ook het opsplitsen van functionaliteit kon
verbeterd worden. Samen werd volgende nieuwe structuur bekomen:

Stagerapport 50
Figuur 5.4-3 Structuur service v2
Er zijn wijzigingen doorgevoerd op het gebied van naamgeving en op het gebied van de opsplitsing
van functionaliteit.
De adapter is vervangen door de StockMarketAppService aangezien het een service is en niet louter
een adapter. [8] Functioneel zal deze hetzelfde doen.
De grootste wijzigingen werden doorgevoerd op het niveau van de proxy. Deze was eigenlijk meer
een repository waarin de mapping verweven zat. Er is gekozen om deze mapping af te splitsen en
adapters aan te maken die de VwdClient en mapper aanspreken. Zo wordt er een Anti-Corruption
laag gecreëerd.

Stagerapport 51
An Anti-Corruption Layer (ACL) is another DDD pattern that encourages you to create
gatekeepers that work to prevent non-domain concepts from leaking into your model. They
keep the model clean. [9]
IMPLEMENTATIE
STOCKMARKETAPPSERVICE
Deze zal het aanspreekpunt zijn in de applicatie om data over beursentiteiten te verkrijgen.
Functioneel blijft deze onveranderd.
STOCKMARKETREPOSITORY
De stockmarketrepository zal de adapters aanspreken om data uit de externe service te verkrijgen.
Daarnaast zal deze ook voor de caching zorgen.
SHARECOLLECTIONREPOSITORY EN SHAREREPOSITORY
Deze zullen net als de repository in de vorige structuur data uit de database ophalen en cachen.
SHAREADAPTER EN STOCKINDEXADAPTER
De adapters zullen de VwdClient en de mapper aanspreken om de verkregen xml om te zetten naar
objecten.
VWDCLIENT
De verantwoordelijkheid van de VwdClient blijft het aanmaken en versturen van requests naar Vwd
en het ontvangen van de response.
VWDSHAREMAPPER EN VWDSTOCKINDEXMAPPER
De mappers zullen de xml vertalen naar objecten.

Stagerapport 52
WIDGETS
De beurspagina’s bestaan uit verschillende widgets. Deze maken onderliggend gebruik van de service
om hun data op te halen. De widgets kunnen hun parameters uit de context halen of deze kunnen
ook gespecifieerd worden.
Voor het aanmaken van de widgets zelf worden dezelfde stappen doorlopen als bij het maken van
andere widgets.
BEURSBALK
De beursbalk zal zorgen voor de navigatie tussen de beurspagina’s. Deze geeft voor indexen
waarvoor dit mogelijk is de huidige koersverandering weer alsook een grafiek van de koers.
Figuur 5.4-4 Beursbalk
GRAFIEK
De afbeeldingen van de grafieken worden aangeboden door Vwd. De grafiek moet afbeeldingen over
volgende perioden weergeven:
 Intraday (Delayed) / 1 week (EndOfDay)
 1 maand
 3 maanden
 1 jaar
 5 jaar
Daarnaast kunnen bij aandelen de koers van het aandeel vergeleken worden met de koers van de
index.

Stagerapport 53
Figuur 5.4-5 Grafiek
INFORMATIE VAN EEN INDEX / AANDEEL
Deze widgets zullen de service aanspreken om een index of aandeel op te halen en deze data
vervolgens weer te geven.
Figuur 5.4-6 Informatie van een index

Stagerapport 54
Figuur 5.4-7 Informatie van een aandeel
AANDELENOVERZICHT
Deze widget toont een overzichtstabel van alle aandelen van een bepaalde index. Er is ook een tab
voorzien met alle aandelen van de beurs waaraan deze index gelinkt is indien dit contractueel
mogelijk is.
Alle aandelen linken door naar de detailpagina van het aandeel en de tabel kan gesorteerd worden
door te klikken op een kolom header.

Stagerapport 55
Figuur 5.4-8 Overzichtstabel aandelen

Stagerapport 56
STIJGERS EN DALERS
Deze widget toont de top drie stijgers en dalers van een bepaalde index. Ieder aandeel linkt door
naar zijn detailpagina.
Figuur 5.4-9 Stijgers en dalers
OVERIGE
Naast voorgaande widgets zijn er ook een aantal widgets waaraan ik niet meegewerkt heb. Deze zijn
op dezelfde manier ontwikkeld. De widget roept de onderliggende service aan om data op te halen
en geeft deze weer.
SCREENSHOTS
Figuur 5.4-10 Heatmap

Stagerapport 57
Figuur 5.4-11 Kerncijfers van een aandeel
Figuur 5.4-12 Winstcijfers van een aandeel
PROBLEMEN
Bij het uitvoeren van deze opdracht kwamen verschillende problemen naar voor. Hieronder worden
enkele van deze besproken.
ANALYSE
De tijdsdruk waaronder het project van de vernieuwing van de site verkeerde, zorgde ervoor dat de
analyse van heel het beursverhaal niet grondig uitgewerkt kon worden. Dit zorgde voor problemen
bij het integreren van de Vwd service aangezien het onduidelijk was over welke data beschikt kon
worden.
Daarnaast waren bepaalde scenario’s zoals wat de business wou wanneer bv. de externe service
onbereikbaar is, niet uitgewerkt wat voor vertraging zorgde.
Wel zorgde dit voor een nauwere communicatie en overleg tussen de teamleden aangezien deze
vaak zelf oplossingen voor de onvolledige analyse moesten zoeken.
VWD
Losstaand van het feit dat het design van de webservice van Vwd niet volgens de hedendaagse
normen ontworpen is (REST?), was deze service vaak onbereikbaar tijdens de ontwikkelingsfase.
Daarnaast zorgde een slechte documentatie voor onnodig tijdverlies.

Stagerapport 58
Ook de communicatie met Vwd verliep niet altijd even vlot en vaak liet Vwd meerdere dagen
wachten op antwoord.
Ten slotte zijn er tijdens het ontwikkelen meerdere problemen naarboven gekomen i.v.m. rechten en
toegang tot data bij Vwd. Toegang tot data die toegankelijk moest zijn, werd geblokkeerd en data die
niet toegankelijk mocht zijn, was wel toegankelijk.
Na communicatie werden deze problemen uiteindelijk net voor de release verholpen.
RELEASE
Bij de release doken er een aantal problemen op. Zo werden er veel fouten gegenereerd bij het
cachen van beursentiteiten. Dit was het gevolg van de herschreven cachedentityrepository die niet
thread safe was. Dit probleem werd verholpen door de parameters op methodeniveau op te slaan
i.p.v. op klasseniveau.
Daarnaast duurden de requests naar Vwd uitzonderlijk lang in productie, soms zelfs met timeout tot
gevolg. Bij Vwd bleken de requests zelf snel te gaan, dus lag het probleem intern.
De proxyinstellingen stonden op automatic detection wat ervoor zorgde dat alle webrequests langs
de proxy werden verstuurd met de bijhorende vertraging tot gevolg. Het uitschakelen van de
automatic detection bleek de oplossing te zijn.
PERFORMANTIE
Bij het uitvoeren van performantietesten bleken de beurspagina’s traag te zijn. Dit probleem kwam
voor wanneer pagina’s werden opgevraagd waarvan de data die widgets nodig hadden niet in de
cache zat.
Bij verdere analyse van de performantie van de aparte widgets kwamen enkel specifieke problemen
naarboven.
BEURSBALK
Bij de beursbalk wordt er een request gedaan naar Vwd die de info van alle indexen gaat opvragen
om de koersverandering te kunnen weergeven. Deze request duurt bij Vwd lang om te verwerken.
Op korte termijn is het een oplossing om de koerswijziging in de beursbalk niet meer weer te geven.
Op lange termijn is het misschien een oplossing dit percentage asynchroon via een js call op te halen.
OVERZICHTSTABEL AANDELEN
Het ophalen van alle aandelen van een index en bijhorende beurs neemt aanzienlijk veel tijd in
beslag vooral op de Duitse beurs aangezien deze een paar duizend aandelen bevat.
Op korte termijn zou het een oplossing zijn om het aandelenoverzicht van de Duitse beurs te
beperken tot de aandelen van de index.
Op lange termijn is het een mogelijke oplossing om de aandelen van een beurs in het overzicht via js
te gaan ophalen wanneer er op geklikt wordt.

Stagerapport 59
5.4.3 RESULTAAT
De beurspagina’s werden op dezelfde manier aangemaakt als bv. de profielpagina.
Voorbeelden hiervan zijn te vinden op onderstaande url’s:
http://www.standaard.be/biz/beleggen
http://www.standaard.be/biz/beleggen/euronext-brussel/colruyt
Figuur 5.4-13 Screenshot Beurspagina Bel20

Stagerapport 60
Figuur 5.4-14 Screenshot Beurspagina Colruyt

Stagerapport 61
TOEKOMST
In het huidige widgetsysteem worden alle widgets synchroon ingeladen. Aangezien deze
onafhankelijk zijn van elkaar, zou men in de toekomst perfect kunnen overschakelen naar een
systeem waar deze asynchroon worden ingeladen. Hiermee kan een enorme performantiewinst
behaald worden.
Specifiek voor deze beurswidgets zouden deze ook via javascript kunnen worden ingeladen. Het
voordeel hiervan is dat de gebruiker de pagina sneller te zien zal krijgen en de widgets vervolgens
eenvoudig (asynchroon) ingeladen kunnen worden. Dit systeem kan men wel niet toepassen voor
andere widgets omwille van SEO.
Een andere mogelijke oplossing is het opzetten van een distributed cache die door een aparte service
preventief wordt gepopuleerd en waarvan de beursdata automatisch ververst wordt.

Stagerapport 62
5.5 DISTRIBUTED CACHE
Uit de theoretische voorstudie bleek vooral Redis een geschikte kandidaat om een distributed cache
op te zetten gezien de noden binnen Corelio. De verschillende platformen zullen echter getest
worden om te kijken welke opstelling de meest performante en makkelijkst te onderhouden is.
De verschillende oplossingen met eventueel verschillende clients zullen tegen elkaar worden
afgewogen door het uitvoeren van schrijf en leesacties naar en van de cache. Enerzijds zal de data
bestaan uit gewone strings en anderzijds uit artikels. Dit is een model waarvoor de cache binnen
Corelio veel gebruikt zal worden. Zo wordt ook meteen de snelheid waarmee objecten vertaald
worden getest.
Daarnaast zal er ook telkens gevalideerd worden of de opgeslagen data niet corrupt is.
5.5.1 OPSTELLING
Voor het opzetten van de pocs en het testen van de verschillende platformen wordt er gebruik
gemaakt van een cluster virtuele machines.
Besturingssysteem Microsoft Windows Server 2008 R2 (64-bit)
CPU 2 vCPU
RAM 4096 MB
Gebruik Webserver +Server/ Client cache
Aantal 4
Besturingssysteem Redhat Enterprise Linux 6.4
CPU 2 vCPU
RAM 8192 MB
Gebruik Server cache
Aantal 2
Daarnaast wordt er ook gebruikt gemaakt van een vast machine met volgende specificaties:
Besturingssysteem Intel Core i7-2820QM
CPU 2 vCPU
RAM 16384 MB
Gebruik Server/Client cache
Aantal 1

Stagerapport 63
5.5.2 INSTALLATIE
De installatie van de webservers was reeds voltooid. Voor de cacheservers werd gekozen voor een
Linux distributie aangezien zowel Redis als Memcached hiervoor ontwikkeld zijn. Voor Redis bestaat
er ook een Windows port, maar deze is onstabiel en niet geschikt voor productie. Deze port zal wel
gebruikt worden om Redis lokaal op de webservers of op de vaste machine te testen.
Couchbase en NCache zullen op de vaste machine geïnstalleerd worden en Windows AppFabric op de
webservers aangezien hiervoor Windows Server vereist is.
REDIS
De installatie van Redis gebeurde door het downloaden en builden van de package. Hiervoor werden
een aantal dependencies geïnstalleerd. De installatie gebeurde a.d.h.v. een zelfgeschreven
installatiescript dat naast Redis Server ook Redis Sentinel installeert (bijlage 1).
Versie: redis-2.6.13.
MEMCACHED
Memcached werd eenvoudig geïnstalleerd door het uitvoeren van volgend commando
yum install Memcached
Versie: Memcached 1.4.4.
COUCHBASE, NCACHE EN WINDOWS APPFABRIC
Voor dezen beperkte de installatie zich tot het volgen van de meegeleverde installer.
Versie: Couchbase Enterprise 2.0.1
NCache Enterprise 4.1 SP2
Windows AppFabric 1.1

Stagerapport 64
5.5.3 CLIENTS
Voor ieder platform zijn er verschillende clients beschikbaar. Aangezien de applicaties binnen Corelio
.NET applicaties zijn, zullen enkel .NET clients gebruikt worden in de testen.
REDIS
Voor Redis bestaan er verschillende C# clients. Omwille van hun lage performantie, beperkte
ondersteuning of documentatie zullen Booksleeve, Sider en redis-sharp niet verder besproken
worden.
SERVICESTACK
ServiceStack is één van de clients voor een Redis server. Deze biedt een gemeenschappelijke
interface aan waarlangs ook Memcached servers kunnen worden aangesproken. Daarnaast is er ook
functionaliteit voorzien om objecten te serialiseren.
Het nadeel aan deze oplossing is deze geen ondersteuning biedt voor Redis Sentinel.
CSREDIS
CsRedis is een library die ondersteuning biedt voor Redis Sentinel. Hierdoor is failover van de nodes
in de distributed cache ook clientside ondersteund. Daarnaast is het ook mogelijk om de cache
asynchroon te benaderen via deze library.
Er is echter geen ondersteuning voor het opslaan of ophalen van .NET objecten. Serialisatie zal dus
zelf geïmplementeerd moeten worden.
SERVICESTACK VS NEWTONSOFT SERIALIZER
Om de performantie van beide serializers te vergelijken werd er een benchmark uitgevoerd waarbij
via CsRedis op de vaste machine de lokaal draaiende Redis server werd benaderd.

Stagerapport 65
Figuur 5.5-1 Servicestack vs NewtonSoft serializer 1000 string writes
Figuur 5.5-2 Servicestack vs NewtonSoft serializer 1000 string reads
We merken dat beiden serializers bij het opslaan of ophalen van strings evenwaardig zijn. Dit is ook
normaal aangezien strings niet meer geserialiseerd moeten worden.
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 10
ms
Test
Writes (1000 strings)
Redis Servicestack Serializer
Redis NewtonSoft Serializer
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 10
ms
Test
Reads (1000 strings)

Stagerapport 66
Figuur 5.5-3 Servicestack vs NewtonSoft serializer 1000 article writes
Figuur 5.5-4 Servicestack vs NewtonSoft serializer 1000 article reads
Bij het opslaan en ophalen van artikels merken we echter dat de ServiceStack serializer performanter
is dat de NewtonSoft serializer.
0
50
100
150
200
250
1 2 3 4 5 6 7 8 9 10
ms
Test
Writes (1000 articles)
0
20
40
60
80
100
120
140
160
180
1 2 3 4 5 6 7 8 9 10
ms
Test
Reads (1000 articles)

Stagerapport 67
Figuur 5.5-5 Servicestack vs NewtonSoft serializer 10000 string writes
Figuur 5.5-6 Servicestack vs NewtonSoft serializer 10000 string reads
Zoals eerder aangehaald is er bij het opslaan en ophalen van strings geen verschil tussen de
serializers.
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test

Stagerapport 68
Figuur 5.5-7 Servicestack vs NewtonSoft serializer 10000 article writes
Figuur 5.5-8 Servicestack vs NewtonSoft serializer 10000 article reads
Het verschil in performantie wordt nog duidelijker wanneer we het aantal operaties vergroten. Hier
zien we dat de ServiceStack serializer bij het wegschrijven van objecten naar de cache ongeveer 25%
sneller is dan de NewtonSoft serializer. Bij het lezen loopt de snelheidswinst zelfs op tot ongeveer
50%.
Voor verdere testen met CsRedis zal dus gebruikt gemaakt worden van de ServiceStack serializer.
0
200
400
600
800
1000
1200
1 2 3 4 5 6 7 8 9 10
ms
Test
0
200
400
600
800
1000
1200
1400
1 2 3 4 5 6 7 8 9 10
ms
Test

Stagerapport 69
SERVICESTACK VS CSREDIS
Om de performantie van beide clients met elkaar te vergelijken, werden een aantal benchmarks
uitgevoerd waarbij de clients op de vast machine een lokale Redis server benaderden.
Figuur 5.5-9 ServiceStack vs CsRedis 1000 string writes
Figuur 5.5-10 ServiceStack vs CsRedis 1000 string reads
We bemerken bij het opslaan op ophalen van strings geen noemenswaardig verschil tussen beide
clients.
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
CsRedis
0
10
20
30
40
50
60
70
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
CsRedis

Stagerapport 70
Figuur 5.5-11 ServiceStack vs CsRedis 1000 article writes
Figuur 5.5-12 ServiceStack vs CsRedis 1000 article reads
Bij het verwerken van complexe data merken we dat de ServiceStack oplossing iets sneller is, maar
het verschil blijft beperkt.
0
20
40
60
80
100
120
140
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
CsRedis
0
20
40
60
80
100
120
140
160
180
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
CsRedis

Stagerapport 71
Figuur 5.5-13 ServiceStack vs CsRedis 10000 string writes
Figuur 5.5-14 ServiceStack vs CsRedis 10000 string reads
Ook wanneer we het aantal operaties vergroten, bemerken we in het geval van strings geen verschil.
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
CsRedis
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
CsRedis

Stagerapport 72
Figuur 5.5-15 ServiceStack vs CsRedis 10000 article writes
Figuur 5.5-16 ServiceStack vs CsRedis 10000 article reads
Wanneer we echter het aantal operaties vergroten in het geval van complexe data bemerken we dat
er een verschil optreedt. De grootte van het verschil blijft echter beperkt.
Gezien het verschil in performantie van beide oplossingen niet zo groot is, maar CsRedis wel
ondersteuning biedt voor Redis Sentinel, zullen we voor deze oplossing kiezen in verdere testen.
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
CsRedis
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
CsRedis

Stagerapport 73
MEMCACHED
Voor Memcached zijn er twee C# clients beschikbaar. Enerzijds EnyimMemcached en anderzijds
BeItMemcached. Beiden zijn opensource en kunnen dus naar eigen noden worden aangepast.
SERVICESTACK (ENYIMCACHED)
Zoals eerder aangehaald biedt ServiceStack ook de functionaliteit om een Memcached server te
benaderen. Ook functionaliteit voor de serialisatie van objecten is voorzien. Deze implementatie
maakt onderliggend gebruik van EnyimMemcached.
BEITMEMCACHED
BeItMemcached biedt ongeveer dezelfde functionaliteit aan als EnyimMemcached. Er zijn bv. wel
geen generieke get en set methodes, maar deze kunnen eenvoudig zelf geïmplementeerd worden.
Ook serialisatie van complexe objecten zal zelf geïmplementeerd moeten worden.
SERVICESTACK VS BEITMEMCACHED
Om beide clients met elkaar te vergelijken werden er benchmarks uitgevoerd waarbij de clients
vanop de webserver de remote Memcached server benaderden.

Stagerapport 74
Figuur 5.5-17 ServiceStack vs BeItMemcached 1000 string writes
Figuur 5.5-18 ServiceStack vs BeItMemcached 1000 string reads
Bij het wegschrijven is het verschil tussen beide beperkt, maar bij het lezen van strings uit de cache is
de BeItMemcached oplossing sneller.
0
100
200
300
400
500
600
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
BeItMemcached
0
100
200
300
400
500
600
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
BeItMemcached

Stagerapport 75
Figuur 5.5-19 ServiceStack vs BeItMemcached 1000 article writes
Figuur 5.5-20 ServiceStack vs BeItMemcached 1000 article reads
Het verwerken van schrijf en leesoperaties op artikels schetst hetzelfde beeld als bij de strings. In het
wegschrijven van data zijn beide clients evenwaardig, maar bij het inlezen van data is
BeItMemcached iets sneller.
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
BeItMemcached
0
100
200
300
400
500
600
700
800
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
BeItMemcached

Stagerapport 76
Figuur 5.5-21 ServiceStack vs BeItMemcached 10000 string writes
Figuur 5.5-22 ServiceStack vs BeItMemcached 10000 string reads
Wanneer het aantal operaties toeneemt wordt het eerder waargenomen verschil tussen beide
oplossingen duidelijker. BeItMemcached haalt de strings ongeveer 33% sneller op de ServiceStack.
0
500
1000
1500
2000
2500
3000
3500
4000
4500
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
BeItMemcached
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
BeItMemcached

Stagerapport 77
Figuur 5.5-23 ServiceStack vs BeItMemcached 10000 article writes
Figuur 5.5-24 ServiceStack vs BeItMemcached 10000 article reads
Tot slot blijkt ook bij het uitvoeren van een groot aantal operaties op artikels dat de BeItMemcached
oplossing performanter is dan ServiceStack.
In verdere testen zal dus gebruik worden gemaakt van de BeItMemcached client.
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
BeItMemcached
0
1000
2000
3000
4000
5000
6000
1 2 3 4 5 6 7 8 9 10
ms
Test
ServiceStack
BeItMemcached

Stagerapport 78
COUCHBASE, NCACHE EN WINDOWS APPFABRIC
Voor deze oplossingen is er telkens één client beschikbaar die meegeleverd wordt bij de installatie.
Het nadeel hiervan is dat deze zelf niet naar eigen noden aangepast kunnen worden.

Stagerapport 79
5.5.4 VERGELIJKING
Uit de theoretische voorstudie bleek dat Redis de oplossing was die het best aansloot bij de noden
van Corelio. Deze oplossing zal naar performantie, betrouwbaarheid en stabiliteit vergeleken worden
met andere platformen.
Aangezien we automatische failover willen implementeren later, wordt er in de testen gebruik
gemaakt van CsRedis.
De resultaten geven geen beeld van de absolute snelheid van de platformen aangezien er in de
testen bij het ophalen ook telkens aan validatie wordt gedaan. Daarnaast beschikken de machines
waarop deze testen uitgevoerd zijn niet over de resources van productieservers.
Redis zal vergeleken worden met volgende platformen:
 Memcached
 Couchbase
 NCache
 Windows AppFabric

Stagerapport 80
REDIS VS. MEMCACHED
Voor de vergelijking van Redis en Memcached werden de cache servers remote aangesproken door
de webserver.
Figuur 5.5-25 Redis vs Memcached 1000 string writes
Figuur 5.5-26 Redis vs Memcached 1000 string reads
Bij het ophalen van strings zijn beide platformen ongeveer even performant en stabiel.
0
50
100
150
200
250
300
350
400
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Memcached
0
50
100
150
200
250
300
350
400
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Memcached

Stagerapport 81
Figuur 5.5-27 Redis vs Memcached 1000 article writes
Figuur 5.5-28 Redis vs Memcached 1000 article reads
Bij het uitvoeren van operaties op artikels liggen de prestaties ongeveer in dezelfde lijn. Bij het lezen
merken we een kleine performantiewinst van Memcached.
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Memcached
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Memcached

Stagerapport 82
Figuur 5.5-29 Redis vs Memcached 10000 string writes
Figuur 5.5-30 Redis vs Memcached 10000 string reads
Ook wanneer we het aantal operaties opdrijven, blijken de prestaties van beide platformen
evenwaardig wanneer het gaat over strings.
0
500
1000
1500
2000
2500
3000
3500
4000
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Memcached
0
500
1000
1500
2000
2500
3000
3500
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Memcached

Stagerapport 83
Figuur 5.5-31 Redis vs Memcached 10000 article writes
Figuur 5.5-32 Redis vs Memcached 10000 article reads
Wanneer het gaat over het verwerken van artikels, blijkt Memcached iets performanter dan Redis.
0
500
1000
1500
2000
2500
3000
3500
4000
4500
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Memcached
0
500
1000
1500
2000
2500
3000
3500
4000
4500
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Memcached

Stagerapport 84
REDIS VS. COUCHBASE
Om Redis met Couchbase te vergelijken werden beide platformen op de vaste machine geïnstalleerd
en werd deze lokaal benaderd.
Figuur 5.5-33 Redis vs Couchbase 1000 string writes
Figuur 5.5-34 Redis vs Couchbase 1000 string reads
Bij het uitvoeren van operaties op strings merken we dat Couchbase performanter is dan Redis. We
merken gemiddeld een performantieverschil op van ongeveer 50%.
0
20
40
60
80
100
120
140
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Couchbase
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Couchbase

Stagerapport 85
Figuur 5.5-35 Redis vs Couchbase 1000 article writes
Figuur 5.5-36 Redis vs Couchbase 1000 article reads
Bij het uitvoeren van operaties op artikels merken we dat de prestaties van beide bij het
wegschrijven naar de cache ongeveer gelijk is. Bij het ophalen van artikels uit de cache merken we
echter dat Redis een pak performanter is dan Couchbase (75%).
0
20
40
60
80
100
120
140
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Couchbase
0
20
40
60
80
100
120
140
160
180
200
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Couchbase

Stagerapport 86
Figuur 5.5-37 Redis vs Couchbase 10000 string writes
Figuur 5.5-38 Redis vs Couchbase 10000 string reads
Ook wanneer we het aantal stringoperaties opdrijven, blijkt Couchbase ongeveer 50% performanter.
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Couchbase
0
100
200
300
400
500
600
700
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Couchbase

Stagerapport 87
Figuur 5.5-39 Redis vs Couchbase 10000 article writes
Figuur 5.5-40 Redis vs Couchbase 10000 article reads
Wanneer het aantal operaties op artikels stijgt, merken we bij het wegschrijven dat Couchbase iets
performanter is. Bij het ophalen van artikels is Redis echter wederom een pak performanter. De
behaalde performantiewinst blijft ongeveer 75%.
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Couchbase
0
200
400
600
800
1000
1200
1400
1600
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Couchbase

Stagerapport 88
REDIS VS. NCACHE
Om Redis met NCache te vergelijken werden beide platformen op de vaste machine geïnstalleerd en
werd deze lokaal benaderd.
Figuur 5.5-41 Redis vs NCache 1000 string writes
Figuur 5.5-42 Redis vs NCache 1000 string reads
Bij het uitvoeren van stringoperaties merken we dat de Redis oplossing zowel bij het wegschrijven als
ophalen van data uit de cache sneller is.
0
20
40
60
80
100
120
140
160
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
NCache
0
20
40
60
80
100
120
140
160
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
NCache

Stagerapport 89
Figuur 5.5-43 Redis vs NCache 1000 article writes
Figuur 5.5-44 Redis vs NCache 1000 article reads
Net als bij het uitvoeren van stringoperaties is Redis ook bij het uitvoeren van operaties op artikels
performanter dan NCache.
0
50
100
150
200
250
300
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
NCache
0
50
100
150
200
250
300
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
NCache

Stagerapport 90
Figuur 5.5-45 Redis vs NCache 10000 string writes
Figuur 5.5-46 Redis vs NCache 10000 string reads
Wanneer het aantal uit te voeren operaties stijgt, wordt het verschil nog duidelijker. Bij het
wegschrijven van data naar de cache is Redis maar liefst dubbel zo snel.
0
200
400
600
800
1000
1200
1400
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
NCache
0
200
400
600
800
1000
1200
1400
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
NCache

Stagerapport 91
Figuur 5.5-47 Redis vs NCache 10000 article writes
Figuur 5.5-48 Redis vs NCache 10000 article reads
Bij het wegschrijven of ophalen van complexe data wordt het verschil tussen beiden al helemaal
duidelijk. Redis haalt een performantiewinst van ongeveer 150% zowel bij het schrijven naar als lezen
van de cache.
0
500
1000
1500
2000
2500
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
NCache
0
500
1000
1500
2000
2500
3000
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
NCache

Stagerapport 92
REDIS VS. WINDOWS APPFABRIC
Aangezien Windows AppFabric enkel beschikbaar is voor Windows Server, werd deze geïnstalleerd
op een webserver waar lokaal ook Redis draaide voor deze testen.
Figuur 5.5-49 Redis vs Windows AppFabric 1000 string writes
Figuur 5.5-50 Redis vs Windows AppFabric 1000 string reads
Windows AppFabric is bij het uitvoeren van stringoperaties ongeveer 3,5 keer zo traag als Redis.
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Windows App Fabric
0
100
200
300
400
500
600
700
800
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Windows App Fabric

Stagerapport 93
Figuur 5.5-51 Redis vs Windows AppFabric 1000 article writes
Figuur 5.5-52 Redis vs Windows AppFabric 1000 article reads
Ook wanneer het gaat over het opslaan of ophalen van complexe objecten blijkt Windows AppFabric
enorm traag. Bij het wegschrijven van deze objecten doet Windows AppFabric er ongeveer 4 keer zo
lang over.
0
100
200
300
400
500
600
700
800
900
1000
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Windows App Fabric
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Windows App Fabric

Stagerapport 94
Figuur 5.5-53 Redis vs Windows AppFabric 10000 string writes
Figuur 5.5-54 Redis vs Windows AppFabric 10000 string reads
Ook wanneer het aantal operaties stijgt blijkt Windows AppFabric veel trager dan Redis.
0
1000
2000
3000
4000
5000
6000
7000
8000
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Windows App Fabric
0
1000
2000
3000
4000
5000
6000
7000
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Windows App Fabric

Stagerapport 95
Figuur 5.5-55 Redis vs Windows AppFabric 10000 article writes
Figuur 5.5-56 Redis vs Windows AppFabric 10000 article reads
De resultaten van deze laatste testen liggen in lijn van de vorige. Redis is veel performanter dan
Windows AppFabric. Bij het wegschrijven van complexe data is Windows AppFabric ongeveer 4 keer
zo traag en bij het ophalen van complexe data ongeveer 3,5 keer.
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Windows App Fabric
0
1000
2000
3000
4000
5000
6000
7000
8000
1 2 3 4 5 6 7 8 9 10
ms
Test
Redis
Windows App Fabric

Stagerapport 96
CONCLUSIE
Uit de testen tussen Redis en Memcached blijkt dat Memcached iets performanter is dan Redis. Maar
het verschil is beperkt en vooral dat de performantie van Redis niet zwaar lijdt onder de extra
featureset, maakt Redis een aantrekkelijkere oplossing dan Memcached. Vooral de ondersteuning
van automatische failover met Redis Sentinel en de ontwikkeling van Redis Cluster spelen in het
voordeel van Redis.
Bij het uitvoeren van operaties op strings blijkt Couchbase performanter dan Redis. Wanneer het
gaat over complexe modellen waaraan serialisatie gepaard gaat, blijkt Redis een pak performanter bij
het inlezen van data.
Aangezien de cache voornamelijk gebruikt zal worden voor het tijdelijk opslaan van complexe
objecten, zal een Redis opstelling performanter zijn. Daarnaast hangt er aan Couchbase een zwaar
kostenplaatje terwijl Redis gratis is.
We merken ook op dat resultaten erg stabiel zijn i.v.m. de testen tussen Redis en Memcached. De
schommelingen in die testen zijn dus vermoedelijk te wijten aan het netwerk aangezien de cache
servers vanop afstand werden benaderd.
NCache en Windows AppFabric zijn abominabel traag t.o.v. Redis. Zeker wanneer er met een cluster
zou gewerkt worden die uit meerdere nodes bestaat en de network penalty er nog bij zou komen,
zijn dit zeker geen werkbare oplossingen.
Redis lijkt over de hele de meest aangewezen oplossing wanneer we kijken naar performantie,
features, stabiliteit en het kostenplaatje.
Naast deze resultaten zijn ook een aantal zaken naarboven gekomen waar rekening mee zal moeten
worden gehouden. Om de performantie van de cache op een acceptabel niveau te houden zal de
afstand tussen servers en clients zo klein mogelijk moeten worden gehouden en de verbinding zo
snel mogelijk. Dit om de network penalty zo klein mogelijk te houden.
Ook is de snelheid waarmee de gegevens verwerkt omgekeerd evenredig met het aantal uit te
voeren operaties.

Stagerapport 97
ALGEMEEN BESLUIT
Gedurende de stage heb ik enorm veel opgestoken zowel op technisch als op persoonlijk vlak.
Ik heb de kans gekregen mee te werken aan één van de grootste sites van België. Zo kreeg ik te
maken met problemen die in andere omgevingen niet ter sprake komen op het gebied van het
ontwikkelen van schaalbare en performante webapplicaties.
Ik kreeg voor het eerst te maken met een applicatie van zodanige omvang en de verschillende
gevolgen die dit heeft op het vlak van codeorganisatie.
Ook leerde ik om samen te werken in een groot team en hoe dit zo efficiënt mogelijk georganiseerd
kan worden.
Ik heb ook de mogelijkheid gekregen om een onafhankelijk onderzoek te doen naar het opzetten van
een distributed cache. Naast het technische aspect leerde ik hierbij ook welke gevolgen zulke
vernieuwing kan hebben binnen een organisatie en met welke verschillende factoren allemaal
rekening moet worden gehouden om deze door te voeren.
De kern van wat ik gedurende deze stage heb bijgeleerd zit in dit verslag beknopt samengevat.
Daarnaast zijn er ook verschillende onderwerpen of aspecten die ik niet heb besproken maar waar ik
tijdens deze stage mee in aanraking ben gekomen:
 Dependency injection
 Inversion of control
 Domain driven design
 Agile
 Scrum
 Design patterns (Adapter, Repository, Builder, Factory, …)
 Single Responsibility principle
 Behavior-driven development
 Test-driven development
 KnockoutJS
 Autofac
 NHibernate
 Team Foundation Server
 NoSQL
 SOLID
 Continuous deployment
 Continuous delivery
 Continuous integration
Ik kan met een voldaan gevoel op deze stage terugblikken. Op zeer korte tijd heb ik op verschillende
vlakken enorm veel bijgeleerd en ik heb ook het gevoel dat ik iets heb kunnen bijbrengen en
verwezenlijken. Voor mij was deze stage meer dan geslaagd 

Stagerapport 98
BIBLIOGRAFIE
[1] „Distributed cache,” Wikipedia, 2 4 2013. [Online]. Available:
http://en.wikipedia.org/wiki/Distributed_cache. [Geopend 23 4 2013].
[2] „Availability,” Wikipedia, 23 4 2013. [Online]. Available:
http://en.wikipedia.org/wiki/Availability. [Geopend 23 4 2013].
[3] O. Widder, „Tech Comics: "High Availability Computing",” 5 10 2012. [Online]. Available:
http://www.datamation.com/news/tech-comics-the-facebook-effect-a-2.html. [Geopend 23 4
2013].
[4] „Multitierarchitectuur,” Wikipedia, 13 3 2013. [Online]. Available:
http://nl.wikipedia.org/wiki/Multitierarchitectuur. [Geopend 3 5 2013].
[5] „Primed Cache,” [Online]. Available:
http://www.diranieh.com/DataAccessPatterns/PrimedCache.htm. [Geopend 23 4 2013].
[6] M. Vandevyvere, „Distributed Cache Options,” Corelio NV, Groot Bijgaarden, 2011.
[7] „NCache: Performance and Scalability Benchmarks,” 18 4 2013. [Online]. Available:
http://www.alachisoft.com/resources/ncache-performance-benchmarks.html.
[8] J. Sugrue, „Design Patterns Uncovered: The Adapter Pattern,” 2 9 2010. [Online]. Available:
http://java.dzone.com/articles/design-patterns-uncovered-0. [Geopend 16 5 2013].
[9] D. Laribee, „An Introduction To Domain-Driven Design,” Microsoft, 2 2009. [Online]. Available:
http://msdn.microsoft.com/en-us/magazine/dd419654.aspx. [Geopend 16 5 2013].
[10] „Inversion of Control – An Introduction with Examples in .NET,” 13 Februari 2013. [Online].
Available: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-
net/.
[11] „Ioc-containers wat en hoe?,” 14 2 2013. [Online]. Available:
http://tim.klingeleers.be/2012/04/ioc-containers-wat-en-hoe/.

Stagerapport 99
[12] „Dependency injection met inversion of control container,” 14 2 2013. [Online]. Available:
http://www.itprosolutions.be/2011/01/dependency-injection-met-inversion-of-control-
container/.
[13] „Sql Server - Efficient way to implement paging,” 15 2 2013. [Online]. Available:
http://stackoverflow.com/questions/548475/efficient-way-to-implement-paging.
[14] „Fluentmigrator,” 14 2 2013. [Online]. Available:
https://github.com/schambers/fluentmigrator/wiki/Migration.
[15] „Autofac,” 13 2 2013. [Online]. Available: http://code.google.com/p/autofac/.
[16] „Autofac,” 13 2 2013. [Online]. Available: http://abdullin.com/autofac/.
[17] „Nhibernate 3.0 tutorial with fluent nhibernate and linq 2 nhibernate,” 14 2 2013. [Online].
Available: http://www.d80.co.uk/post/2011/02/20/Linq-to-NHibernate-Tutorial.aspx.
[18] „Your first NHibernate based application,” 14 2 2013. [Online]. Available:
http://nhforge.org/wikis/howtonh/your-first-nhibernate-based-application.aspx.
[19] „Fluent Interface,” 14 2 2013. [Online]. Available:
https://github.com/schambers/fluentmigrator/wiki/Fluent-Interface.
[20] „Lightweight NHibernate and ASP.NET MVC integration with Autofac,” 13 2 2013. [Online].
Available: http://slynetblog.blogspot.be/2011/04/lightweight-nhibernate-and-aspnet-mvc.html.
[21] „KnockoutJS,” 15 2 2013. [Online]. Available: http://knockoutjs.com/.
[22] „Learn KnockoutJS,” 15 2 2013. [Online]. Available: http://learn.knockoutjs.com/.
[23] „Inversion of Control Containers and the Dependency Injection pattern,” 14 2 2013. [Online].
Available: http://martinfowler.com/articles/injection.html.
[24] J. Butt, „Windows Azure AppFabric Caching,” 14 3 2013. [Online]. Available: http://www.be-
init.nl/article/1478/windows-azure-appfabric-caching.
[25] D. Hume, „Memcached for C# - A Walkthrough,” 18 4 2013. [Online]. Available:

Stagerapport 100
http://www.deanhume.com/Home/BlogPost/memcached-for-c----a-walkthrough/62.
[26] sangeethashekar, „8.0 Factors that Affect Batch Cache-ability,” 15 1 2007. [Online]. Available:
http://blogs.msdn.com/b/sqlprogrammability/archive/2007/01/15/8-0-factors-that-affect-
batch-cache-ability.aspx. [Geopend 23 4 2013].
[27] L. Jankowfsky, „Caching, sharding, distributing - Scaling best practices,” 19 11 2009. [Online].
Available: http://www.slideshare.net/dodgeris/caching-sharding-distributing-scaling-best-
practices. [Geopend 23 4 2013].
[28] nbonvin, „Serving small static files: which server to use ?,” 24 3 2011. [Online]. Available:
http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/.
[Geopend 20 4 2013].
[29] T. Hoff, „Product: Memcached,” High Scalability, 1 8 2007. [Online]. Available:
http://highscalability.com/blog/2007/8/1/product-memcached.html. [Geopend 20 4 2013].
[30] Gear6, „Implementing High Availability Caching with Memcached,” Gear6, 26 8 2009. [Online].
Available: http://www.slideshare.net/gear6memcached/implementing-high-availability-
services-for-memcached-1911077. [Geopend 20 4 2014].
[31] „BeIT Memcached is a client for memcached written in C# 2.0,” [Online]. Available:
https://code.google.com/p/beitmemcached/. [Geopend 24 4 2013].
[32] Aniket, „Heartbeat – A Step by Step Configuration Guide to High Availability Linux Clusters,” The
IT Axis, 14 11 2009. [Online]. Available: http://theitaxis.wordpress.com/2009/11/14/heartbeat-
a-step-by-step-configuration-guide-to-high-availability-linux-clusters/. [Geopend 24 4 2013].
[33] „Memcache vs. Redis?,” Stackoverflow, 20 3 2013. [Online]. Available:
http://stackoverflow.com/questions/10558465/memcache-vs-redis. [Geopend 24 4 2013].
[34] „Redis vs Memcached,” 8 9 2010. [Online]. Available:
http://systoilet.wordpress.com/2010/08/09/redis-vs-memcached/. [Geopend 24 4 2013].
[35] K. Kovacs, „Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j
vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris comparison,” [Online].
Available: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis. [Geopend 24 4 2013].
[36] C. Couch, „Redis as the primary data store? WTF?!,” 5 4 2013. [Online]. Available:

Ontwikkelen van een nieuwe site voor de standaard & onderzoek naar het opzetten van een distributed cache

Ontwikkelen van een nieuwe site voor de standaard & onderzoek naar het opzetten van een distributed cache

Recommended

Recommended

More Related Content

Similar to Ontwikkelen van een nieuwe site voor de standaard & onderzoek naar het opzetten van een distributed cache

Similar to Ontwikkelen van een nieuwe site voor de standaard & onderzoek naar het opzetten van een distributed cache (20)

Ontwikkelen van een nieuwe site voor de standaard & onderzoek naar het opzetten van een distributed cache