Wir haben eine laufende Anwendung auf Basis von Symfony 3.2 (damals mit Symfony 2.3 gestartet) und Doctrine ORM 2.5 und es ist großartig, wie sich die Dinge entwickelt haben.
Ich lese viel über die neue Symfony Cache-Komponente, die Ups und Downs von APC und APCU, Opcache, die Pull-Anfragen für Chaching in Symfony etc ... aber um ganz ehrlich zu sein, hast du mich diesmal ein bisschen verloren.
So frage ich freundlich, ob man mich in 1) verstehen und 2) Caching für eine "Standard" Symfony / Doctrine-Anwendung in der Produktion implementieren kann.
Voraussetzungen / Annahmen
1) opcache sollte aktiviert und aktiv sein und alles, was mit Bytecode zusammenhängt, zwischenspeichern.
2) Ich habe derzeit keine Anforderung, meine eigenen App-Sachen zu cachen. Es geht um das Framework-Caching wie Annotationen, Klassenzuordnungen, Validierungen, ORM-Metadaten usw.
2) Die meisten Entwickler möchten sich nicht mit mehr als einem Caching-Provider beschäftigen, sei es APCu, xcache, redis, memcache oder irgendetwas anderes. Es könnte sehr gute Gründe geben, verschiedene für verschiedene Aufgaben zu haben, aber bleiben wir bei einem, um es einfach zu halten.
Caching-Optionen in einer "Standard" Symfony / Doctrine-Anwendung im Prod-Modus
1) Klassenladen
Wir haben immer noch ApcClassLoader in app.php :
Es gibt nur zwei Optionen, die in meinem Verständnis enthalten sind, ApcClassLoader und XcacheClassLoader. Dies könnte also der obigen Annahme 2 widersprechen.
Frage:
Ist es noch erforderlich / benötigt / Leistung erheblich besser, diese ClassLoaders im Cache zu haben?
Oder reicht es, die Standard App.php heutzutage zu benutzen?
%Vor%2) Validierungscaching
Wir haben das immer noch in unserem config_prod.yml :
Frage:
Um ganz ehrlich zu sein habe ich keine Ahnung, ob dies mit Symfony 3.2 und der neuen Cache-Komponente noch immer zutrifft. Und wie man es bei Bedarf zu einem anderen Cache-Provider ändert. Wie kann ich es ändern, um mit Symfony 3.2 Cache auf dem neuesten Stand zu sein?
3) Doktrin-Caching:
Mehr oder weniger dieselbe Frage gilt für den Doktrin-Orm-Abschnitt in config_prod.yml :
Frage :
Ist das immer noch der richtige Weg? Wie man das ändert, benutze die neue Symfony Cache Komponente - kann das trotzdem gemacht werden?
4) Neue Optionen?
Was ist mit dem Neuen? Optionen? Einstellung in config_prod.yml :
Frage :
Welche Art von Informationen wird hier von wem zwischengespeichert und ersetzt / erweitert sie einige der obigen Themen?
Um es zusammenzufassen:
Ich möchte grundsätzlich alle meine prod-Konfigurationen so ändern, dass sie mit Symfony 3.2 kompatibel sind, und ich möchte redis für das Caching (Ersetzen von apc) verwenden, wo immer es möglich ist, aber ich habe absolut keine Ahnung, wie und wo ich anfangen soll.
**** EDIT ****
Wie spielen Symfony Cache Component und DoctrineCacheBundle in diesem Zusammenhang zusammen? Ersetzen? Summieren? Auf etwas aufbauen? Zusammen arbeiten? Widersprüchlich? Nicht vergleichbar?
Die Leistungsdokumentation von Symfony ist veraltet. Wir haben es mit einem anderen Commiter aktualisiert, aber die Pull-Anforderung wartet immer noch auf ihre Genehmigung. Ich kopiere einfach den neuen Doc hier. Sie finden die GitHub Pull-Anfrage hier
Verwenden Sie den OPcache-Bytecode-Cache
OPcache speichert die kompilierten PHP-Dateien, um zu vermeiden, dass sie für jede Anfrage neu kompiliert werden müssen. Es gibt einige Byte-Code-Caches, aber ab PHP 5.5 wird PHP mit integriertem OPcache ausgeliefert. Für ältere Versionen ist der am weitesten verbreitete Bytecode-Cache APC.
Konfigurieren Sie OPcache für maximale Leistung
Die standardmäßige OPcache-Konfiguration ist nicht für die Symfony-Anwendung geeignet. Daher wird empfohlen, diese Einstellungen wie folgt zu ändern:
%Vor%Überprüfen Sie keine PHP-Zeitstempel
Auf Produktionsservern sollten PHP-Dateien niemals geändert werden, es sei denn, eine neue Anwendungsversion wird bereitgestellt. Standardmäßig überprüft OPcache jedoch, ob zwischengespeicherte Dateien ihren Inhalt seit dem Zwischenspeichern geändert haben. Diese Überprüfung führt zu einigen Gemeinkosten, die wie folgt vermieden werden können:
%Vor%Hinweis
Der OPcache unterscheidet sich für den Webserver und die Befehlskonsole. Sie können den Webserver-OPcache nicht löschen, indem Sie einen Befehl in Ihrem Terminal ausführen. Sie müssen entweder den Webserver neu starten oder die Funktion opcache_reset () über den Web-Server aufrufen (d. H. Indem Sie dies in einem Skript ausführen, das Sie über das Web ausführen).
Konfigurieren Sie den PHP-Realpath-Cache
Wenn ein relativer Pfad in seinen realen und absoluten Pfad umgewandelt wird, speichert PHP das Ergebnis zwischen, um die Leistung zu verbessern. Die Standardkonfiguration dieses Caches eignet sich nicht für Anwendungen, die viele PHP-Dateien wie Symfony öffnen. Es wird empfohlen, diese Einstellungen wie folgt zu ändern:
%Vor%Konfigurieren Sie den PHP-Realpath-Cache
PHP verwendet einen internen Cache, um das Ergebnis der Zuordnung von Dateipfaden zu ihren realen und absoluten Dateisystempfaden zu speichern. Dies erhöht die Performance für Anwendungen wie Symfony, die viele PHP-Dateien öffnen, besonders auf Windows-Systemen.
Standardmäßig legt PHP eine realpath_cache_size von 16K fest, die für Symfony zu niedrig ist. Erwägen Sie, diesen Wert mindestens auf 4096 K zu aktualisieren. Darüber hinaus werden gecachte Pfade standardmäßig nur für 120 Sekunden gespeichert. Erwägen Sie auch, diesen Wert mithilfe der Option realpath_cache_ttl zu aktualisieren:
Composer Autoloader optimieren
Der beim Entwickeln der Anwendung verwendete Klassenlader ist optimiert, um neue und geänderte Klassen zu finden. Auf Produktionsservern sollten PHP-Dateien niemals geändert werden, es sei denn, eine neue Anwendungsversion wird bereitgestellt. Daher können Sie die Autoloader-Optimierung von Composer verwenden, um die gesamte Anwendung einmal zu scannen und eine "Klassenzuordnung" zu erstellen, die eine große Auswahl der Speicherorte aller Klassen darstellt und in vendor / composer / autoload_classmap.php .
Führen Sie diesen Befehl aus, um die Klassenzuordnung zum Zeitpunkt der Installation zu generieren (und damit auch Teil Ihres Bereitstellungsprozesses zu machen):
%Vor% --no-dev Schließt die Klassen aus, die nur in der Entwicklungsumgebung benötigt werden (z. B. Tests).
--optimize-autoloader Löscht jede PSR-0- und PSR-4-kompatible Klasse, die in Ihrer Anwendung verwendet wird.
--classmap-authoritative Verhindert, dass Composer das Dateisystem nach Klassen durchsucht, die nicht in der Klassenzuordnung gefunden wurden.
--apcu-autoloader Sie müssen die APCu PHP-Erweiterung installieren, um diese Option zu verwenden. Es wird die Classmap in APCu zwischenspeichern. Es wird jedoch nicht die Classmap generieren, also müssen Sie sie immer mit --optimize-autoloader
Tipp
Wenn Ihr Produktionsserver weiterhin die ältere APC-PHP-Erweiterung anstelle von OPcache verwendet, installieren Sie die APCu-Polyfill-Komponente in Ihrer Anwendung, um die Kompatibilität mit APCu-PHP-Funktionen zu aktivieren und die Unterstützung für erweiterte Symfony-Funktionen wie den APCu-Cache-Adapter freizugeben. p>
Hinweis
Wenn Sie beim APCu Autoloader neue Klassen hinzufügen, werden diese automatisch gefunden und alles funktioniert genauso wie zuvor (d. h. kein Grund, den Cache zu löschen). Wenn Sie jedoch den Speicherort eines bestimmten Namespaces oder Präfixes ändern, müssen Sie den APCu-Cache leeren. Andernfalls sucht der Autoloader immer noch nach dem alten Speicherort für alle Klassen in diesem Namespace.