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

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.

3 ACTIEPLAN

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 RepositoryHttpRuntime

CacheStored

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

http://www.standaard.be/tags

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

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

http://localhost:9000/auteur/andy-stevens

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

http://www.standaard.be/archief/cnt

Stagerapport 44


MAANDOVERZICHT

Een voorbeeld kan gevonden worden op http://www.standaard.be/archief/cnt/2013/4

Figuur 5.3-2 Screenshot maandoverzicht archief

http://www.standaard.be/archief/cnt/2013/4

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

http://www.standaard.be/archief/cnt/2013/5/8

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

http://www.standaard.be/biz/beleggen

http://www.standaard.be/biz/beleggen/euronext-brussel/colruyt

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:

Stagerapport 101


https://moot.it/blog/technology/redis-as-primary-datastore-wtf.html. [Geopend 26 4 2013].

[37] „Redis cluster Specification,” [Online]. Available: http://redis.io/topics/cluster-spec. [Geopend

26 4 2013].

[38] „Is memcached a dinosaur in comparison to Redis?,” 11 7 2011. [Online]. Available:

http://stackoverflow.com/questions/2873249/is-memcached-a-dinosaur-in-comparison-to-

redis. [Geopend 26 4 2013].

[39] „Redis vs Memcached comparison,” [Online]. Available:

http://redis4you.com/articles.php?id=003. [Geopend 26 4 2013].

[40] Saxenap, „Install Redis Amazon Linux CentOS,” 6 2012. [Online]. Available:

https://github.com/saxenap/install-redis-amazon-linux-centos. [Geopend 7 5 2013].

[41] N. Timmermans, „Redis Server Sentinel Installation Scripts,” 8 5 2013. [Online]. Available:

https://github.com/nillis/redis-server-sentinel-installation-scripts. [Geopend 8 5 2013].

[42] „Redis Keyspace Notifications,” [Online]. Available: http://redis.io/topics/notifications.

[Geopend 21 5 2013].

Stagerapport 102


BIJLAGEN

1. REDIS SERVER SCRIPTS

5.5.5 REDIS-INSTALL-SCRIPT.SH

#!/bin/bash# Based on https://github.com/saxenap/install-redis-amazon-linux-centos # From https://raw.github.com/nillis/redis-server-sentinel-installation-scripts/master/redis-install-script.sh # Uses redis-server init script from https://raw.github.com/nillis/redis-server-sentinel-installation-scripts/master/redis-server # Uses redis-sentinel init script from https://raw.github.com/nillis/redis-server-sentinel-installation-scripts/master/redis-sentinel ###############################################

# To use: # git clone https://github.com/nillis/redis-server-sentinel-installation-scripts.git # sudo sh redis-install-script.sh

echo "*****************************************" echo " 1. Prerequisites: Install updates, set time zones, install GCC and make" echo "*****************************************" sudo yum -y update sudo yum -y install gcc gcc-c++ make echo "*****************************************" echo " 2. Download, Untar and Make Redis 2.6.13" echo "*****************************************" sudo wget http://redis.googlecode.com/files/redis-2.6.13.tar.gz sudo tar xzf redis-2.6.13.tar.gz sudo rm redis-2.6.13.tar.gz -f cd redis-2.6.13 sudo make sudo make install echo "*****************************************" echo " 3. Create Directories and Copy Redis Files" echo "*****************************************" sudo mkdir /etc/redis-server /etc/redis-sentinel /var/lib/redis-server /var/lib/redis-sentinel sudo cp src/redis-server src/redis-cli src/redis-sentinel /usr/local/bin sudo cp redis.conf /etc/redis-server echo "*****************************************" echo " 4. Configure Redis.Conf" echo "*****************************************" echo " Edit redis.conf as follows:"

Stagerapport 103


