Betreiben Sie eine verteilte SF3.3-Anwendung auf mehreren AWS EC2-Instanzen mit einem zentralen ElastiCache-Cluster (Redis).
Jede EC2-Instanz führt auch eine lokale Redis-Instanz aus, die für Doctrine-Meta und Query-Caching verwendet wird.
Diese Anwendung verwendet Doctrines Second Level Cache, was aus funktionaler Sicht sehr gut funktioniert. Aber die Leistung ist schlecht (900-1200ms Seitenladezeit) auf AWS aufgrund der mehr als 400 Cache-Aufrufe, die in unseren Länder- und VatRate-Entitäten geladen werden, die auf vielen unserer Seiten benötigt werden.
Da sich diese Land- und VatRate-Entitäten nur selten ändern, möchte ich sowohl die lokale Redis-Instanz als auch ElastiCache für das Ergebnis-Caching verwenden, indem Sie verschiedene Bereiche verwenden, die im Cache der zweiten Ebene definiert sind. Dies sollte das Latenzproblem bei den mehr als 400 Cache-Aufrufen reduzieren, da beim Laden auf einer einzigen Box die Ladezeiten unter 100 ms liegen. Das Lesen der Dokumentation scheint alles möglich zu sein, nur nicht ganz sicher, wie man es mit Symfony und PHP-Cache konfiguriert.
app / config / config.yml
%Vor%src / AppBundle / Entität / Land.php
%Vor%Quelle / AppBundle / Entity / VatRate.php
%Vor%src / AppBundle / Entität / Order.php
%Vor%app / config / config.yml
%Vor%src / AppBundle / Entität / Land.php
%Vor%Quelle / AppBundle / Entity / VatRate.php
%Vor%src / AppBundle / Entität / Order.php
%Vor%Was zu
führt %Vor%Nicht allzu sicher, wo ich von hier aus weitergehen sollte, habe ich an den Tests gearbeitet: Ссылка , aber der Mangel an Dokumentation für die Konfiguration macht es ein wenig schwieriger!
Nachdem Sie viel mit der PHP-Cache-Bibliothek experimentiert haben, sehen Sie im CacheBundle-Compiler, dass nur eine DoctrineBridge-Instanz aus der Konfiguration unterstützt wird. Ссылка
Lösung war, meinen eigenen Compiler zu erstellen, nicht hübsch, aber es scheint zu funktionieren.
src / AppBundle / DependencyInjektion / Compiler / DoctrineCompilerPass.php
%Vor%src / AppBundle / AppBundle.php
%Vor%app / config / config.yml
%Vor%Obwohl dies in gewissem Maße zu funktionieren scheint, gibt es einige Inkonsistenzen, bei denen lokale Cache-Aufrufe zu 500 Fehlern führen, wenn wahrscheinlich etwas im Cache fehlt. Insgesamt glaube ich, dass ich versuche, den Second-Level-Cache mehr zu verbiegen als geplant.
Die Fehlermeldung, die Sie erhalten, spiegelt die Ursache Ihres Problems wider. Sie übergeben DoctrineCacheBridge instances (die zugrunde liegende Klasse von doctrine.orm.default_result_cache ), wenn Instanzen der Doctrine\ORM\Cache\Region -Schnittstelle erwartet werden:
In Ihrer früheren Konfiguration wurde der doctrine.orm.default_result_cache -Cache-Service als Standard-Cache über die Einstellung region_cache_driver festgelegt. \Doctrine\ORM\Cache\DefaultCacheFactory generiert Instanzen von DefaultRegion im Flug (da keine vorkonfiguriert wurden) und füttert den Standard-Cache für sie.
Es ist zu erwarten, dass die letztere Konfiguration vorkonfigurierte Regionen hat und auf verschiedene Arten repariert werden kann. Ich schlage das nächste vor:
%Vor% Hier sagen Sie Doctrine, dass Sie 2 DefaultRegion regions unter den Schlüsseln local und remote erstellen und ihnen local_cache und remote_cache entsprechend übergeben.
Und es ist besser, region_cache_driver auf den vorherigen Wert zurückzusetzen, andernfalls DefaultRegion s, das beim Flug generiert wird, verwendet array cache: