Caching

Een cache is een verzameling verwerkte gegevens die bij de hand wordt gehouden en opnieuw wordt gebruikt om dure herhaalde database-query's te voorkomen. Totara 2.4 zag de implementatie van MUC, de Moodle Universal Cache. Dit nieuwe systeem staat toe dat bepaalde functies van Totara (bijv. string fetching) profiteren van verschillende geïnstalleerde cacheservices (bijv. bestanden, ram, Memcached).

In toekomstige versies van Totara zullen we het aantal Totara-functies dat MUC gebruikt blijven uitbreiden, waardoor de prestaties blijven verbeteren, maar je kunt het al gebruiken om je site te verbeteren.

Je kunt ook onze Caching voor ontwikkelaars documentatie bekijken voor advies over het optimaliseren van de performance met caching. 

Een algemene benadering van performance testen

Hier is de algemene strategie die je zou moeten volgen:

1. Bouw een testomgeving die zo dicht mogelijk bij je echte productie-instantie ligt (bijv. hardware, software, netwerken, enz.).
2. Zorg ervoor dat je zoveel mogelijk ongecontroleerde variabelen uit deze omgeving verwijdert (bijv. andere diensten).
3. Gebruik een tool om een realistische, maar gesimuleerde en herhaalbare belasting op je server te plaatsen (bijv. jmeter of selenium).
4. Beslis over een manier om de prestaties van de server te meten door gegevens vast te leggen (ram, belasting, ingenomen tijd, enz.).
5. Voer je belasting uit en meet een basisprestatieresultaat.
6. Wijzig één variabele tegelijk en voer de belasting opnieuw uit om te zien of de prestaties beter of slechter worden. Herhaal indien nodig.
7. Wanneer je instellingen ontdekt die resulteren in een consistente prestatieverbetering, pas ze dan toe op je productiesite.

Cache-configuratie in Totara

Sinds Totara 2.4 heeft Totara een caching-pluginraamwerk voorzien om beheerders de mogelijkheid te geven om te controleren waar Totara gecached gegevens bewaart. Voor de meeste Totara-sites zou de standaardconfiguratie voldoende moeten zijn en is het niet nodig om de configuratie te wijzigen. Voor grotere Totara-sites met meerdere servers kunnen beheerders Memcached, MongoDB of andere systemen gebruiken om cachegegevens op te slaan. Het cache-pluginscherm biedt beheerders de mogelijkheid om te configureren welke cachegegevens waar bewaard worden.

Caching in Totara wordt gecontroleerd door wat bekend staat als de Moodle Universele Cache, gewoonlijk MUC genoemd.

In dit document wordt kort uitgelegd wat MUC is voordat je verder gaat met de concepten en configuratieopties die het biedt.

De basiscacheconcepten in Totara

Caching in Totara is niet zo complex als het voor het eerst verschijnt. Een beetje kennis van de achtergrond zal een grote rol spelen in het begrijpen van hoe de cacheconfiguratie werkt.

Cache-types

Er zijn drie basistypes (ook wel modi genoemd) van caches in Totara. Dit zijn:

Cache-types en systemen met meerdere servers

Als je een systeem hebt met meerdere front-end webservers, moet de applicatiecache gedeeld worden tussen de servers. Met andere woorden, je kunt geen snelle lokale opslag gebruiken voor de applicatiecache, maar je moet gedeelde opslag of een andere vorm van gedeelde cache gebruiken, zoals een gedeelde Memcache.

Hetzelfde geldt voor sessiecache, tenzij je een kleverig sessiemechanisme gebruikt om ervoor te zorgen dat gebruikers binnen een sessie altijd toegang hebben tot dezelfde front-end server.

Cache back-ends

Cache backends zijn waar gegevens worden bewaard. Dit zijn zaken zoals het bestandssysteem, PHP-sessie, Memcached en geheugen.

Standaard worden alleen het bestandssysteem, de PHP-sessie en het geheugen gebruikt binnen Totara.

Het is niet nodig dat een site toegang heeft tot andere systemen, zoals Memcached. In plaats daarvan ben je verantwoordelijk voor het installeren en configureren van jezelf. 

Wanneer cache back-ends worden genoemd, denk dan aan systemen buiten Totara die kunnen worden gebruikt om gegevens op te slaan, zoals de MongoDB-server, de Memcache-server en vergelijkbare servertoepassingen.

Cache opslag

Cache-opslag is een plugin-type binnen Totara. Ze vergemakkelijken het verbinden van Moodle met de hierboven besproken cache back-ends.

Totara verzendt met de drie bovengenoemde standaardwaarden, evenals Memcache, Memcached en MongoDB.

De code hiervoor bevindt zich in cache/opslag in je Moodle map root.

In Totara kun je zoveel cache-opslag configureren als je architectuur vereist. Als je bijvoorbeeld meerdere Memcache-servers hebt, dan kun je voor elke server een cache-opslagformulier maken.

Totara bevat standaard drie cache-opslagexemplaren die gebruikt worden wanneer je geen andere configuratie hebt gemaakt.

• Er wordt een bestandsopslag gemaakt die wordt gebruikt voor alle applicatiecaches (gegevens worden opgeslagen in je sitegegevensmap)
• Er wordt een sessieopslag gemaakt die wordt gebruikt voor alle sessiecaches (gegevens worden opgeslagen in de PHP-sessie, die standaard wordt opgeslagen in je database)
• Er wordt een statisch geheugenopslagexemplaar gemaakt dat wordt gebruikt voor alle verzoekcachetypen (gegevens bestaan slechts gedurende de levensduur van een verzoek in het geheugen)

Hoe caches werken in code

Caches worden gemaakt in code en worden gebruikt door de ontwikkelaar om gegevens op te slaan die ze nodig vinden om te cachen. 

De ontwikkelaar krijgt geen mening over waar de gegevens gecached worden. Ze moeten de volgende informatie opgeven bij het maken van een cache om te gebruiken.

• Het type cache dat ze nodig hebben
• De zone met code waartoe deze cache behoort (de API als je dat wil)
• De naam van de cache, iets wat ze in één woord bedoelen wat de cache bewaart

Er zijn verschillende optionele vereisten en instellingen die ze ook kunnen specifiëren. Belangrijk is echter dat ze niet kunnen kiezen welke cache backend ze willen gebruiken, ze kunnen alleen het type cache kiezen dat ze willen uit de drie hierboven beschreven.

Hoe het verbindt

Dit kan het best beschreven worden in relatie tot rollen die gespeeld worden in een organisatie.

• De systeembeheerder installeert de cache back-ends die je wil gebruiken. Memcache, XCache, APC, enzovoort. Totara weet dit niet, ze vallen buiten het bereik van Totara en vallen uitsluitend onder de verantwoordelijkheid van je systeembeheerder.
• De Totara-sitebeheerder maakt een cache-opslaginstantie aan in Totara voor elke back-end waar de site gebruik van zal maken. Er kunnen één of meer cache-opslaginstanties zijn voor elke back-end. Sommige backends zoals Memcached hebben instellingen om gescheiden spaties binnen één backend te maken.
• De ontwikkelaar heeft caches in code gemaakt en gebruikt ze om gegevens op te slaan. Ze weten niets over hoe je je caches gaat gebruiken, ze maken gewoon een cache en vertellen Totara welk type het beste is.
• De Totara-sitebeheerder maakt een koppeling tussen een cache-opslaginstantie en een cache. Die koppeling vertelt Totara om de back-end die je opgeeft te gebruiken om de gegevens op te slaan die de ontwikkelaar wil cachen.

Daarnaast kun je nog verder gaan.

• Je kunt veel caches koppelen aan één enkele cache opslaginstantie
• Je kunt meerdere cache-opslagexemplaren koppelen aan één cache met prioriteit (primair ... definitief)
• Je kunt een cache-opslaginstantie koppelen als de standaardopslag die wordt gebruikt voor alle caches van een specifiek type die anders geen specifieke koppelingen hebben

Als dit de eerste keer is dat je over de MUC leest, dan klinkt dit waarschijnlijk best complex, maar maak je geen zorgen, het zal in meer detail worden besproken terwijl we de caching in Totara configureren.

Geavanceerde concepten

Deze concepten zijn dingen die de meeste sites niet hoeven te kennen of waar ze zich geen zorgen over hoeven te maken.

