Ist get_option () schneller als der Zugriff auf get_transient ()?

8

Heute führe ich einen Test über meine Datenbank durch, um den Geschwindigkeitsunterschied zwischen dem Zugriff auf einen Schlüssel über Optionen, benutzerdefinierte Tabellen und Transienten zu untersuchen. Ich habe den Test 1000 Mal ausgeführt und es folgt die Zeit, die benötigt wird, um 1000 get-Operationen auszuführen:

  1. get_transient() 0,0245 Sekunden
  2. get_option() 0,0068 Sekunden
  3. einfache Auswahloperation aus der benutzerdefinierten Tabelle 0,65 Sekunden

Ich habe auch überprüft, dass der Übergang während dieses Tests nicht abgelaufen ist. Die Frage ist also, ist get_option()schneller als get_transient()oder habe ich etwas in meinem Test durcheinander gebracht? Ist die Verzögerung der benutzerdefinierten Tabelle darauf zurückzuführen, dass Optionen standardmäßig von WordPress zwischengespeichert werden? Werden Optionen auch von verschiedenen Caching-Plugins wie den Transienten zwischengespeichert?

plugin-development cache transient options learning_13
quelle
Die Antwort darauf ist variabel, wobei zu berücksichtigen ist, dass Transienten bei einem Objektcache überhaupt keine Optionen verwenden. In jedem Fall ist es eine Mikrooptimierung und Zeitverschwendung. Das automatische Laden als Option verschiebt die Kosten einfach woanders hin
Tom J Nowell

Antworten:

15

Heute führe ich einen Test über meine Datenbank durch, um den Geschwindigkeitsunterschied zwischen dem Zugriff auf einen Schlüssel über Optionen, benutzerdefinierte Tabellen und Transienten zu untersuchen. Ich habe den Test 1000 Mal ausgeführt und es folgt die Zeit, die benötigt wird, um 1000 get-Operationen auszuführen:

Beachten Sie, dass die Optionstabelle auf den meisten Systemen sowohl für Optionen als auch für Transienten verwendet wird und diese Tabelle mit hinzugefügten Indizes optimiert wurde. Es ist also kein fairer Vergleich

get_transient () 0,0245 Sekunden get_option () 0,0068 Sekunden einfache Auswahloperation aus der benutzerdefinierten Tabelle 0,65 Sekunden

Dies ist auch ein unfairer Vergleich. Optionen mit dem autoloadOptionssatz werden in einer einzigen Abfrage frühzeitig in Advanced geladen. Wird get_optionalso von gezogen WP_Cache, wurde die Option bereits abgerufen.

TLDR: Die Option wird nicht abgerufen, sondern bereits abgerufen. Aufgrund der autoloadOption wird sie nur aus dem Speicher abgerufen

Ich habe auch überprüft, dass der Übergang während dieses Tests nicht abgelaufen ist.

Dies sollte sich nicht auf ein normales System beim vorübergehenden Abrufen auswirken, schließlich weiß es nicht, ob es abgelaufen ist, bis es abgerufen wurde.

Die Frage ist also, ist get_option () schneller als get_transient () oder habe ich in meinem Test etwas durcheinander gebracht?

Es hängt davon ab, ob:

  • Auf den meisten Systemen werden Transienten mithilfe von Optionen gespeichert. Beide beinhalten einen get_optionAnruf
  • Optionen mit dem autoloadWert true werden zu Beginn alle in einem einzigen Aufruf geladen, sodass sie im Speicher bleiben. Danach werden keine Abfragen mehr ausgeführt
  • Durch das Zwischenspeichern von Objekten werden sowohl automatisch geladene Optionen als auch Transienten zwischengespeichert

Ist die Verzögerung der benutzerdefinierten Tabelle darauf zurückzuführen, dass Optionen standardmäßig von WordPress zwischengespeichert werden?

Sehr gut möglich, aber wie schnell diese Auswahl dauert, hängt stark von der Abfrage und dem Tabellendesign ab

Werden Optionen auch von verschiedenen Caching-Plugins wie den Transienten zwischengespeichert?

Ja, WP_Cachewird verwendet, wodurch es für den Rest der Anforderung im Speicher gespeichert wird. Caching-Plugins können diese Werte aus Leistungsgründen beibehalten.

Wiederholbarkeit

Diese werden alle über zwischengespeichert, WP_Cachesodass beim zweiten Anfordern keine Datenbank beteiligt ist.

Variabilität und es kommt darauf an

Dies alles setzt eine gemeinsame Basis voraus, aber was ist mit Objekt-Caches?

Lassen Sie uns eine MemcacheD-Instanz oder eine Redis-Instanz einführen (ich empfehle Ihnen dringend, dies zu tun, wenn Sie die Option haben, RIESIGE Leistungsvorteile für gut erstellte Websites, insbesondere wenn Sie sie für das Zwischenspeichern von Seiten verwenden, es sei denn, Sie haben so etwas wie ein Lack-Setup).

Jetzt haben wir eine neue Situation:

  • Jetzt werden Daten im RAM gespeichert, und sobald sie aus der Datenbank abgerufen wurden, werden sie vorbereitet und die Zugriffszeiten werden drastisch reduziert. Immer noch langsamer als eine Variable, aber deutlich schneller als eine Datenbankabfrage
  • Es werden viele neue Daten gespeichert WP_Cache, die normalerweise nicht vorhanden sind. ZB WP_PostObjekte, Post-Meta usw.
  • WP_Cache bleibt nun über Anfragen hinweg bestehen
  • MemcacheD usw. können abgelaufene Transienten usw. Beseitigen

