Cassandra Performance

/, Unkategorisiert/Cassandra Performance

Cassandra Performance

Cassandra is een Big Data database en wordt als open-source aangeboden. Bij Big Data gaat het om pure snelheid; grote hoeveelheden data dat snel opgevraagd kan worden.

De Cassandra performance diagnose start met het begrijpen uit welke componenten Cassandra is opgebouwd. Cassandra kent een Cassandra node en een Cassandra client. De Cassandra node is een op Java gebaseerde applicatie dat gebruik maakt van een Java Virtual Machine (JVM). Op de Cassandra node dient men een diagnostische agent te installeren om de applicatie aanroepen te kunnen volgen om vervolgens te bepalen hoeveel tijd de Cassandra node consumeert van de totale eindgebruiker responstijd.

De client is het stukje software dat gebruik wordt om de Cassandra database te bevragen dan wel om data op te slaan. Hiervoor dient geen specifieke diagnostische agent voor geïnstalleerd te worden, maar wel een diagnostische agent die de aanroep van de Cassandra node kan volgen. Er zijn vele clients te verkrijgen waardoor niet alle clients door de diagnostische software ondersteund worden, let hier op.

Out-of-the-box hoeft de Cassandra database helemaal niet goed te performen. Met out-of-the-box bedoel ik een standaard installatie zonder aanpassingen in de configuratie, iets dat zeer veel voorkomt. Het is sterk aan te raden om middels performance testen de real-world use cases te testen en tegelijkertijd te diagnosticeren hoe de betrokken componenten in de applicatie keten zich gedragen. Het gedrag van een component kan gemeten worden doordat een component is opgebouwd uit verschillende lagen. Grofweg kan men een onderverdeling maken in een Operating System laag, een Middleware laag, Virtualisatie laag, een Applicatie laag. Bijna van elke laag worden er metertjes bijgehouden die iets specifieks vertellen over het gebruik van de desbetreffende laag. Bekende metertjes zijn CPU, Memory op de Operating System laag. Of de Heap memory size en de Garbage Collection frequentie/duur van de Java Virtual Machine.

De Applicatie laag is veruit de “lastigste” laag, omdat er niet zoveel metertjes beschikbaar zijn. Niet zoveel software ontwikkelaars bouwen metertjes in om de Applicatie laag transparant te maken, ondanks initiatieven zoals ARM. Dit kan zijn, omdat de metertjes een bepaalde extra belasting genereren waardoor de applicatie trager reageert. In het performance vakgebied wordt het niet transparant krijgen van iets een Black Box genoemd; men kan niet in de laag kijken wat er exact aan de hand is. Echter, diagnostische software kan de reddende engel zijn, omdat het de mogelijkheid heeft om wel in de Applicatie laag te kunnen kijken. Afhankelijk van de gebruikte technologie (Java, Dot Net, C/C++) is de Applicatie laag transparant te maken.

Belangrijk is dat er correlatie uitgevoerd kan worden tussen de uit te voeren use cases en de metertjes op de verschillende lagen van de componenten. Waarom? Op deze manier kan achterhaald worden wat de reden is van lange responstijden en/of instabiliteit. Door een verband te leggen tussen het gedrag van de metertjes op de momenten dat de test laat zien dat er lange responstijden zijn, kan men achterhalen wat de oorzaak ervan is.

Lees het volgende interessante artikel over hoe een Cassandra performance diagnose uitgevoerd wordt met de 3e generatie diagnostische tool dynaTrace.

By | 2017-12-07T22:31:05+00:00 april 8th, 2015|Technologie, Unkategorisiert|0 Comments

Leave A Comment