Je zou hier alleen moeten beginnen te kijken als je de prestaties wilt maximaliseren op grote sites die draaien over geclusterde services met gedeelde cache back-ends, of op multi-site architectuur waar informatie wordt gedeeld tussen sites.

Blokkeren

Het idee van vergrendelen is niets nieuws, het is het proces van het controleren van de toegang om gelijktijdige problemen te voorkomen.

MUC heeft een tweede type plugin, een cache lock plugin die gebruikt wordt wanneer caches dat vereisen. Tot op heden hebben er geen caches nodig. Een cache is van nature volatiel en alle informatie die absoluut missiekritisch is, moet een meer permanente opslag zijn, waarschijnlijk de database.

Niettemin is er een blokkeringssysteem dat cachedefinities kunnen vereisen binnen hun opties en dat wordt toegepast bij interactie met een cache-opslaginstantie.

Delen

Aan elk deel van de gegevens dat in een cache wordt bewaard, is een berekende unieke sleutel gekoppeld.

Standaard is het onderdeel van die sleutel de site-ID die alle inhoud die in de cache is opgeslagen, specifiek maakt voor de site die deze heeft opgeslagen. Voor de meeste sites is dit precies wat je wil.

In sommige situaties is het echter nuttig om meerdere sites of op de een of andere manier gekoppelde sites toe te staan om gecached gegevens te delen.

Natuurlijk kunnen niet alle caches gedeeld worden, maar sommigen zeker en door te delen kun je de belasting verder verminderen en de prestaties verhogen door het gebruik van bronnen te maximaliseren.

Dit is een geavanceerde functie. Als je delen wil configureren, doe dit dan zorgvuldig.

Om gebruik te maken van delen, moet je eerst identieke cache-opslagexemplaren configureren op de sites die je wil delen, en vervolgens op elke site het delen voor de cache op dezelfde waarde zetten.

De beschikbare instellingen zijn als volgt:

• Sites met dezelfde site-ID: Dit is de standaardinstelling. Hiermee kunnen sites met dezelfde site-ID gecached informatie delen. Het is het meest restrictief, maar het zal werken voor alle caches. Alle andere opties brengen een risico-element met zich mee dat je moet verzekeren dat de informatie in de cache van toepassing is op alle sites die er toegang toe hebben.
• Sites met dezelfde versie: Alle sites die de back-end openen en dezelfde Totara-versie hebben, kunnen de informatie die deze cache heeft opgeslagen delen in de cache-opslag.
• Aangepaste sleutel: Hiervoor vul je manueel een sleutel in om te delen. Je moet dan exact dezelfde sleutel ingeven op de andere sites die je wil delen.
• Iedereen: De gecachede gegevens zijn toegankelijk voor alle andere sites die toegang hebben tot de gegevens. Deze optie zet de bal volledig in de rechtbank van de Moodle-beheerder.

Als je bijvoorbeeld meerdere Totara-sites had met dezelfde versie op een server waarop APC is geïnstalleerd, kun je beslissen om de taalcache naar de APC-opslag te koppelen en delen te configureren voor alle sites met dezelfde versie.

De taalcache voor sites met dezelfde versie is veilig om te delen in veel situaties, het wordt gebruikt op vrijwel elke pagina en APC is extreem snel. Deze drie punten kunnen resulteren in een kleine performance boost voor je sites.

Het is belangrijk om met de taalcache te overwegen dat door het delen van taalaanpassingen tussen sites ook eventuele taalaanpassingen gedeeld zullen worden.

Cache configuratie-instellingen

Cache-configuratie biedt links naar alle acties die je kunt uitvoeren om caching te configureren voor de vereisten van je site.

Toegang tot het cache configuratiescherm

Het cacheconfiguratiescherm is alleen toegankelijk voor gebruikers met de mogelijkheid site:config. Standaard is dit alleen beheerders.

Eenmaal ingelogd kan het configuratiescherm gevonden worden in het snelmenu > Plugins > Caching>configuratie.

Geïnstalleerde cache opslag

Dit toont je een lijst met cache opslagplugins die je geïnstalleerd hebt.

Voor elke plugin kun je snel zien of ze klaar is om te worden gebruikt (aan alle PHP-vereisten is voldaan), hoeveel opslagexemplaren er al op deze site bestaan, de cachetypes waarvoor deze opslag kan worden gebruikt, welke functies ze ondersteunt (geavanceerd) en alle acties die je kunt uitvoeren met betrekking tot deze opslag.

 Sessiecache en statische aanvraagcache ondersteunen het hebben van meerdere formulieren niet.

Hier krijg je een lijst van de cache opslaginstanties op deze site.

Bekende cache-definitie

Het idee van een cachedefinitie is hier nog niet besproken. Het is iets dat door de ontwikkelaar wordt gecontroleerd. Wanneer ze een cache maken, kunnen ze dit op twee manieren doen, eerst door een cachedefinitie te maken.

Dit vertelt Moodle over de cache die ze gemaakt hebben. De tweede manier is om een adhoc cache te maken. Ontwikkelaars worden altijd aangeraden om de eerste methode te gebruiken. Alleen caches met een definitie kunnen door de beheerder in kaart gebracht en verder geconfigureerd worden. Adhoc caches zullen enkel gebruik maken van standaardinstellingen. 

Gewoonlijk zijn adhoc caches alleen toegestaan in situaties waar de cache klein is en het configureren ervan buiten de standaardinstellingen geen voordeel zou opleveren voor beheerders.

Voor elke hier getoonde cache krijg je de volgende informatie:

Onderaan deze tabel vind je ook een link met de titel Herscandefinities. Door op deze link te klikken, gaat Totara af en controleert ze alle kerncomponenten en geïnstalleerde plugins die zoeken naar wijzigingen in de cachedefinities.

Dit gebeurt standaard tijdens een upgrade en als er een nieuwe cachedefinitie wordt aangetroffen. Als je echter op zoek bent naar een cache die er niet is, dan kan dit de moeite waard zijn.

Het is ook handig voor ontwikkelaars omdat het hen in staat stelt om snel wijzigingen toe te passen bij het werken met caches. Het is nuttig bij het aanpassen van cachedefinities om te vinden wat het beste werkt.

Samenvatting van cache lock instanties

Zoals hierboven vermeld, is cache-blokkering een geavanceerd concept in MUC.

De tabel hier toont de informatie over de geconfigureerde vergrendelingsmechanismen die beschikbaar zijn voor MUC. Standaard is er slechts één vergrendelingsmechanisme beschikbaar, bestandsvergrendeling. Op dit moment zijn er geen caches die hier gebruik van maken. 

Wanneer er geen koppeling aanwezig is

Deze tabel toont snel welke cache-opslaginstanties gebruikt gaan worden voor cachetypes als er geen specifieke koppelingen zijn.

Om dit te vereenvoudigen, toont dit de standaard cache-opslag voor elk type.

Onderaan zul je zien dat er een link Bewerk koppelingen is die je naar een pagina brengt waar je dit kunt configureren.

Bestandscache

Bij het maken van een bestandscache is er in feite slechts één vereiste parameter, de opslagnaam. De opslagnaam wordt gebruikt om de bestandsopslaginstantie in de configuratie-interface te identificeren en moet uniek zijn voor de site. Het kan alles zijn wat je wil, maar we raden je aan om het iets te maken dat je beoogde gebruik van de bestandsopslag beschrijft.

De volgende eigenschappen kunnen worden opgegeven, waarbij wordt aangepast waar de bestandscache zich bevindt en hoe deze werkt.

De bestandscache-opslag is de standaard opslag die wordt gebruikt voor applicatiecaches en als standaardinstelling wordt de site data-map gebruikt voor de cache. Bestandstoegang kan een belastende bron zijn in tijden van verhoogde belasting en de volgende zijn enkele ideeën over het configureren van alternatieve bestandsopslag om de prestaties te verbeteren.

• Controleer of er een sneller bestandssysteem beschikbaar is voor gebruik op je server. Misschien heb je een SSD geïnstalleerd, maar gebruik je dit niet voor je site datamap omdat spatie een toppunt is. Je zou moeten overwegen om een map of kleine partitie op je SSD te maken en een bestandsopslag te maken om die te gebruiken in plaats van je Totara-datamap.
    
