Persistente Objekte in WordPress/PHP

Lesezeit: 4 Minuten

Persistente Objekte in WordpressPHP
Ken

Ich möchte eine Reihe von persistenten Objekten erstellen, die ihren Zustand aus der Datenbank laden und dann im Speicher für WordPress/PHP-Seitenladevorgänge gespeichert werden, um sie als zwischengespeicherte Speicherobjekte zu verwenden. Ich würde mir vorstellen, dass eine Schnittstelle für diese Objekte Folgendes enthält:

  • initialise() – Lade den Zustand aus der Datenbank und führe alle anderen Initialisierungsfunktionen aus, die vor der Bearbeitung von Anfragen benötigt werden
  • getter_foo() – eine Reihe von Getter-Methoden für PHP-Code zum Abrufen von im Speicher zwischengespeicherten Antworten
  • getter_bar() – eine Reihe von Getter-Methoden für PHP-Code zum Abrufen von im Speicher zwischengespeicherten Antworten
  • update() – wird von zeit- oder ereignisgesteuerten Prozessen aufgerufen, die das Objekt auffordern, zur Datenbank zurückzukehren und seinen Status zu aktualisieren

Die zwei Tricks, die ich vermute, sind:

  1. Lassen Sie den Haupt-PHP-Prozess die Speicherreferenz für diese Objekte zuweisen und halten, damit sie über Webtransaktionen/Anfragen hinweg im Speicher fixiert bleiben, ohne jedes Mal gegen die Datenbank neu initialisiert werden zu müssen
  2. Einen Mechanismus haben, der es den Transaktionsprozessen ermöglicht, einen Zeiger auf diese Objekte zu erhalten.

Gibt es Beispiele für Lösungen, die dies tun? Ich programmiere seit Jahren, bin aber sowohl in WordPress als auch in PHP sehr neu, also ist das vielleicht ganz einfach. Nicht sicher. Jedenfalls erkenne ich an, dass technische Lösungen gefallen redis und Zwischenspeicher könnte ähnliche Ziele erreichen, jedoch auf weniger elegante und nicht kontextbezogene Weise. Das heißt, wenn es keinen einfachen Weg gibt, wende ich gerne die 80/20-Regel an. :^)

  • Haben Sie sich mit der Serialisierung beschäftigt? php.net/manual/en/function.serialize.php Dies ist im Allgemeinen eine gute Möglichkeit, den Objektstatus zwischen Anforderungen beizubehalten

    – Mahn

    14. Mai 2012 um 12:43 Uhr

Es ist nicht möglich, Daten während einer Anfrage im Speicher zu speichern und sie dann während einer anderen Anfrage mit nichts anderem als einfachem PHP aus dem Speicher zurückzulesen. Sicher, der PHP-Prozess verwendet Speicher, aber sobald Ihre Anfrage abgeschlossen ist, wird dieser Teil des Speichers bereinigt. Dies bedeutet, dass eine zweite Anforderung nicht erneut auf diesen vorherigen Teil des Speichers zugreifen kann.

Was Sie andeuten, nennt sich Caching. Einfach ausgedrückt bedeutet Caching, dass Sie die Ausgabe einer teuren Transaktion zur späteren Wiederverwendung speichern, um die Kosten dieser Transaktion zu sparen. Was Sie dann als Backend verwenden, um diese Ausgabe zu speichern, liegt bei Ihnen oder dem, was Sie zur Verfügung haben. Wenn Sie es im RAM speichern möchten, benötigen Sie etwas wie Memcached. Sie könnten es auch in einer normalen Datei speichern, aber das ist langsamer, da auf die Festplatte zugegriffen wird.

  • Danke Miljar. Mir sind memcached und redis bekannt. Ich werde sie wahrscheinlich verwenden, hatte aber auf einen Mechanismus gehofft, wie ich ihn beschrieben habe, da er gegenüber infrastrukturelleren Lösungen wie Memcached/Redis einige nette Vorteile haben kann.

    – Ken

    15. Mai 2012 um 23:11 Uhr

  • Ich denke, wenn Sie Recht haben, dass dies nicht möglich ist, bedeutet dies auch, dass es keine Möglichkeit gibt, eine Datenbankverwaltungsebene aufzubauen, die einen Pool offener Verbindungen zur Datenbank aufrechterhält. Es sei denn, WordPress ist schlau genug, dies selbst zu tun? Auf Websites mit hohen Transaktionszahlen ist dies ein großer Vorteil, da Sie in der Lage sind, Verbindungen aufrechtzuerhalten und auch Bind-Variablen besser wiederzuverwenden.

    – Ken

    15. Mai 2012 um 23:12 Uhr


  • Es ist möglich, eine offene Verbindung in einer Anfrage gemeinsam zu nutzen. Aber ich habe noch nie davon gehört, es über mehrere Anfragen hinweg zu teilen. Wenn Sie so viele Lesevorgänge aus Ihrer DB haben, würde ich versuchen, die Ergebnisse Ihrer Abfrage in Memcache zwischenzuspeichern und ein Master-Slave-Setup für Ihre Datenbank mit einem Pool von Slaves zum Lesen in Betracht ziehen.

    – Miljar

    16. Mai 2012 um 7:41 Uhr

  • Ich denke, Sie haben wahrscheinlich Recht, Miljar. In einigen der wirklich großen Apps, an denen ich im Laufe der Jahre beteiligt war, war das Teilen von Pool-Verbindungen von großem Wert, aber das alles war in einer Zeit vor Memcache.

    – Ken

    23. Mai 2012 um 7:09 Uhr


  • Die Vorteile waren zweifach: (1) Die Kosten für das Öffnen und Schließen von Verbindungen zwischen der Geschäftslogik und den Datenspeicherebenen waren hoch und (2) die Datenbank musste eine Erklärung für ähnlich strukturierte Abfragen ausführen, anstatt Bindevariablen zu verwenden, um diesen Overhead zu vermeiden . Ich vermute, dass Sie mit Memcached mit sehr wenig Aufwand eine 80/20-Regel erreichen, sodass es weniger Fälle gibt, in denen es sinnvoll ist, den Aufwand in den letzten 20 % des Kontinuums aufzuwenden. Ich schließe diese Frage vorerst. Danke für deinen Beitrag.

    – Ken

    23. Mai 2012 um 7:11 Uhr

996010cookie-checkPersistente Objekte in WordPress/PHP

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy