Ein Cache ist eine Sammlung verarbeiteter Daten, die zur Verfügung gehalten und wiederverwendet wird, um kostspielige wiederholte Datenbankabfragen zu vermeiden. Totara 2.4 sah die Einführung von MUC, dem Moodle Universal Cache. Dieses neue System ermöglicht es bestimmten Funktionen von Totara (z. B. String-Fetching), verschiedene installierte Cache-Dienste (z. B. Dateien, Ram, Memcached) zu nutzen.
In zukünftigen Versionen von Totara werden wir die Anzahl der Totara-Funktionen, die MUC verwenden, weiter erweitern, was die Leistung weiter verbessern wird, aber Sie können bereits damit beginnen, Ihre Website zu verbessern.
Sie sollten auch unsere Dokumentation zu Caching für Entwickler einsehen, um Ratschläge zur Optimierung der Leistung mit Caching zu erhalten.
Ein allgemeiner Ansatz für Leistungstests
Hier ist die allgemeine Strategie, die Sie verfolgen sollten:
- Erstellen Sie eine Testumgebung, die Ihrer realen Produktionsinstanz so nahe wie möglich kommt (z. B. Hardware, Software, Netzwerk usw.).
- Achten Sie darauf, so viele unkontrollierte Variablen wie möglich aus dieser Umgebung zu entfernen (z. B. andere Dienste).
- Verwenden Sie ein Tool, um eine realistische, aber simulierte und wiederholbare Last auf Ihrem Server zu platzieren (z. B. jmeter oder Selen).
- Entscheiden Sie sich für eine Möglichkeit, die Leistung des Servers durch die Erfassung von Daten (Ram, Last, Zeitaufwand usw.) zu messen.
- Führen Sie Ihre Last aus und messen Sie ein Ausgangsleistungsergebnis.
- Ändern Sie jeweils eine Variable und führen Sie die Last erneut aus, um zu sehen, ob die Leistung besser oder schlechter wird. Wiederholen Sie den Vorgang nach Bedarf.
- Wenn Sie Einstellungen entdecken, die zu einer konsistenten Leistungsverbesserung führen, wenden Sie diese auf Ihre Produktionsseite an.
Cache-Konfiguration in Totara
Seit Totara 2.4 hat Totara ein Caching-Plugin-Framework bereitgestellt, mit dem Administratoren steuern können, wo Totara zwischengespeicherte Daten speichert. Für die meisten Totara-Standorte sollte die Standardkonfiguration ausreichen und es ist nicht notwendig, die Konfiguration zu ändern. Für größere Totara-Websites mit mehreren Servern können Administratoren Memcached, MongoDB oder andere Systeme verwenden, um Cache-Daten zu speichern. Der Cache-Plugin-Bildschirm bietet Administratoren die Möglichkeit zu konfigurieren, welche Cache-Daten wo gespeichert werden.
Das Caching in Totara wird durch den sogenannten Moodle Universal Cache gesteuert, der allgemein als MUC bezeichnet wird.
Dieses Dokument erklärt kurz, was MUC ist, bevor es ins Detail über die Konzepte und Konfigurationsoptionen geht, die es bietet.
Die grundlegenden Cache-Konzepte in Totara
Das Caching in Totara ist nicht so komplex wie es zuerst erscheint. Ein wenig Hintergrundwissen wird viel dazu beitragen, die Funktionsweise der Cache-Konfiguration zu verstehen.
Cache-Typen
Es gibt drei grundlegende Arten (manchmal auch als Modi bezeichnet) von Cache in Totara. Diese sind:
Cache-Typ | Beschreibung |
|---|---|
Anwendungs-Cache | Der Anwendungs-Cache ist mit Abstand der am häufigsten verwendete Cache-Typ im Code. Seine Informationen werden von allen Nutzern geteilt und seine Daten bleiben zwischen Anfragen bestehen. Die hier gespeicherten Informationen werden in der Regel aus einem von zwei Gründen zwischengespeichert:
Standardmäßig werden diese Informationen in einer organisierten Struktur in Ihrem Totara-Datenverzeichnis gespeichert. |
Sitzungs-Cache | Der Sitzungscache ist genau wie die PHP-Sitzung, mit der Sie bereits vertraut sind. Tatsächlich wird die PHP-Sitzung standardmäßig verwendet. Sie fragen sich vielleicht, warum wir diesen Cache-Typ überhaupt haben, aber die Antwort ist einfach. MUC bietet ein verwaltetes Mittel zum Speichern und Entfernen von Informationen, die zwischen Anfragen erforderlich sind. Es bietet Entwicklern ein Framework, das verwendet werden kann, anstatt das Rad neu zu erfinden, und stellt sicher, dass wir Zugriff auf ein kontrolliertes Mittel zur Verwaltung des Cache haben. Es ist wichtig zu beachten, dass dies kein häufig verwendeter Cache-Typ ist, da standardmäßig die Cache-Daten in der PHP-Sitzung und die PHP-Sitzung in der Datenbank gespeichert werden. Die Verwendung des Sitzungscache-Typs ist auf kleine Datensätze beschränkt, da wir keine Sitzungen aufblähen und somit die Datenbank belasten möchten. |
Cache anfordern | Die im Anfrage-Cache-Typ gespeicherten Daten bleiben nur für die gesamte Lebensdauer der Anfrage bestehen. Wenn Sie ein PHP-Entwickler sind, denken Sie daran wie eine verwaltete statische Variable. Dies ist bei weitem die am wenigsten verwendete der Cache-Typen. Die Verwendung ist oft auf Informationen beschränkt, auf die innerhalb derselben Anfrage mehrmals zugegriffen wird, in der Regel durch mehr als einen Codebereich. Cache-Informationen werden standardmäßig im Speicher gespeichert. |
Cache-Typen und Systeme mit mehreren Servern
Wenn Sie ein System mit mehreren Frontend-Webservern haben, muss der Anwendungs-Cache zwischen den Servern geteilt werden. Mit anderen Worten: Sie können keinen schnellen lokalen Speicher für den Anwendungs-Cache verwenden, sondern müssen einen gemeinsam genutzten Speicher oder eine andere Form von gemeinsam genutztem Cache wie einen gemeinsam genutzten Memcache verwenden.
Dasselbe gilt für den Sitzungscache, es sei denn, Sie verwenden einen Sticky-Sessions-Mechanismus, um sicherzustellen, dass Nutzer innerhalb einer Sitzung immer auf denselben Frontend-Server zugreifen.
Cache-Backends
In Cache-Backends werden Daten gespeichert. Dazu gehören das Dateisystem, die PHP-Sitzung, Memcached und der Speicher.
Standardmäßig werden in Totara nur das Dateisystem, die PHP-Sitzung und der Speicher verwendet.
Es ist nicht erforderlich, dass eine Website Zugriff auf andere Systeme wie Memcached hat. Stattdessen sind Sie für die Installation und Konfiguration selbst verantwortlich.
Wenn Cache-Backends erwähnt werden, denken Sie an Systeme außerhalb von Totara, die zum Speichern von Daten verwendet werden können, wie z. B. der MongoDB-Server, der Memcache-Server und ähnliche Serveranwendungen.
Cache-Speicher
Cache-Speicher sind ein Plugin-Typ in Totara. Sie erleichtern die Verbindung von Totara mit den oben beschriebenen Cache-Backends.
Totara wird mit den drei oben genannten Standardeinstellungen sowie mit Memcache, Memcached und MongoDB geliefert.
Der Code für diese befindet sich im Cache/in den Speichern in Ihrem Totara-Verzeichnis.
In Totara können Sie so viele Cache-Speicher konfigurieren, wie Ihre Architektur benötigt. Wenn Sie beispielsweise mehrere Memcache-Server haben, können Sie für jeden Server eine Cache-Speicherinstanz erstellen.
Totara enthält standardmäßig drei Cache-Speicherinstanzen, die verwendet werden, wenn Sie keine andere Konfiguration vorgenommen haben.
- Es wird eine Dateispeicherinstanz erstellt, die für alle Anwendungs-Caches verwendet wird (Daten werden in Ihrem Website-Datenverzeichnis gespeichert)
- Es wird eine Sitzungsspeicherinstanz erstellt, die für alle Sitzungscaches verwendet wird (Daten werden in der PHP-Sitzung gespeichert, die standardmäßig in Ihrer Datenbank gespeichert ist)
- Es wird eine statische Speicherinstanz erstellt, die für alle Anfrage-Cache-Typen verwendet wird (Daten sind nur für die Lebensdauer einer Anfrage im Speicher vorhanden)
Wie Cache-Speicher im Code funktionieren
Caches werden im Code erstellt und vom Entwickler verwendet, um Daten zu speichern, für die ein Cache erforderlich ist.
Der Entwickler erhält keine Aussage darüber, wo die Daten zwischengespeichert werden. Sie müssen die folgenden Informationen angeben, wenn ein Cache zur Verwendung erstellt wird.
- Die Art des Cache, den sie benötigen
- Der Codebereich, zu dem dieser Cache gehört (die API, wenn Sie dies tun)
- Der Name des Cache, etwas, das er zusammensetzt, um in einem Wort zu beschreiben, was der Cache speichert
Es gibt mehrere optionale Anforderungen und Einstellungen, die sie auch festlegen können. Wichtig ist jedoch, dass sie nicht auswählen können, welches Cache-Backend sie verwenden möchten. Sie können nur den gewünschten Cache-Typ aus den drei oben beschriebenen auswählen.
Wie sie miteinander verbunden ist
Dies wird am besten in Bezug auf Rollen in einer Organisation beschrieben.
- Der Systemadministrator installiert die gewünschten Cache-Backends. Memcache, XCache, APC und so weiter. Totara weiß nichts darüber, sie liegen außerhalb des Geltungsbereichs von Totara und liegen ausschließlich in der Verantwortung Ihres Systemadministrators.
- Der Totara Site Administrator erstellt in Totara eine Cache-Speicherinstanz für jedes Backend, das die Website nutzen wird. Für jedes Backend kann eine oder mehrere Cache-Speicherinstanzen vorhanden sein. Einige Backends wie Memcached haben Einstellungen, um getrennte Leerzeichen innerhalb eines Backends zu erstellen.
- Der Entwickler hat Cache-Speicher in Code erstellt und verwendet diese zum Speichern von Daten. Er weiß nichts darüber, wie Sie Ihre Cache-Speicher verwenden werden. Er erstellt einfach einen Cache und teilt Totara mit, welcher Typ am besten geeignet ist.
- Der Totara Site Administrator erstellt eine Zuordnung zwischen einer Cache-Speicherinstanz und einem Cache. Diese Zuordnung weist Totara an, das von Ihnen angegebene Backend zu verwenden, um die Daten zu speichern, die der Entwickler im Cache speichern möchte.
Darüber hinaus können Sie die Dinge weiter vorantreiben.
- Sie können viele Caches einer einzelnen Cache-Store-Instanz zuordnen
- Sie können mehrere Cache-Speicherinstanzen einem einzelnen Cache mit Priorität zuordnen (primär ... endgültig)
- Sie können eine Cache-Store-Instanz als Standardspeicher für alle Cache-Speicher eines bestimmten Typs zuordnen, die sonst keine spezifischen Zuordnungen haben
Wenn Sie zum ersten Mal über das MUC lesen, klingt dies wahrscheinlich ziemlich komplex, aber keine Sorge, es wird genauer besprochen, während wir uns mit der Konfiguration des Cachings in Totara beschäftigen.
Erweiterte Konzepte
Diese Konzepte sind Dinge, die die meisten Websites nicht wissen oder sich keine Gedanken machen müssen.
Sie sollten hier nur dann suchen, wenn Sie die Leistung auf großen Websites maximieren möchten, die über geclusterte Dienste mit gemeinsamen Cache-Backends laufen, oder auf einer Architektur mit mehreren Websites, auf der Informationen zwischen Websites ausgetauscht werden.
Sperren
Die Idee des Sperrens ist nichts Neues. Es ist der Prozess der Zugriffskontrolle, um Gleichzeitigkeiten zu vermeiden.
MUC hat eine zweite Art von Plugin, ein Cache-Sperr-Plugin, das verwendet wird, wenn Caches es erfordern. Bisher sind keine Cache-Speicher erforderlich. Ein Cache ist von Natur aus volatil und alle Informationen, die absolut geschäftskritisch sind, sollten ein permanenterer Datenspeicher sein, wahrscheinlich die Datenbank.
Dennoch gibt es ein Sperrsystem, das Cache-Definitionen innerhalb ihrer Optionen erfordern können und das bei der Interaktion mit einer Cache-Speicherinstanz angewendet wird.
Teilen
Jedem Daten-Bit, das in einem Cache gespeichert wird, ist ein eindeutiger Schlüssel zugeordnet.
Standardmäßig ist ein Teil dieses Schlüssels die Website-Kennung, die alle Inhalte, die im Cache gespeichert sind, spezifisch für die Website, die ihn gespeichert hat. Für die meisten Websites ist dies genau das, was Sie wollen.
In einigen Situationen ist es jedoch von Vorteil, mehrere Websites oder irgendwie verlinkte Websites zuzulassen, um zwischengespeicherte Daten zu teilen.
Natürlich können nicht alle Cache-Speicher gemeinsam genutzt werden, aber einige können es sicherlich und durch die gemeinsame Nutzung können Sie die Belastung weiter reduzieren und die Leistung durch eine Maximierung der Ressourcennutzung steigern.
Dies ist eine erweiterte Funktion. Wenn Sie die Freigabe konfigurieren möchten, tun Sie dies bitte sorgfältig.
Um die gemeinsame Nutzung zu nutzen, müssen Sie zunächst identische Cache-Speicherinstanzen auf den Websites konfigurieren, für die Sie Informationen freigeben möchten, und dann auf jeder Website die gemeinsame Nutzung für den Cache auf den gleichen Wert setzen.
Folgende Einstellungsoptionen stehen zur Verfügung:
- Websites mit der gleichen Website-ID: Dies ist die Standardeinstellung, da Websites mit der gleichen Website-ID zwischengespeicherte Informationen freigeben können. Sie ist am restriktivsten, funktioniert aber für alle Cache-Speicher. Alle anderen Optionen bergen ein gewisses Risiko, da Sie sicherstellen müssen, dass die Informationen im Cache für alle Websites gelten, die darauf zugreifen.
- Websites, die dieselbe Version ausführen: Alle Websites, die auf das Backend zugreifen und die gleiche Totara-Version haben, können die Informationen, die dieser Cache im Cachespeicher gespeichert hat, teilen.
- Benutzerdefinierter Schlüssel: Dazu geben Sie manuell einen Schlüssel ein, der für die Freigabe verwendet werden soll. Sie müssen dann den gleichen Schlüssel in die anderen Websites eingeben, auf denen Sie Informationen teilen möchten.
- Alle: Die zwischengespeicherten Daten sind für alle anderen Websites zugänglich, die auf die Daten zugreifen. Mit dieser Option wird der Ball vollständig auf das Totara-Administratorfeld gesetzt.
Wenn beispielsweise mehrere Totara-Sites dieselbe Version auf einem Server mit installierter APC ausgeführt haben, könnten Sie entscheiden, den Sprach-Cache dem APC-Store zuzuordnen und die Freigabe für alle Sites mit derselben Version zu konfigurieren.
Der Sprach-Cache für Websites mit derselben Version kann in vielen Situationen sicher geteilt werden, er wird auf praktisch jeder Seite verwendet und APC ist extrem schnell. Diese drei Punkte können zu einem kleinen Leistungsschub für Ihre Websites führen.
Es ist wichtig, beim Sprach-Cache zu berücksichtigen, dass durch die gemeinsame Nutzung zwischen Websites auch Sprachanpassungen geteilt werden.
Cache-Konfigurationseinstellungen
Die Cache-Konfiguration enthält Links zu allen Aktionen, die Sie ausführen können, um das Caching für die Anforderungen Ihrer Website zu konfigurieren.
Aufrufen des Cache-Konfigurationsbildschirms
Der Cache-Konfigurationsbildschirm kann nur von Benutzern mit der Funktion site:config aufgerufen werden. Standardmäßig sind dies nur Administratoren.
Nach der Anmeldung im Konfigurationsbildschirm finden Sie das Schnellzugriffsmenü > Plugins > Caching->Konfiguration.
Installierte Cache-Speicher
Hier sehen Sie eine Liste der installierten Cache-Store-Plugins.
Für jedes Plugin können Sie schnell sehen, ob es einsatzbereit ist (alle PHP-Anforderungen wurden erfüllt), wie viele Instanzen bereits auf dieser Website existieren, für welche Cache-Typen dieser Speicher verwendet werden kann, welche Funktionen er unterstützt (erweitert) und welche Aktionen Sie in Bezug auf diesen Speicher ausführen können.
Sitzungscache und statischer Anfragecache unterstützen nicht mehrere Instanzen.
Hier erhalten Sie eine Liste der Cache-Store-Instanzen auf dieser Website.
Spalte | Beschreibung |
|---|---|
Name des Stores | Der Name, der dieser Cache-Speicherinstanz bei der Erstellung gegeben wird, damit Sie ihn erkennen können. Es kann alles sein, was Sie wollen, und wird nur verwendet, damit Sie die Store-Instanz identifizieren können. |
Plugin | Das Cache-Store-Plugin, dessen Instanz dies ist. |
Bereit | Ein Häkchen wird angezeigt, wenn alle PHP-Anforderungen erfüllt sind und alle Verbindungs- oder Einrichtungsanforderungen überprüft wurden. |
Zuordnungen speichern | Die Anzahl der Caches, denen diese Store-Instanz explizit zugeordnet wurde. Enthält keine Verwendungen durch Standardzuordnungen (siehe unten). |
Modi | Die Modi, die diese Cache-Store-Instanz bedienen kann. |
Unterstützt | Die Funktionen werden von dieser Cache-Speicherinstanz unterstützt. |
Sperren | Locking ist ein Vorgang, der das Überschreiben von zwischengespeicherten Daten für eine Zeit verhindert. Die Sperrmethode legt fest, wie die Sperre erfasst und überprüft wird. |
Aktionen | Alle Aktionen, die gegen diese Cache-Store-Instanz ausgeführt werden können. |
Bekannte Cache-Definitionen
Die Idee einer Cache-Definition wurde hier noch nicht besprochen. Es wird vom Entwickler kontrolliert. Wenn sie einen Cache erstellen, können sie dies auf zwei Arten tun: Die erste ist die Erstellung einer Cache-Definition.
Dies informiert Totara im Wesentlichen über den erstellten Cache. Die zweite Möglichkeit ist die Erstellung eines Adhoc-Caches. Entwicklern wird immer empfohlen, die erste Methode zu verwenden. Nur Cache-Speicher mit einer Definition können vom Administrator zugeordnet und weiter konfiguriert werden. Adhoc-Caches verwenden nur die Standardeinstellungen.
Adhoc-Caches sind in der Regel nur in Situationen zulässig, in denen der Cache klein ist und eine Konfiguration über die Standardeinstellungen hinaus Administratoren keinen Nutzen bringen würde.
Für jeden hier angezeigten Cache erhalten Sie die folgenden Informationen:
Spalte | Beschreibung |
|---|---|
Definition | Eine präzise Beschreibung dieses Cache. |
Modus | Der Cache-Typ, für den dieser Cache entwickelt wurde. |
Komponente | Die Codekomponente, mit der der Cache verknüpft ist. |
Bereich | Der Codebereich, den dieser Cache innerhalb der Komponente bedient. |
Zuordnungen speichern | Der oder die Speicher, die für diesen Cache verwendet werden. |
Teilen | Wie ist die Freigabe für diese Website konfiguriert? |
Aktionen | Alle Aktionen, die im Cache ausgeführt werden können. In der Regel können Sie die Cache-Store-Instanzzuordnungen bearbeiten, die Freigabe bearbeiten und den Cache löschen. |
Unten in dieser Tabelle finden Sie auch einen Link mit dem Titel Definitionen erneut scannen. Wenn Sie auf diesen Link klicken, wird Totara alle Kernkomponenten und installierten Plugins überprüfen, die nach Änderungen in den Cache-Definitionen suchen.
Dies geschieht standardmäßig während eines Upgrades und wenn eine neue Cache-Definition gefunden wird. Wenn Sie jedoch auf der Suche nach einem Cache sind, der nicht vorhanden ist, ist dies möglicherweise einen Versuch wert.
Es ist auch praktisch für Entwickler, da es ihnen ermöglicht, Änderungen schnell anzuwenden, wenn sie mit Cache arbeiten. Es ist nützlich, wenn Sie die Cache-Definitionen anpassen, um herauszufinden, was am besten funktioniert.
Zusammenfassung der Cache-Sperrinstanzen
Wie oben erwähnt, ist die Cache-Sperre ein erweitertes Konzept in MUC.
Die folgende Tabelle zeigt die Informationen zu den konfigurierten Sperrmechanismen, die MUC zur Verfügung stehen. Standardmäßig ist nur ein einziger Sperrmechanismus verfügbar, die Dateisperre. Derzeit gibt es keine Cache-Speicher, die diese nutzen.
Wenn keine Zuordnung vorhanden ist
Diese Tabelle zeigt schnell, welche Cache-Speicherinstanzen für Cache-Typen verwendet werden, wenn keine spezifischen Zuordnungen vorhanden sind.
Um dies zu vereinfachen, werden die standardmäßigen Cache-Speicher für jeden Typ angezeigt.
Unten sehen Sie einen Link Zuordnungen bearbeiten, der Sie zu einer Seite führt, auf der Sie dies konfigurieren können.
Datei-Cache
Beim Erstellen eines Datei-Caches gibt es tatsächlich nur einen erforderlichen Parameter, den Namen des Stores. Der Speichername wird verwendet, um die Dateispeicherinstanz in der Konfigurationsschnittstelle zu identifizieren und muss eindeutig für die Website sein. Es kann alles sein, was Sie wollen, aber wir empfehlen, es etwas zu machen, das Ihre beabsichtigte Verwendung des Dateispeichers beschreibt.
Die folgenden Eigenschaften können festgelegt werden, um festzulegen, wo sich der Datei-Cache befindet und wie er funktioniert.
Einstellung | Beschreibung | Hinweise |
|---|---|---|
| Name des Stores | Der Name des Stores wird angegeben. | Obligatorisch. |
| Sperren | Locking ist ein Vorgang, der das Überschreiben von zwischengespeicherten Daten für eine Zeit verhindert. Die Sperrmethode legt fest, wie die Sperre erfasst und überprüft wird. | - |
Cache-Pfad | Ermöglicht die Angabe eines Verzeichnisses, das beim Speichern von Cache-Daten im Dateisystem verwendet werden soll. Natürlich muss der Nutzer, den der Webserver ausführt, Lese-/Schreibzugriff auf dieses Verzeichnis haben. Standardmäßig (leer) wird das Site-Datenverzeichnis verwendet. | - |
Verzeichnis automatisch erstellen | Wenn diese Option aktiviert ist, wenn der Cache initialisiert wird und das angegebene Verzeichnis nicht existiert, erstellt Totara es. Wenn dies angegeben ist und das Verzeichnis nicht existiert, gilt der Cache als nicht bereit und wird nicht verwendet. | - |
Einzelverzeichnisspeicher | Standardmäßig erstellt der Dateispeicher eine Unterverzeichnisstruktur zum Speichern von Daten. Die ersten drei Zeichen des Datenschlüssels werden als Verzeichnis verwendet. Dies ist nützlich, um Beschränkungen des Dateisystems zu vermeiden, wenn das Dateisystem über eine maximale Anzahl von Dateien pro Verzeichnis verfügt. Wenn Sie diese Option aktivieren, verwendet der Datei-Cache keine Unterverzeichnisse für die Speicherung von Daten. Dies führt zu einer flachen Struktur, die jedoch mit größerer Wahrscheinlichkeit die Grenzen des Dateisystems überschreitet. Mit Vorsicht verwenden. | - |
Prescan-Verzeichnis | Eine der Funktionen, die der Datei-Cache bietet, ist das Vorscannen des Speicherverzeichnisses, wenn der Cache zum ersten Mal verwendet wird. Dies führt zu schnelleren Überprüfungen von Dateien auf Kosten einer eingehenden Lektüre. | - |
Der Datei-Cache-Speicher ist der Standardspeicher, der für Anwendungs-Caches verwendet wird, und standardmäßig wird das Site-Datenverzeichnis für den Cache verwendet. Der Dateizugriff kann in Zeiten erhöhter Belastung eine fordernde Ressource sein. Im Folgenden finden Sie einige Ideen zur Konfiguration alternativer Dateispeicher zur Verbesserung der Leistung.
- Prüfen Sie, ob auf Ihrem Server ein schnelleres Dateisystem zur Verwendung verfügbar ist. Vielleicht ist eine SSD installiert, aber nicht für Ihr Website-Datenverzeichnis, da Speicherplatz eine Prämie ist. Sie sollten in Betracht ziehen, ein Verzeichnis oder eine kleine Partition auf Ihrer SSD zu erstellen und einen Dateispeicher zu erstellen, der anstelle Ihres Totara-Datenverzeichnisses verwendet wird.
- Wenn Sie kein schnelleres Laufwerk zur Verfügung haben, haben Sie viel freien Speicherplatz. Eine kleine Partition auf dem Laufwerk, das Sie installiert haben und das ein leistungsorientiertes Dateisystem verwendet, könnte es sich lohnen, eine Aufnahme zu machen. Viele Linux-Installationen verwenden heutzutage beispielsweise EXT4, ein schönes Dateisystem, das jedoch aufgrund von Journaling-Vorfällen über Overhead verfügt.
- Die Erstellung einer Partition und die Verwendung eines leistungsoptimierten Dateisystems kann Ihnen den geringen Boost geben, den Sie suchen. Denken Sie daran, dass Cache-Speicher so konzipiert sind, dass sie volatil sind, und die Wahl eines Dateisystems für einen Cache ist eine andere Entscheidung als die Wahl eines Dateisystems für Ihren Server.
- Und wenn Sie bereit sind, auf Längen zu gehen und eine Fülle von Speicher auf Ihrem Server zu haben, könnten Sie in Betracht ziehen, eine Ramdisk/tmpfs zu erstellen und auf diesen zu verweisen. Der reine Speicher ist genauso volatil wie der Cache, und die Leistung des Dateisystems wird einfach nicht viel besser werden.
Was auch immer Sie wählen, denken Sie daran, es wiederholt zu testen. Achten Sie auf Ihre Entscheidung.
Memcache
Bevor Sie eine Memcache Store-Instanz hinzufügen können, müssen Sie zunächst einen Memcached-Server haben, auf den Sie zugreifen können, und die Memcache PHP-Erweiterung auf Ihrem Webserver installiert und aktiviert haben.
Wie der Dateispeicher müssen Sie den Namen des Speichers angeben. Sie wird verwendet, um die Store-Instanz in der Konfigurationsschnittstelle zu identifizieren und muss eindeutig für die Website sein.
Für einen Memcache-Speicher müssen Sie auch den Memcache-Server oder die Server eingeben, die Sie verwenden möchten. Server sollten einen pro Zeile hinzufügen und jede Zeile kann ein bis drei Eigenschaften enthalten, die durch Doppelpunkte getrennt sind.
- Die URL oder IP-Adresse des Servers (erforderlich).
- Der Port, auf dem der Server zuhört (optional).
- Die Gewichtung für diesen Server (optional).
Wenn beispielsweise zwei Memcached-Instanzen auf Ihrem Server ausgeführt werden, eine für den Standardport und eine für 11212 konfiguriert ist, würden Sie Folgendes verwenden:
127.0.0.1127.0.0.1:11212Optional können Sie auch ein Schlüsselpräfix angeben. Was Sie hier eingeben, wird allen Schlüsseln vor dem Zugriff auf den Server vorangestellt und kann verwendet werden, um den Memcache-Raum auf erkennbare Weise effektiv zu partitionieren. Dies kann hilfreich sein, wenn Sie ein Management-Tool für Ihren Memcached-Server haben, das Sie verwenden, um zu überprüfen, was dort gespeichert ist.
Wichtige Hinweise zur Implementierung
Die Memcache-Erweiterung bietet keine Möglichkeit, einen Satz von Einträgen zu löschen. Entweder wird ein einzelner Eintrag gelöscht oder alle Einträge werden gelöscht. Aus diesem Grund ist es wichtig zu beachten, dass beim Bereinigen eines Memcache-Speichers in Totara alle Einträge im Memcache-Backend gelöscht werden. Nicht nur die, die sich auf Totara beziehen. Aus diesem Grund wird dringend empfohlen, dedizierte Memcached-Server zu verwenden und keine andere Software für die Verwendung dieser Server zu konfigurieren. Dies kann zu Leistungsabwertungen und negativen Auswirkungen führen.
Wenn Sie Memcache für das Caching und für Sitzungen in Totara verwenden möchten, müssen Sie zwei Memcached-Server verwenden. Eine für Sitzungen und eine für das Caching. Andernfalls werden Ihre Sitzungen durch eine Cache-Bereinigung in Totara gelöscht.
Eingebettet
Wie der Memcache Store müssen Sie zunächst einen Memcached-Server haben, auf den Sie zugreifen können, und die Memcached PHP-Erweiterung auf Ihrem Server installiert und aktiviert haben.
Ebenso wie der Memcache-Speicher gibt es zwei erforderliche Parameter für die Konfiguration eines Memcached-Speichers, den Namen des Speichers und den Server. Es gibt auch mehrere optionale Parameter, die Sie beim Erstellen eines Memcached-Speichers festlegen können.
Einstellung | Beschreibung | Hinweise |
|---|---|---|
Name des Stores | Sie wird verwendet, um die Store-Instanz in der Konfigurationsschnittstelle zu identifizieren und muss eindeutig für die Website sein. | - |
Server | Die Server, die dieser Cache-Speicher verwenden soll. Details finden Sie unten. Server sollten einen pro Zeile hinzufügen und jede Zeile kann ein bis drei Eigenschaften enthalten, die durch Doppelpunkte getrennt sind.
| Wenn beispielsweise zwei Memcached-Instanzen auf Ihrem Server ausgeführt werden, eine für den Standardport und eine für 11212 konfiguriert ist, würden Sie Folgendes verwenden: 127.0.0.1 127.0.0.1:11212 |
Komprimierung verwenden | Standardmäßig auf wahr, kann aber deaktiviert werden, wenn Sie möchten. | - |
Serialisierung verwenden | Ermöglicht die Auswahl des Serialisators für die Kommunikation mit dem Memcache-Server. | Standardmäßig bieten die Memcached-Erweiterung und PHP nur eine serialisierte, aber es stehen einige andere zur Installation zur Verfügung, wenn Sie sie suchen. Eins ist zum Beispiel das Igbinar, das unter https://github.com/igbinary/igbinary. |
Präfix-Schlüssel | Hier können Sie einige Zeichen festlegen, die allen Schlüsseln vor der Interaktion mit dem Server vorangestellt werden. | - |
Hash-Methode | Die von der Memcached-Erweiterung bereitgestellte Hash-Methode wird hier standardmäßig verwendet. Sie können jedoch eine Alternative wählen, wenn Sie möchten. | Weitere Informationen zu den verfügbaren Optionen finden Sie im PHP-Handbuch. Wenn Sie möchten, können Sie auch die Standard-Hash-Funktion überschreiben, die PHP in Ihrer php.ini verwendet. |
Puffer schreibt | Standardmäßig deaktiviert. Das Aktivieren von gepufferten Schreibvorgängen minimiert die Interaktion mit dem Memcached-Server durch das Puffern von io-Vorgängen. Der Nachteil ist, dass es in einem System mit einer beliebigen Gleichzeitigkeit eine gute Chance gibt, dass mehrere Anfragen die Daten generieren, da niemand sie auf dem Memcached-Server gespeichert hat, als er sie zum ersten Mal angefordert hat. Diese Option kann für Cache-Speicher von Vorteil sein, auf die nur in fähigkeitskontrollierten Bereichen zugegriffen wird, z. B. wenn mehrere Interaktionen Netzwerkressourcen oder dergleichen belasten. Aber das ist definitiv am extremen Optimierungsende der Skala. |
Wichtige Hinweise zur Implementierung
Die Erweiterung Memcached bietet keine Möglichkeit, einen Satz von Einträgen zu löschen. Entweder wird ein einzelner Eintrag gelöscht oder alle Einträge werden gelöscht.
Aus diesem Grund ist es wichtig zu beachten, dass beim Löschen eines Memcached-Speichers in Totara alle Einträge im Memcached-Server gelöscht werden. Nicht nur die, die sich auf Totara beziehen.
Aus diesem Grund wird dringend empfohlen, dedizierte Memcached-Server zu verwenden und keine andere Software für die Verwendung derselben Server zu konfigurieren. Dies kann zu Leistungsabwertungen und negativen Auswirkungen führen.
Wenn Sie Memcached für das Caching und für Sitzungen in Totara verwenden möchten, ist es ebenfalls wichtig, zwei Memcached-Server zu verwenden. Eine für Sitzungen und eine für das Caching. Andernfalls werden Ihre Sitzungen durch eine Cache-Bereinigung in Totara gelöscht.
MongoDB
MongoDB ist eine Open-Source-Dokumenten-orientierte NoSQL-Datenbank. Weitere Informationen finden Sie auf der Website www.mongodb.org.
Einstellung | Beschreibung | Hinweise |
|---|---|---|
Name des Stores | Wird verwendet, um die Store-Instanz in der Konfigurationsschnittstelle zu identifizieren und muss eindeutig für die Website sein. | - |
Server | Dies ist der Verbindungsstring zum Server, den Sie verwenden wollen. Mehrere Server können mithilfe einer durch Kommas getrennten Liste angegeben werden. | - |
Datenbank | Der Name der Datenbank, die verwendet werden soll. | - |
Nutzername | Der Benutzername, der beim Herstellen einer Verbindung verwendet wird. | - |
Passwort | Das Passwort des Nutzers, der für die Verbindung verwendet wird. | - |
Replika-Set | Der Name des Hosts, der für die Verbindung mit der Datenbank benutzt wird. Wenn dies eingetragen wird erfolgt der Zugriff auf die Datenbank über die Definition des ismaster-Befehls. Damit wird die Verbindung hergestellt zu einer Datenbank- Instanz, die hier nicht aufgeführt ist. | - |
Sichere Verwendung | Wenn diese Option aktiviert ist, wird die Option „Sicher verwenden“ während der Einfüge-, Abruf- und Entfernungsvorgänge verwendet. Wenn Sie ein Replikat festgelegt haben, wird dies trotzdem erzwungen. | - |
Sicheren Wert verwenden | Sie können für die sichere Verwendung einen spezifischen Wert festsetzen. Dies bestimmt die Anzahl der Server, auf denen die Vorgänge abgeschlossen sein müssen, bevor sie als abgeschlossen gelten. | - |
Erweiterte Tasten verwenden | Wenn diese Option aktiviert wird, wird durch das Plugin mit voller Schlüssellänge gearbeitet. Dies wird noch nicht intern verwendet, aber es würde Ihnen ermöglichen, das MongoDB-Plugin auf einfache Weise manuell zu durchsuchen und zu untersuchen, wenn Sie dies wünschen. Wenn Sie diese Option aktivieren, wird ein kleiner Overhead hinzugefügt. Dies sollte nur dann erfolgen, wenn Sie es benötigen. | - |
Redis
Redis ist ein Open Source In-Memory-Datenstrukturspeicher, der für das Caching oder als Datenbank verwendet werden kann. Weitere Informationen finden Sie auf der Redis-Website.
| Einstellung | Beschreibung | Hinweise |
|---|---|---|
Server | Hiermit wird der Hostname oder die IP-Adresse des Redis-Servers festgelegt. | - |
Passwort | Hiermit wird das Passwort des Redis-Servers festgelegt. | Wenn Sie Redis als Sitzungsspeicher verwenden möchten, müssen Sie die richtigen Werte in der Konfigurationsdatei ($CFG->session_redis_*) festlegen. Weitere Details finden Sie in der Datei config-dist.php. |
Schlüssel-Präfix | Dieses Präfix wird für alle Schlüsselnamen auf dem Redis-Server verwendet. Wenn Sie nur eine Totara-Instanz mit diesem Server verwenden, können Sie diesen Wert als Standard beibehalten. | Aufgrund von Beschränkungen der Schlüssellänge sind maximal fünf Zeichen erlaubt. |
Serializer verwenden | Gibt den Serialisierungsserver an, der für die Serialisierung verwendet werden soll. Die gültigen Serialisierungsgeräte sind entweder der Standard-PHP-Serialisierungsgerät oder der igbinäre Serialisierungsgerät. Letzteres wird nur unterstützt, wenn es im System korrekt konfiguriert wurde (weitere Informationen finden Sie im Abschnitt Verwenden des igbinären Serialisators). | - |
Verwenden des igbinären Serialisierers
Der igbinäre Serialisierer speichert Datenstrukturen in kompakter binärer Form und Einsparungen können für die Speicherung serialisierter Daten erheblich sein.
Der igbinäre Serialisator ist nicht Teil einer Standard-PHP-Verteilung, kann aber optional installiert werden. Sie können es über GitHub oder PECL abrufen.
Redis Cache-Speicher
Wenn igbinary installiert ist, können Sie bei der Konfiguration des Redis Cache-Speichers den Serialisator auswählen. Es wird standardmäßig auf den Standard-PHP-Serialiser gesetzt, kann aber auf igbinär umgestellt werden.
Statischer Cache-Speicher
Der statische Cache-Speicher verwendet automatisch den igbinären Serialiser, wenn er installiert ist. Es gibt keine Einstellungs- oder Konfigurationsoption zum Aktivieren oder Deaktivieren.
Redis-Sitzungs-Handler
Wenn igbinary installiert ist und $CFG->session_redis_serializer_use_igbinary auf true gesetzt ist, verwendet der Redis Session Handler igbinary für die Serialisierung der Daten.
Einzelne Instanzen im Vergleich zu mehreren Instanzen
Wenn eine einzelne Speicherinstanz dem Cache zugeordnet ist, geschieht Folgendes:
- Daten aus dem Cache abrufen Totara bittet den Cache, die Daten abzurufen.
- Der Cache versucht, ihn aus dem Store zu beziehen.
- Wenn der Speicher ihn hat, wird er im Cache und der Cache Totara zur Verfügung gestellt, damit er die Daten verwenden kann.
- Wenn der Store keinen Fehler hat, wird ein Fehler zurückgegeben und Totara muss die Daten generieren und sie höchstwahrscheinlich dann an den Cache senden.
- Beim Speichern von Daten im Cache fordert Totara den Cache auf, einige Daten zu speichern, und der Cache gibt sie an den Cache-Speicher weiter.
Wenn mehrere Speicherinstanzen dem Cache zugeordnet sind, geschieht Folgendes:
- Daten aus einem Store beziehen Totara bittet den Cache, die Daten zu erhalten.
- Der Cache versucht, ihn aus dem ersten Store zu beziehen.
- Wenn der erste Speicher ihn hat, gibt er die Daten an den Cache zurück und der Cache gibt sie an Totara zurück.
- Wenn der erste Store nicht über die Daten verfügt, versucht er, die Daten aus dem zweiten Store zu erhalten.
- Wenn der zweite Store ihn hat, gibt er ihn an den ersten Store zurück, der ihn dann selbst speichert, bevor er in den Cache zurückkehrt.
- Wenn das nicht der Fall ist, wird der nächste Store genutzt.
- Dies wird fortgesetzt, bis entweder die Daten gefunden werden oder es keine Stores mehr gibt, die überprüft werden müssen.
- Beim Speichern von Daten im Cache fordert Totara den Cache auf, einige Daten zu speichern. Der Cache gibt sie jedem zugeordneten Cache-Speicher zur Speicherung.
Der Hauptvorteil der Zuweisung mehrerer Speicher besteht darin, dass Sie Cache-Redundanz einführen können. Natürlich führt dies zu einem Overhead und sollte daher nur verwendet werden, wenn dies tatsächlich erforderlich ist. Im Folgenden finden Sie ein Beispiel dafür, wann die Zuordnung mehrerer Stores einen Vorteil bieten kann.
Szenario
Problem: Sie haben einen Webserver mit einer Totara-Website sowie anderen Websites. Sie haben auch einen Memcache-Server, der von mehreren Websites verwendet wird, einschließlich Totara. Memcache verfügt über einen Cache mit begrenzter Größe, der, wenn er voll ist und zur Speicherung weiterer Informationen aufgefordert wird, Speicherplatz freigibt, indem die am wenigsten verwendeten Cache-Einträge gelöscht werden. Sie möchten Memcache für Ihre Totara-Website verwenden, da sie schnell ist. Sie sind sich jedoch bewusst, dass es zu mehr Cache-Fehlen kommen kann, da es sich um einen stark genutzten Memcache-Server handelt.
Lösung: Um dies zu umgehen, ordnen Sie zwei Stores Cache zu, die Sie Memcache verwenden möchten. Sie machen Memcache zum primären Speicher und die Standarddatei zum endgültigen Cache-Speicher.
Erklärung: Auf diese Weise haben Sie Redundanz geschaffen, wenn etwas angefordert wird. Totara versucht zunächst, es von Memcache (dem schnellsten Speicher) zu erhalten, und wenn es nicht dort ist, wird der Datei-Cache überprüft.
Nur noch ein paar weitere Sehenswürdigkeiten:
- Die Zuordnung mehrerer Cache-Speicher führt zu Overhead, je mehr Cache-Speicher zugeordnet werden, desto mehr Overhead.
- Betrachten Sie die Cache-Speicher, denen Sie zuordnen. Wenn die Daten dort bleiben, nachdem sie festgelegt wurden, dann gibt es keine Punktzuordnung mehr. Diese Technik ist in erster Linie in Situationen nützlich, in denen nicht garantiert wird, dass Daten nach der Einstellung verbleiben.
- Testen Sie immer Ihre Konfiguration. Aktivieren Sie die Anzeige von Leistungsinformationen und beobachten Sie dann, welche Stores bei der Interaktion mit Totara verwendet werden, um den Cache auszulösen.
Join the Totara Community for more resources to help you get the most out of Totara.
© Copyright 2025 Totara Learning Solutions. All rights reserved. Some content originally obtained via GPLv3 license and continues to be available under GPLv3. All other content is the sole copyright of Totara Learning Solutions.