• Als je nog geen snellere schijf hebt, dan heb je wel genoeg vrije ruimte. Iets dat het geven van een foto waard kan zijn, is het maken van een kleine partitie op de schijf die je hebt geïnstalleerd en die een performance-georiënteerd bestandssysteem gebruikt. Veel Linux-installaties gebruiken tegenwoordig bijvoorbeeld EXT4, een mooi bestandssysteem, maar een systeem dat overhead heeft vanwege het bijhouden van logboeken.
    
• Het maken van een partitie en het gebruik van een bestandssysteem dat is geoptimaliseerd voor prestaties kan je die kleine boost geven die je zoekt. Denk eraan dat caches volatiel zijn en dat het kiezen van een bestandssysteem voor een cache een andere keuze is dan het kiezen van een bestandssysteem voor je server.
    
• Als je er klaar voor bent om tot het uiterste te gaan en een overvloed aan geheugen op je server hebt, kun je overwegen om een ramdisk/tmpfs te maken en daar een bestandsopslag naar toe te wijzen. Puur gebaseerd op geheugen, is het vluchtig precies zoals de cache is en de prestaties van het bestandssysteem zullen niet veel beter worden dan dit.

Wat je ook kiest, vergeet niet om het herhaaldelijk te testen. Wees zeker van de beslissing die je neemt.

Memcache

Voordat je een Memcache opslaginstantie kunt toevoegen, moet je eerst een Memcached server hebben waartoe je toegang hebt en de Memcache PHP-extentie geïnstalleerd en ingeschakeld hebben op je webserver.

Zoals de bestandsopslag, moet je de opslagnaam opgeven. Het wordt gebruikt om de opslaginstantie in de configuratie-interface te identificeren en moet uniek zijn voor de site.

Voor een Memcache-opslag moet je ook de Memcache-server binnengaan, of servers waarvan je wil dat ze er gebruik van maken. Servers moeten één per lijn toegevoegd worden en elke lijn kan één tot drie eigenschappen hebben, gescheiden door dubbele punten.

• De URL of IP-adres van de server (vereist).
• De poort waarop de server luistert (optioneel).
• De weging om deze server te geven (optioneel).

Als je bijvoorbeeld twee Memcached-exemplaren op je server had, één geconfigureerd voor de standaardpoort en één geconfigureerd voor 11212, dan zou je het volgende gebruiken:

127.0.0.1

127.0.0.1:11212

Optioneel kun je ook een sleutelprefix opgeven om te gebruiken. Wat je hier ingeeft zal op alle sleutels gezet worden voor je de server opent en kan gebruikt worden om de Memcache ruimte effectief op een herkenbare manier te partitioneren. Dit kan handig zijn als je een beheertool hebt voor je Memcached server die je gebruikt om te controleren wat er bewaard wordt.

Memcached

Net als de Memcache-opslag moet je eerst een Memcached-server hebben waartoe je toegang hebt en de Memcached PHP-extentie geïnstalleerd en ingeschakeld hebben op je server.

Ook zijn er, net als de Memcache-opslag, twee vereiste parameters bij het configureren van een Memcached-opslag, opslagnaam en server. Er zijn ook verschillende optionele parameters die je kunt instellen bij het maken van een Memcached-opslag.

127.0.0.1

127.0.0.1:11212

MongoDB

MongoDB is een open-source documentgeoriënteerde NoSQL-database. Kijk op hun website www.mongodb.org voor meer informatie.

Redis

Redis is een open-source opslag voor gegevensstructuur in het geheugen die kan worden gebruikt voor caching of als databank. Je kunt meer te weten komen op de Redis-website. 

De igbinaire serialiser gebruiken 

De igbinaire serialiser bewaart gegevensstructuren in compacte binaire vorm en besparingen kunnen aanzienlijk zijn voor het bewaren van geserialiseerde gegevens.

De igbinaire serialiser maakt geen deel uit van een standaard PHP distributie, maar kan optioneel geïnstalleerd worden. Je kunt het krijgen van GitHub of PECL.

Redis cache opslag

Wanneer igbinary is geïnstalleerd, kun je de serialiser kiezen bij het configureren van de Redis cache-opslag. Het is standaard ingesteld op de standaard PHP serialiser, maar kan igbinair worden ingeschakeld.

Statische cache opslag

