Caching

En cache är en samling bearbetade data som hålls till hands och återanvänds för att undvika kostsamma upprepade databasfrågor. Totara 2.4 såg implementeringen av MUC, Moodle Universal Cache. Detta nya system tillåter vissa funktioner i Totara (t.ex. stränghämtning) att dra nytta av olika installerade cache-tjänster (t.ex. filer, ram, Memcached).

I framtida versioner av Totara kommer vi att fortsätta att utöka antalet Totara-funktioner som använder MUC, vilket kommer att fortsätta förbättra prestandan, men du kan redan börja använda den för att förbättra din webbplats.

Du kanske också vill titta på vår Caching for developers dokumentation för råd om hur du optimerar prestanda med caching. 

En allmän strategi för prestandatestning

Här är den allmänna strategi du bör ta:

1. Bygg en testmiljö som ligger så nära din verkliga produktionsinstans som möjligt (t.ex. maskinvara, programvara, nätverk osv.).
2. Se till att ta bort så många okontrollerade variabler som möjligt från denna miljö (t.ex. andra tjänster).
3. Använd ett verktyg för att placera en realistisk, men simulerad och repeterbar belastning på din server (t.ex. jmeter eller selen).
4. Bestäm ett sätt att mäta serverns prestanda genom att samla in data (ram, laddning, tidsåtgång osv.).
5. Kör din last och mät ett resultat för baslinjeprestanda.
6. Ändra en variabel i taget och kör om lasten för att se om prestandan blir bättre eller sämre. Upprepa vid behov.
7. När du upptäcker inställningar som resulterar i en konsekvent prestandaförbättring, tillämpa dem på din produktionsanläggning.

Cache-konfiguration i Totara

Sedan Totara 2.4 har Totara tillhandahållit ett ramverk för caching-plugin för att ge administratörer möjlighet att kontrollera var Totara lagrar cachade data. För de flesta Totara-platser bör standardkonfigurationen vara tillräcklig och det är inte nödvändigt att ändra konfigurationen. För större Totara-webbplatser med flera servrar kan administratörer vilja använda Memcached, MongoDB eller andra system för att lagra cachedata. Skärmen för cacheplugin ger administratörer möjlighet att konfigurera vilka cachedata som lagras där.

Caching i Totara styrs av vad som kallas Moodle Universal Cache, vanligen kallad MUC.

Detta dokument förklarar kortfattat vad MUC är innan du går vidare i detalj om de koncept och konfigurationsalternativ som erbjuds.

Grundläggande cache-koncept i Totara

Caching i Totara är inte så komplicerat som det först verkar. Lite bakgrundskunskap kommer att gå långt för att förstå hur cachekonfigurationen fungerar.

Cache-typer

Det finns tre grundläggande typer (ibland kallade lägen) av cacheminnen i Totara. Dessa är:

Cachetyper och system med flera servrar

Om du har ett system med flera front-end webbservrar, måste applikationens cache delas mellan servrarna. Med andra ord kan du inte använda snabb lokal lagring för applikationens cache, utan måste använda delad lagring eller någon annan form av delad cache, t.ex. en delad Memcache.

Detsamma gäller för sessionscache såvida du inte använder en mekanism för klibbiga sessioner för att säkerställa att användare alltid får tillgång till samma front-end-server inom en session.

Cache back-ends

Cache backends är där data faktiskt lagras. Dessa inkluderar saker som filsystemet, PHP-session, Memcached och minne.

Som standard används bara filsystemet, PHP-sessionen och minnet i Totara.

Det krävs inte att en webbplats har tillgång till några andra system såsom Memcached. Istället är det något du ansvarar för att installera och konfigurera dig själv. 

När cachebackends nämns, tänk på system utanför Totara som kan användas för att lagra data, såsom MongoDB-servern, Memcache-servern och liknande serverapplikationer.

Cache-plats

Cache-butiker är en plugin-typ inom Totara. De underlättar anslutning av Totara till cachebackends som diskuteras ovan.

Totara levereras med de tre standardinställningarna som nämns ovan samt Memcache, Memcached och MongoDB.

Koden för dessa finns i cache/butiker i din Totara-katalogrot.

I Totara kan du konfigurera så många cache-butiker som din arkitektur kräver. Om du till exempel har flera Memcache-servrar kan du skapa en cachelagringsinstans för varje.

Totara innehåller som standard tre cachelagringsinstanser som används när du inte har gjort någon annan konfiguration.

• En fillagringsinstans skapas som används för alla programcaches (data lagras i din webbplatsdatakatalog)
• En sessionslagringsinstans skapas som används för alla sessionscaches (data lagras i PHP-sessionen, som som standard lagras i din databas)
• En statisk minneslagringsinstans skapas som används för alla typer av cache-begäran (data finns i minnet bara under en begärans livslängd)

Hur caches fungerar i kod

Kakor skapas i kod och används av utvecklaren för att lagra data som de ser ett behov av cacheminne. 

Utvecklaren får inget att säga i var data cachas. De måste ange följande information när de skapar en cache som ska användas.

• Typen av cache de behöver
• Området för kod som denna cache kommer att tillhöra (API om du vill)
• Namnet på cachen, något som de gör upp för att beskriva i ett ord vad cachen lagrar

Det finns flera valfria krav och inställningar som de också kan specificera. Viktigt är dock att de inte kan välja vilken cache backend som ska användas, de kan bara välja vilken typ av cache de vill ha från de tre som beskrivs ovan.

Hur det knyter samman

Detta beskrivs bäst i förhållande till roller som spelas i en organisation.

• Systemadministratören installerar de cache-back-ends du vill använda. Memcache, XCache, APC och så vidare. Totara känner inte till dessa, de ligger utanför Totaras omfattning och helt och hållet ansvaret för din systemadministratör.
• Totaras webbplatsadministratör skapar en cachelagringsinstans i Totara för varje backend som webbplatsen kommer att använda sig av. Det kan finnas en eller flera cachelagringsinstanser för varje backend. Vissa backends som Memcached har inställningar för att skapa separerade utrymmen inom en backend.
• Utvecklaren har skapat cacheminnen i kod och använder dem för att lagra data. De vet ingenting om hur du ska använda dina cacheminnen, de skapar bara en cache och berättar för Totara vilken typ som är bäst för den.
• Totaras webbplatsadministratör skapar en mappning mellan en cachelagringsinstans och en cache. Denna mappning instruerar Totara att använda den back-end du anger för att lagra data som utvecklaren vill cachas.

Utöver detta kan du ta saker och ting ännu längre.

• Du kan mappa många cacheminnen till en enda cachelagringsinstans
• Du kan mappa flera cachelagringsinstanser till en enda cache med prioritet (primär ... slutlig)
• Du kan mappa en cachelagringsinstans så att den är den standardlagring som används för alla cachelagringar av en specifik typ som annars inte har specifika mappningar

Om det här är första gången du läser om MUC låter det förmodligen ganska komplicerat, men oroa dig inte, det kommer att diskuteras mer detaljerat när vi arbetar igenom hur man konfigurerar cachningen i Totara.

Avancerade koncept

Dessa koncept är saker som de flesta webbplatser inte behöver känna till eller oroa sig för.

Du bör bara börja titta här om du vill maximera prestandan på stora webbplatser som körs över klustrade tjänster med delade cache-backend-enheter, eller på arkitektur på flera platser igen där information delas mellan webbplatser.

Låser

Idén om låsning är inget nytt, det är processen att kontrollera åtkomst för att undvika problem med samtidighet.

MUC har en andra typ av plugin, ett plugin för cache-lås som används när cache-minnen kräver det. Hittills har inga cacheminnen krävt det. En cache är till sin natur flyktig och all information som är absolut verksamhetskritisk bör vara en mer permanent datalagring som sannolikt är databasen.

Det finns dock ett låssystem som cachedefinitioner kan kräva inom sina alternativ och som kommer att tillämpas när man interagerar med en cachelagringsinstans.

Delning

Varje bit data som lagras i en cache har en beräknad unik nyckel kopplad till den.

Som standard är en del av den nyckeln webbplatsidentifieraren som gör innehåll som lagras i cacheminnet specifikt för den webbplats som lagrade det. För de flesta webbplatser är detta precis vad du vill ha.

Men i vissa situationer är det fördelaktigt att tillåta flera webbplatser, eller på något sätt länkade webbplatser att dela cachade data.

Naturligtvis kan inte alla cacheminnen delas, men vissa kan säkert och genom att dela kan du ytterligare minska belastningen och öka prestandan genom att maximera resursanvändningen.

Detta är en avancerad funktion, om du väljer att konfigurera delning, gör det noggrant.

För att använda delning måste du först konfigurera identiska cachelagringsinstanser på de webbplatser du vill dela information, och sedan på varje webbplats ställa in delning för cachen till samma värde.

Tillgängliga inställningsalternativ är följande:

• Platser med samma plats-ID: Detta är standard, det tillåter platser med samma plats-ID att dela cachad information. Det är den mest restriktiva men kommer att fungera för alla cacheminnen. Alla andra alternativ medför ett riskelement genom att du måste se till att informationen i cacheminnet är tillämplig på alla webbplatser som kommer att komma åt den.
• Webbplatser som kör samma version: Alla webbplatser som har tillgång till back-end som har samma Totara-version kan dela informationen som denna cache har lagrat i cache-butiken.
• Anpassad nyckel: För detta anger du manuellt en nyckel att använda för delning. Du måste sedan ange exakt samma nyckel på de andra webbplatser som du vill dela information på.
• Alla: Cachade data är tillgängliga för alla andra webbplatser som har tillgång till data. Detta alternativ sätter bollen helt i Totara administratörs domstol.

Om du till exempel hade flera Totara-webbplatser med samma version på en server med APC installerat, kan du välja att mappa språkcache till APC-butiken och konfigurera delning för alla webbplatser som kör samma version.

Språkcachen för webbplatser i samma version är säker att dela i många situationer, den används på praktiskt taget alla sidor och APC är extremt snabb. Dessa tre punkter kan resultera i en liten prestationsökning för dina webbplatser.

Det är viktigt att tänka på med språkcachen att genom att dela den mellan webbplatser så kommer även språkanpassningar att delas.

Inställningar för cache-konfiguration

Cache-konfiguration ger länkar till alla åtgärder du kan utföra för att konfigurera cachelagring för din webbplats krav.

Öppna skärmen för cachekonfiguration

Skärmen för cachekonfiguration kan endast nås av användare med site:config-kapacitet. Som standard är detta endast administratörer.

När du har loggat in på konfigurationsskärmen kan du hitta den i snabbåtkomstmenyn > Plugins > Caching > Configuration .

Installerade plugin-lagringsplatser

Detta visar dig en lista över plugin-program för cachelagring som du har installerat.

För varje plugin kan du snabbt se om den är redo att användas (alla PHP-krav har uppfyllts), hur många butiksinstanser som redan finns på denna webbplats, cachetyperna som denna butik kan användas för, vilka funktioner den stöder (avancerad) och eventuella åtgärder som du kan utföra i samband med denna butik.

 Sessionscache och statisk begärancache stöder inte flera instanser.

Här får du en lista över cachelagringsinstanser på denna webbplats.

Kända cache-definitioner

Idén om en cachedefinition har inte diskuterats här än. Det är något som kontrolleras av utvecklaren. När de skapar en cache så kan de göra det på två sätt, det första är genom att skapa en cachedefinition.

Detta berättar i huvudsak för Totara om cachen de har skapat. Det andra sättet är att skapa en Adhoc-cache. Utvecklare uppmanas alltid att använda den första metoden. Endast cacheminnen med en definition kan mappas och konfigureras ytterligare av administratören. Adhoc-cacheminnen kommer endast att använda standardinställningar. 

Vanligtvis är adhoc-cache-filer endast tillåtna i situationer där cache-minnet är litet och konfiguration av det utöver standardvärden inte skulle ge någon fördel för administratörer.

För varje cache som visas här får du följande information:

Du hittar också längst ner i denna tabell en länk med titeln Omskanna definitioner . Om du klickar på denna länk kommer Totara att gå av och kontrollera alla kärnkomponenter och installerade plugins som söker efter ändringar i cachedefinitionerna.

Detta händer som standard under en uppgradering, och om en ny cachedefinition påträffas. Men om du hittar dig själv letar efter en cache som inte finns där kan detta vara värt ett försök.

Det är också praktiskt för utvecklare eftersom det gör det möjligt för dem att snabbt tillämpa ändringar när de arbetar med cacheminnen. Det är användbart vid justering av cachedefinitioner för att hitta det som fungerar bäst.

Sammanfattning av cache-låsinstanser

Som nämnts ovan är cachelåsning ett avancerat koncept i MUC.

Tabellen här visar information om de konfigurerade låsmekanismer som är tillgängliga för MUC. Som standard är bara en enda låsmekanism tillgänglig, fillåsning. För närvarande finns det inga caches som använder sig av detta. 

När ingen mappning finns

Denna tabell visar snabbt vilka cachelagringsinstanser som kommer att användas för cachetyper om det inte finns några specifika mappningar på plats.

För att förenkla detta visar detta standardcachelagringarna för varje typ.

Längst ner kommer du att märka att det finns en länk Redigera mappningar som tar dig till en sida där du kan konfigurera detta.

Fil cache

När du skapar en filcache finns det faktiskt bara en parameter som krävs, butiksnamnet. Butiksnamnet används för att identifiera fillagringsinstansen i konfigurationsgränssnittet och måste vara unikt för webbplatsen. Det kan vara vad du vill, men vi rekommenderar att du gör det till något som beskriver din avsedda användning av fillagringen.

Följande egenskaper kan specificeras, anpassa var filcache kommer att placeras och hur det fungerar.

Filcachelagringen är standardlagringen som används för programcachelagringar och som standard används webbplatsdatakatalogen för cachelagringen. Filåtkomst kan vara en beskattningsresurs i tider med ökad belastning och följande är några idéer om hur man konfigurerar alternativa fillagringar för att förbättra prestanda.

• Kontrollera om det finns ett snabbare filsystem tillgängligt för användning på din server. Kanske har du en SSD installerad men använder den inte för din webbplatsdatakatalog eftersom utrymme är en premie. Du bör överväga att skapa en katalog eller liten partition på din SSD och skapa en fillagring för att använda den istället för din Totara datakatalog.
    
• Om du inte har en snabbare enhet tillgänglig för användning, har du gott om ledigt utrymme. Något som kan vara värt att ge en bild skulle vara att skapa en liten partition på enheten du har installerat som använder ett prestandaorienterat filsystem. Många Linux-installationer idag använder till exempel EXT4, ett trevligt filsystem men ett som har omkostnader på grund av journaling.
    
• Skapa en partition och använda ett filsystem som har optimerats för prestanda kan ge dig den lilla boost du letar efter. Kom ihåg att caches är utformade för att vara flyktiga och att välja ett filsystem för en cache är ett annat beslut än att välja ett filsystem för din server.
    
• Slutligen, om du är redo att gå till längder och har ett överflöd av minne på din server kan du överväga att skapa en ramdisk / tmpfs och peka på en fillagring på det. Rent baserat på minne, är det flyktigt precis som cachen är, och filsystemets prestanda kommer bara inte att bli mycket bättre än så här.

Vad du än väljer, kom ihåg att testa det upprepade gånger. Var säker på vilket beslut du fattar.

Memcache

Innan du kan lägga till en Memcache-butiksinstans måste du först ha en Memcached-server som du kan komma åt och ha Memcache PHP-tillägget installerat och aktiverat på din webbserver.

Precis som i filbutiken måste du ange butiksnamnet. Den används för att identifiera butiksinstansen i konfigurationsgränssnittet och måste vara unik för webbplatsen.

För en Memcache-butik måste du också ange Memcache-servern, eller servrar som du vill att den ska använda. Servrar ska läggas till en per rad och varje rad kan innehålla en till tre egenskaper separerade med kolon.

• Serverns URL- eller IP-adress (obligatoriskt).
• Porten som servern lyssnar på (valfritt).
• Vikten för att ge denna server (valfritt).

Om du till exempel hade två Memcached-instanser på din server, en konfigurerad för standardporten och en konfigurerad för 11212, skulle du använda följande:

127.0.0.1

127.0.0.1:11212

Alternativt kan du också specificera ett nyckelprefix att använda. Det du anger här kommer att vara prefix till alla nycklar innan du öppnar servern och kan användas för att effektivt partitionera Memcache-utrymmet på ett igenkännbart sätt. Detta kan vara praktiskt om du har ett hanteringsverktyg för din Memcached server som du använder för att inspektera vad som lagras där.

Memcached

Liksom Memcache-butiken måste du först ha en Memcached-server som du kan komma åt och ha Memcached PHP-tillägget installerat och aktiverat på din server.

Som Memcache-butiken finns det också två parametrar som krävs för att konfigurera en Memcached-butik, Store-namn och Server . Det finns också flera valfria parametrar som du kan ställa in när du skapar en Memcached-butik.

127.0.0.1