Transienten und Optionen haben jetzt die gleichen Zugriffskosten. Sie waren bereits in der Nähe, aber sie sind jetzt vernachlässigbar und haben mehr mit der CPU-Auslastung zum Zeitpunkt der Anforderung zu tun.

Sollte ich für die Leistung Transienten oder Optionen verwenden?

Die Frage ist zwar eine würdige Frage, aber die Antwort lautet, dass der Unterschied vernachlässigbar ist und innerhalb der Fehlergrenzen liegt

es ist nicht so einfach

Stoppen Sie also die Mikrooptimierung, sie sind das gleiche Speichermedium, und dies ist Ihre Zeit nicht wert

  • Verwenden Sie Optionen, wenn Sie etwas speichern müssen, das sich auf der gesamten Website befindet
  • Verwenden Sie Transienten, um vorübergehend Dinge zu speichern, deren Berechnung teuer ist, damit Sie das nächste Mal nicht müssen

Es lohnt sich nicht, je nach Leistung einen über den anderen zu wählen. Es gibt keinen bedeutenden Unterschied.

Es gibt weitaus bessere Optimierungsmöglichkeiten, die zu erheblich größeren Einsparungen führen, z. B. die Verwendung von Taxonomien anstelle von Meta in Post-Abfragen, die Verwendung von __notStilparametern, die Ausführung weniger Dinge auf der Seite, die Installation eines Objektcaches, geringere Posts pro Seite und die Vermeidung von Remote-Anforderungen usw

Was ist mit einer benutzerdefinierten Tabelle, die ...

Nein, die Optionstabelle ist bereits gut optimiert. Wenn Sie eine benutzerdefinierte Tabelle verwenden, werden Vorgänge einfach außerhalb des WP-Caching-Systems verschoben, sodass Sie gezwungen sind, Ihre eigenen zu schreiben

Tom J Nowell
quelle
In Bezug auf die Option wird es in meinem Fall automatisch geladen. Die benutzerdefinierte Tabelle enthält nur zwei Zeilen und eine Auswahlabfrage zum Abrufen von Daten.
learning_13
Ich mache das für mein Plugin und muss mich zwischen einem von ihnen entscheiden. Die benutzerdefinierte Tabelle war gemäß meinem Entwurf am einfachsten zu implementieren, aber die Abrufkosten sind groß genug, um das Laden der Seite zu verzögern.
learning_13
2
@ learning_13, Sie haben die falsche Frage gestellt, und vielleicht haben sowohl Tom als auch ich die Nachricht nicht in unseren Antworten enthalten. Durch korrektes Caching wird alles, was Sie für die Verwendung verwenden, für Websites, die sich um Leistung kümmern, ausreichend ausgeführt. Die Entscheidung, wie Daten gespeichert werden sollen, sollte auf der Grundlage der Struktur Ihres Plugins und seiner Funktionalität getroffen werden. Die Leistung sollte das letzte sein, über das Sie nachdenken sollten.
Mark Kaplun
2
@ aim100k, bitte bringen Sie "Eltern" nicht in die Antworten hier ein. Was Menschen für ihren Lebensunterhalt tun, sollte nicht zur Sprache gebracht werden, es sei denn, es ist für die Antwort oder Frage relevant. Wenn Ihnen eine Antwort nicht gefällt, stimmen Sie sie ab. Wenn Sie der Meinung sind, dass die Antwort technisch in Ordnung, aber anstößig ist, können Sie entweder versuchen, sie zu bearbeiten, zu kennzeichnen oder auf der Metaseite zu diskutieren.
Mark Kaplun
@ mark-kaplun, Angenommen, ich speichere Daten in der benutzerdefinierten Tabelle und rufe Daten für jedes Post-Rendering ab, bei dem mein Plugin beteiligt ist, um einige Daten anzuzeigen. Werden sich die Caching-Plugins oder die Caching-Optimierung des Benutzers um das Caching dieser Tabelle kümmern? Und werden sich die zusätzlichen Anstrengungen bei der Implementierung und beim Design ändern, nur um Transienten / Optionen zu verwenden, anstatt eine benutzerdefinierte Tabelle zu verwenden, die mehr in mein Design passt, eine Mikro- (vorzeitige) Optimierung über die Seitenladegeschwindigkeit?
learning_13
4

Wenn kein Objekt - Caching gefunden wird, get_transientruft get_optionzweimal, einmal oder das Ablaufintervall und ein für den Wert, dafür ist es nicht schneller sein wird.

get_optionDie Leistung selbst wird davon beeinflusst, ob die Option "automatisch geladen" ist (Standard) oder nicht. Alle automatisch geladenen Optionen werden in einer Anforderung für die Datenbank abgerufen und im Speichercache gespeichert. Daher sollte es nur sehr geringe Auswirkungen darauf haben, wie oft Sie aufrufen, get_optionselbst wenn es sich um verschiedene Optionen handelt.

Wenn Sie direkt auf die Datenbank zugreifen, umgehen Sie alle Caching- und anderen Leistungsverbesserungen. Es wird erwartet, dass diese langsamer sind, es sei denn, Sie implementieren selbst eine intelligente Logik.

Trotzdem bin ich mir nicht sicher, ob Ihr Test gut war, aber unabhängig davon ist die gesamte Diskussion sinnlos, als ob Sie sich wirklich für die Leistung interessieren. Sie werden ein Objekt-Cache-System (und das entsprechende Plugin) verwenden, das die Datenzugriffszeit viel näher bringt auf Null ... und wenn Sie sich entscheiden, Ihre eigenen DB-Tabellen zu verwenden, sollten Sie natürlich Ihre Zugriffs-APIs in den Objekt-Caching-Mechanismus integrieren.

Mark Kaplun
quelle