De statische cache-opslag maakt automatisch gebruik van de igbinaire serialiser wanneer deze is geïnstalleerd. Er is geen instelling of configuratie-optie om het te activeren of te deactiveren.

Redis sessie afhandelaar

Als igbinary is geïnstalleerd en $CFG->session_redis_serializer_use_igbinary is ingesteld op waar, dan gebruikt de Redis sessieafhandelaar igbinary voor het serialiseren van de gegevens.

Single versus multiple store instances

Als een enkele opslaginstantie naar de cache wordt gekoppeld, gebeurt het volgende:

• Het ophalen van gegevens uit de cache Totara vraagt de cache om de gegevens op te halen. 
• De cache probeert het uit de opslag te halen. 
• Als de opslag het heeft, geeft het het aan de cache en de cache geeft het aan Totara zodat het de gegevens kan gebruiken. 
• Als de opslag het niet heeft, wordt een fout geretourneerd en moet Totara de gegevens genereren en deze waarschijnlijk naar de cache sturen.
• Het bewaren van gegevens in de cache Totara zal de cache vragen om wat gegevens op te slaan en de cache zal deze aan de cache-opslag geven.

Als er meerdere opslaginstanties naar de cache worden gekoppeld, gebeurt het volgende:

• Het ophalen van gegevens uit een opslag Moodle vraagt de cache om de gegevens op te halen.
• De cache probeert het uit de eerste opslag te halen. 
• Als de eerste opslag die heeft, dan brengt het de gegevens terug naar de cache en de cache brengt ze terug naar Totara. 
• Als de eerste opslag niet over de gegevens beschikt, dan probeert die de gegevens uit de tweede opslag te halen. 
• Als de tweede opslag die heeft, die die terugbrengt naar de eerste opslag die die dan zelf bewaard voordat die terug in de cache gezet wordt. 
• Als dat niet het geval is, wordt de volgende opslag gebruikt. 
• Dit gaat door totdat de gegevens gevonden zijn of er geen opslag meer is om te controleren.
• Het bewaren van gegevens in de cache Totara zal de cache vragen om wat gegevens op te slaan, de cache zal ze naar elke toegewezen cache-opslag sturen voor opslag.

Het belangrijkste voordeel van het toewijzen van meerdere opslagruimten is dat je cache-redundantie kunt introduceren. Dit introduceert natuurlijk een overhead, dus het moet alleen gebruikt worden wanneer het echt nodig is. Het volgende is een voorbeeld van wanneer het koppelen van meerdere opslagmogelijkheden een voordeel kan opleveren.

Scenario

Probleem: je hebt een webserver met een Totara-site en andere sites. Je hebt ook een Memcache-server die wordt gebruikt door verschillende sites, waaronder Totara. Memcache heeft een beperkte cachegrootte, die wanneer ze vol is en gevraagd wordt om meer informatie op te slaan, ruimte vrijmaakt door de minst gebruikte cache-items neer te zetten. Je wilt Memcache gebruiken voor je Memcache-site omdat het snel is, maar je bent je ervan bewust dat het meer cache-ongelukken kan veroorzaken omdat het een zwaar gebruikte Memcache-server is.

Oplossing: Om dit te omzeilen, koppel je twee opslagruimten aan caches die je wil gebruiken. Je maakt Memcache de primaire opslag en je maakt de standaard opslag voor bestanden.

Uitleg: Door dit te doen heb je redundantie gecreëerd wanneer er iets gevraagd wordt aan Memcache (de snelste opslag) en als het er niet is, dan zal Moodle de bestandscache controleren.

Nog een paar punten:

• Het koppelen van meerdere caches zal overhead introduceren, hoe meer caches in kaart gebracht worden, hoe meer overhead.
• Overweeg de cache-opslag waarnaar je koppelt. Als er gegevens blijven staan zodra ze zijn ingesteld, dan is er geen punt-mapping meer voor opslag. Deze techniek is vooral waardevol in situaties waar het niet gegarandeerd is dat gegevens blijven nadat ze zijn ingesteld.
• Test altijd je configuratie. Schakel de weergave van prestatie-informatie in en kijk vervolgens welke opslag wordt gebruikt bij de interactie met Totara, zodat de cache wordt geactiveerd.