127.0.0.1:11212

MongoDB

MongoDB är en öppen källkod dokumentorienterad NoSQL databas. Kolla in deras hemsida www.mongodb.org för mer information.

Redis

Redis är en öppen källkod i minnesdatastruktur som kan användas för cachelagring eller som databas. Du kan läsa mer på Redis webbplats . 

Använda den igbinära serialiseraren 

Den igbinära serialiseraren lagrar datastrukturer i kompakt binär form och besparingar kan vara betydande för lagring av serialiserade data.

Den igbinära serialiseraren är inte en del av en standard PHP-distribution men kan installeras som tillval. Du kan få det från GitHub eller PECL .

Redis cachelagring

När igbinary är installerat kan du välja serialiser när du konfigurerar Redis cache store. Standardinställningen är standard PHP serialiser men kan växlas till igbinary.

Statisk cachelagring

Det statiska cacheminnet använder automatiskt den igbinära serialiseraren när den installeras. Det finns inget inställnings- eller konfigurationsalternativ för att aktivera eller inaktivera det.

Hanterare för Redis-session

Om igbinary är installerat och  $CFG->session_redis_serializer_use_igbinary är inställt på sant använder Redis sessionshanterare igbinary för serialisering av data.

Enstaka kontra flera butiksinstanser

Om en enskild lagringsinstans mappas till cacheminnet sker följande:

• Hämta data från cache Totara frågar cachen för att hämta data. 
• Cachen försöker få den från butiken. 
• Om butiken har det så ger det det till cachen, och cachen ger det till Totara så att det kan använda data. 
• Om butiken inte har det returneras ett fel och Totara måste generera data och kommer sannolikt sedan skicka den till cachen.
• Lagring av data i cachen Totara kommer att be cachen att lagra vissa data, och cachen kommer att ge den till cacheminnet.

Om flera lagringsinstanser mappas till cacheminnet sker följande:

• Hämta data från en butik Totara ber cachen att hämta data.
• Cachen försöker hämta den från den första butiken. 
• Om den första butiken har den så returnerar den data till cachen och cachen returnerar den till Totara. 
• Om den första butiken inte har data så försöker den hämta data från den andra butiken. 
• Om den andra butiken har den returnerar den den till den första butiken som sedan lagrar den själv innan den returneras till cachen. 
• Om den inte gör det så används nästa butik. 
• Detta fortsätter tills antingen data hittas eller tills det inte finns några fler butiker att kontrollera.
• Lagring av data i cache  Totara kommer att be cachen att lagra vissa data, cachen kommer att ge det till varje mappad cachelagring för lagring.

Den största fördelen med att tilldela flera butiker är att du kan introducera cacheredundans. Naturligtvis introducerar detta en overhead så den bör endast användas när det verkligen krävs. Följande är ett exempel på när kartläggning av flera butiker kan ge en fördel.

Scenario

Problem: Du har en webbserver som har en Totara-webbplats samt andra webbplatser. Du har också en Memcache-server som används av flera webbplatser, inklusive Totara. Memcache har en cache i begränsad storlek, som när den är full och begärd att lagra mer information frigör utrymme genom att släppa de minst använda cache-posterna. Du vill använda Memcache för din Totara-webbplats eftersom det är snabbt, men du är medveten om att det kan introducera fler cache-missar eftersom det är en starkt använd Memcache-server.

Lösning: För att komma runt detta kartlägger du två butiker till cacheminnen som du vill använda Memcache. Du gör Memcache till den primära butiken och du gör att standardfilen lagrar den slutliga cache-butiken.

Förklaring: Genom att göra detta har du skapat redundans när något begärs Totara först försöker få det från Memcache (den snabbaste butiken) och om det inte är där fortsätter det att kontrollera filcache.

Bara några fler intressanta punkter:

• Kartläggning av flera cache-minnen kommer att introducera overhead, ju fler cache-minnen kartlagt desto mer overhead.
• Tänk på cachelagringarna du mappar till, om data finns kvar där när de väl har ställts in så finns det ingen punktmappning för ytterligare lagringar efter det. Denna teknik är i första hand värdefull i situationer där data inte garanteras finnas kvar efter att de har ställts in.
• Testa alltid din konfiguration. Aktivera visning av prestandainformation och se sedan vilka butiker som används när du interagerar med Totara på ett sådant sätt att cacheminnet aktiveras.