echo " 1: ... daemonize yes" echo " 2: ... bind 127.0.0.1" echo " 3: ... dir /var/lib/redis-server" echo " 4: ... loglevel notice" echo " 5: ... logfile /var/log/redis-server.log" echo "*****************************************" sudo sed -e "s/^daemonize no$/daemonize yes/" -e "s/^# bind 127.0.0.1$/bind 127.0.0.1/" -e "s/^dir \.\//dir \/var\/lib\/redis-server\//" -e "s/^loglevel verbose$/loglevel notice/" -e "s/^logfile stdout$/logfile \/var\/log\/redis-server.log/" redis.conf > /etc/redis-server/redis.conf echo "*****************************************" echo " 5. Configure Sentinel.Conf" echo "*****************************************" echo " Edit sentinel.conf as follows:" echo " 1: ... daemonize yes" echo " 2: ... bind 127.0.0.1" echo " 3: ... dir /var/lib/redis-sentinel" echo " 4: ... loglevel notice" echo " 5: ... logfile /var/log/redis-sentinel.log" echo "*****************************************" sudo echo "daemonize yes" >> sentinel.conf sudo echo "dir /var/lib/redis-sentinel" >> sentinel.conf sudo echo "loglevel notice" >> sentinel.conf sudo echo "logfile /var/log/redis-sentinel.log" >> sentinel.conf sudo cp sentinel.conf /etc/redis-sentinel echo "*****************************************" echo " 6. Move and Configure Redis-Server and Redis-Sentinel" echo "*****************************************" cd .. sudo cp redis-server /etc/init.d sudo cp redis-sentinel /etc/init.d sudo chmod 755 /etc/init.d/redis-server sudo chmod 755 /etc/init.d/redis-sentinel echo "*****************************************" echo " 7. Auto-Enable Redis-Server and Redis-Sentinel" echo "*****************************************" sudo chkconfig --add redis-server sudo chkconfig --level 345 redis-server on sudo chkconfig --add redis-sentinel sudo chkconfig --level 345 redis-sentinel on echo "*****************************************" echo " Installation Complete!" echo "" echo " Configure redis-server in /etc/redis-server/redis.conf" echo " Configure redis-sentinel in /etc/redis-sentinel/sentinel.conf" echo "" echo " To start redis-server execute /etc/init.d/redis-server start" echo " To start redis-sentinel execute /etc/init.d/redis-sentinel start" echo "" read -p "Press [Enter] to continue..."

Stagerapport 104


5.5.6 REDIS-REMOVE-SCRIPT

#!/bin/bash # From https://raw.github.com/nillis/redis-server-sentinel-installation-scripts/master/redis-remove-script.sh ###############################################

# To use: # git clone https://github.com/nillis/redis-server-sentinel-installation-scripts.git # sudo sh redis-remove-script.sh

echo "*****************************************" echo " 1. Stop Redis Server and Redis Sentinel" echo "*****************************************" sudo service redis-server stop sudo service redis-sentinel stop echo "*****************************************" echo " 2. Remove Auto-Enable Redis-Server and Redis-Sentinel" echo "*****************************************" sudo chkconfig --del redis-server sudo chkconfig --del redis-sentinel echo "*****************************************" echo " 3. Remove Directories and Files" echo "*****************************************" sudo rm -rf /etc/redis-server /etc/redis-sentinel /var/lib/redis sudo rm -rf /usr/local/bin/redis-server /usr/local/bin/redis-cli /usr/local/bin/redis-sentinel sudo rm -rf /etc/init.d/redis-server sudo rm -rf /etc/init.d/redis-sentinel echo "*****************************************" echo " Uninstall Complete!" read -p "Press [Enter] to continue..."

5.5.7 REDIS-SERVER INIT SCRIPT

#!/bin/sh # From - http://www.codingsteps.com/install-redis-2-6-on-amazon-ec2-linux-ami-or-centos/ # # redis - this script starts and stops the redis-server daemon # Originally from - https://raw.github.com/gist/257849/9f1e627e0b7dbe68882fa2b7bdb1b2b263522004/redis-server # # chkconfig: - 85 15 # description: Redis is a persistent key-value database # processname: redis-server # config: /etc/redis/redis.conf # config: /etc/sysconfig/redis

Stagerapport 105


# pidfile: /var/run/redis.pid # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ "$NETWORKING" = "no" ] && exit 0 redis="/usr/local/bin/redis-server" prog=$(basename $redis) REDIS_CONF_FILE="/etc/redis-server/redis.conf" [ -f /etc/sysconfig/redis ] && . /etc/sysconfig/redis lockfile=/var/lock/subsys/redis start() { [ -x $redis ] || exit 5 [ -f $REDIS_CONF_FILE ] || exit 6 echo -n $"Starting $prog: " daemon $redis $REDIS_CONF_FILE retval=$? echo [ $retval -eq 0 ] && touch $lockfile return $retval echo -n $"$prog started succesfully " } stop() { echo -n $"Stopping $prog: " killproc $prog -QUIT retval=$? echo [ $retval -eq 0 ] && rm -f $lockfile return $retval echo -n $"$prog stopped succesfully " } restart() { echo -n "Restarting $prog ..." stop start echo -n $"$prog restarted succesfully " } reload() { echo -n "Restarting $prog ..." killproc $redis -HUP RETVAL=$? echo }

Stagerapport 106


force_reload() { restart } rh_status() { status $prog } rh_status_q() { rh_status >/dev/null 2>&1 } case "$1" in start) rh_status_q && exit 0 $1 ;; stop) rh_status_q || exit 0 $1 ;; restart|configtest) $1 ;; reload) rh_status_q || exit 7 $1 ;; force-reload) force_reload ;; status) rh_status ;; condrestart|try-restart) rh_status_q || exit 0 ;; *) echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload}" exit 2 esac

5.5.8 REDIS-SENTINEL INIT SCRIPT

#!/bin/sh # From - http://www.codingsteps.com/install-redis-2-6-on-amazon-ec2-linux-ami-or-centos/ # # redis - this script starts and stops the redis-sentinel daemon #

Stagerapport 107


# chkconfig: - 85 15 # description: Redis sentinel is a system designed to help managing Redis instances. # processname: redis-sentinel # config: /etc/redis-sentinel/sentinel.conf # config: /etc/sysconfig/sentinel.conf # pidfile: /var/run/redis-sentinel.pid # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ "$NETWORKING" = "no" ] && exit 0 sentinel="/usr/local/bin/redis-sentinel" prog=$(basename $sentinel) REDIS_SENTINEL_CONF_FILE="/etc/redis-sentinel/sentinel.conf" lockfile=/var/lock/subsys/redis-sentinel start() { [ -x $sentinel ] || exit 5 [ -f $REDIS_SENTINEL_CONF_FILE ] || exit 6 echo -n $"Starting $prog: " daemon $sentinel $REDIS_SENTINEL_CONF_FILE retval=$? echo [ $retval -eq 0 ] && touch $lockfile return $retval echo -n $"$prog started succesfully " } stop() { echo -n $"Stopping $prog: " killproc $prog -QUIT retval=$? echo [ $retval -eq 0 ] && rm -f $lockfile return $retval echo -n $"$prog stopped succesfully " } restart() { echo -n "Restarting $prog ..." stop start echo -n $"$prog restarted succesfully " } case "$1" in start)

Stagerapport 108


start ;; stop) stop ;; restart) restart ;; *) echo "Usage $0 {start|stop|restart}" exit 2 esac

Stagerapport 109


2. DISTRIBUTED CACHE BENCHMARKS

5.5.9 BENCHMARKS SERVICESTACK VS CSREDIS

1000 strings ServiceStack CsRedis 1000 articles ServiceStack CsRedis

Writes 60 65 Writes 66 130

61 59 68 78

60 67 66 78

61 59 66 77

59 63 68 77

59 58 67 76

58 60 67 75

59 59 65 75

61 61 65 77

60 59 65 75

Gemiddelde 59,8 61 Gemiddelde 66,3 81,8

Reads 60 59 Reads 68 160

58 57 69 84

63 60 68 80

59 59 67 79

61 58 68 80

58 57 69 79

58 58 68 79

58 59 67 78

63 59 69 78

58 59 68 79

Gemiddelde 59,6 58,5 Gemiddelde 68,1 87,6

Stagerapport 110


10000 strings ServiceStack CsRedis 10000 articles ServiceStack CsRedis


598 594 671 760

598 602 674 762

614 600 676 771

604 606 686 776

606 593 686 767

614 598 682 781

602 591 683 758

631 595 693 765

603 605 673 806


Reads 584 587 Reads 677 799

580 589 677 807

592 585 689 797

595 596 701 803

581 587 704 819

583 586 691 814

588 585 680 809

592 583 693 793

613 593 685 795

580 584 682 800


Stagerapport 111


5.5.10 BENCHMARKS REDIS SERVICESTACK SERIALIZER VS REDIS NEWTONSOFT

SERIALIZER

1000 strings Servicestack NewtonSoft 1000 articles Servicestack NewtonSoft


58 61 80 97

59 64 79 94

60 66 77 96

59 64 79 98

59 63 79 96

58 64 79 99

58 62 77 96

61 61 77 94

58 63 75 95



58 59 85 127

63 60 79 127

58 62 84 126

58 68 85 128

58 63 81 127

58 60 82 125

57 61 79 124

60 60 79 123

58 61 79 126

Gemiddelde 58,6 61,4 Gemiddelde 89,1 130

Stagerapport 112


10000 strings Servicestack NewtonSoft 10000 articles Servicestack NewtonSoft


589 600 783 954

589 591 760 978

588 592 761 946

588 596 772 964

586 589 772 960

595 591 800 943

595 589 763 954

594 591 764 955

598 603 766 953

Gemiddelde 591,3 593,9 Gemiddelde 775 956,1

Reads 583 590 Reads 822 1250

581 595 788 1254

585 597 787 1256

585 585 790 1252

578 580 830 1257

582 591 801 1268

586 588 801 1244

583 588 794 1245

590 587 795 1261

590 580 825 1258


Stagerapport 113


5.5.11 BENCHMARKS SERVICESTACK VS BEITMEMCACHED

1000 strings ServiceStack BeItMemcached 1000 articles ServiceStack BeItMemcached


345 294 386 419

350 298 401 395

374 289 391 404

480 330 499 391

350 345 390 444

341 359 431 398

373 334 494 383

349 315 412 379

348 378 387 405


Reads 470 315 Reads 754 364

545 266 452 339

390 244 463 341

413 258 449 328

385 295 474 345

465 298 510 320

451 301 448 325

448 315 449 341

403 315 459 342

402 307 459 338


Stagerapport 114


10000 strings ServiceStack BeItMemcached 10000 articles ServiceStack BeItMemcached

Writes 3943 3495 Writes 4167 3480

3762 3366 3967 3363

3524 2967 4024 3842

3805 2962 4021 3834

3669 3080 4439 3336

3830 3414 4316 3751

3759 3464 4239 3701

3737 3373 4364 3833

3813 2903 3936 3941

3834 2995 4067 3649

Gemiddelde 3767,6 3201,9 Gemiddelde 4154 3673

Reads 4286 2936 Reads 4920 3025

3926 2756 4538 3464

3951 2706 4600 3367

4206 2836 4810 3472

4200 2678 4937 3264

4299 2889 4966 3124

4360 3007 4871 3224

4226 3009 4978 3542

4186 2748 4566 3386

4163 2491 4666 3249


Stagerapport 115


5.5.12 BENCHMARKS REDIS VS MEMCACHED

1000 strings Redis Memcached 1000 articles Redis Memcached


313 368 415 375

274 337 350 338

299 378 369 350

299 308 385 360

320 350 361 326

290 310 366 336

316 263 353 341

292 335 368 352

288 331 346 356


Reads 277 285 Reads 616 323

309 302 364 302

286 331 368 301

311 283 372 305

313 293 367 301

314 256 366 304

282 272 349 302

361 265 390 303

286 240 327 314

309 269 378 320


Stagerapport 116


10000 strings Redis Memcached 10000 articles Redis Memcached

Writes 3153 3132 Writes 3977 3292

3113 2910 3518 3468

3099 3364 3631 3736

2915 3343 3602 3829

2975 3297 3851 3660

2959 3320 3636 3346

3040 3493 3831 3249

2965 3331 3895 3591

3271 3239 4030 3601

3322 2917 3567 3639


Reads 3199 2893 Reads 3551 3322

3158 2773 3602 3352

3074 2963 3628 3482

3012 2797 3695 3371

2973 2962 3579 3375

3132 3070 3710 3114

2997 2936 3868 3020

3202 2834 3843 3366

3249 2798 3618 3212

3230 2679 3547 3156


Stagerapport 117


5.5.13 BENCHMARKS REDIS VS COUCHBASE

1000 strings Redis Couchbase 1000 articles Redis Couchbase


57 42 78 73

59 42 78 77

58 43 79 75

58 41 82 74

58 43 81 74

59 42 79 74

59 44 78 74

58 44 79 75

59 41 79 75



68 41 82 137

58 42 81 133

59 41 83 132

63 40 82 136

56 40 83 133

63 41 82 133

59 40 82 132

59 39 82 132

59 41 82 133


Stagerapport 118


10000 strings Redis Couchbase 10000 articles Redis Couchbase


595 434 801 742

599 431 797 743

597 429 798 746

597 426 796 743

590 427 802 744

591 428 790 743

599 426 797 744

595 425 793 741

587 436 796 741


Reads 586 409 Reads 847 1344

586 408 839 1344

592 411 835 1342

594 412 832 1332

590 405 821 1335

587 406 821 1334

589 407 832 1332

586 407 826 1333

584 407 823 1330

588 408 826 1335

Gemiddelde 588,2 408 Gemiddelde 830,2 1336,1

Stagerapport 119


5.5.14 BENCHMARKS REDIS VS NCACHE

1000 strings Redis NCache 1000 articles Redis NCache


67 125 87 243

68 120 81 240

64 125 81 240

63 120 79 234

61 131 82 247

60 147 81 241

61 133 79 241

67 129 81 253

61 120 83 246


Reads 99 114 Reads 167 251

73 115 83 245

73 113 84 249

61 114 87 251

63 111 88 248

63 139 84 278

59 125 83 257

59 117 85 248

60 115 86 271

59 113 91 260


Stagerapport 120


10000 strings Redis NCache 10000 articles Redis NCache

Writes 606 1200 Writes 811 2310

620 1193 804 2251

611 1201 805 2276

617 1262 821 2288

623 1278 817 2284

624 1209 810 2252

616 1158 828 2315

611 1196 866 2304

622 1148 867 2271

611 1209 848 2316


Reads 614 1082 Reads 836 2517

608 1090 845 2553

616 1124 861 2531

612 1198 847 2614

607 1123 856 2538

614 1089 848 2509

607 1075 868 2583

614 1081 1028 2532

610 1119 890 2512

608 1071 863 2610

Gemiddelde 611 1105,2 Gemiddelde 874,2 2549,9

Stagerapport 121


5.5.15 BENCHMARKS REDIS VS WINDOWS APPFABRIC

1000 strings Redis Windows App Fabric 1000 articles Redis Windows App Fabric


170 750 184 772

173 744 184 802

175 757 201 780

172 752 217 783

178 742 182 775

174 796 178 886

168 755 180 784

154 683 220 777

156 673 258 779

Gemiddelde 169,5 749 Gemiddelde 219,2 797

Reads 182 693 Reads 456 790

188 677 180 693

174 680 180 703

177 671 221 696

179 677 209 707

177 677 178 705

179 680 183 762

165 676 209 693

165 588 222 699

157 586 220 706


Stagerapport 122


10000 strings Redis 10000 articles Redis Windows App Fabric

Writes 1786 7536 Writes 2223 7872

1745 6186 2204 7638

1748 6536 2273 7912

1753 6585 2198 7835

1785 7136 2203 7988

1780 6612 2182 7923

1742 6506 2238 7426

1750 6568 2189 7910

1192 6655 2201 7993

1637 7229 2196 7663


Reads 1769 5210 Reads 2231 7058

1722 5660 2204 7065

1880 5632 2191 7088

1866 5730 2202 7536

1771 5687 2214 6938

1750 5585 2226 7066

1787 5775 2209 6995

1721 5782 2208 7526

1623 5690 2250 7094

1762 5686 2225 7028

Gemiddelde 1765,1 5643,7 Gemiddelde 2216 7139,4

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

Internet

Transcript of Ontwikkelen van een nieuwe site voor de standaard & onderzoek naar het opzetten van een distributed...