Jetzt muss ich euch beide nochmal fragen, welche Versionen von Phpfastcache ihr jeweils aktuell einsetzt?
[...]
Hallo zusammen, das ist als erster Beitrag vielleicht etwas viel, aber vielleicht kann ich von technischer Seite etwas unterstützen.
Vorab vielen Dank für die Unterstützung!
Ich bin der Webhoster von @CBaumi02 und hatte auf Serverseite die Versuche gemacht mit Unterstützung von @fiveBytes und @Karsta.
Das Redis Modul von @GTB für den Shop hatte ich bestellt und eingesetzt (Um die Performance zu verbessern und die SSDs von den Cachewrites zu entlasten).
@Tomcraft: sollen wir das Thema vielleicht in einen eigenen Thread verlagern um diesen nicht zu kapern?
@Karsta: Welche Version genau des PhpFastCache war für @CBaumi02 bereitgestellt ich sehe leider nur die API Version 4.3.0 in den Quellen?
Das Problem selbst scheint allerdinge unabhängig der beiden FastCache Versionen aufzutreten, in der neueren Version ist aber ein Errorhandling implementiert, so dass man die "unserialize" und "corrputData" Fehler sehen kann, die mitgelieferte Version hat nur ein leeres return (= die "weißen Seiten" ) geliefert.
In der Redis Datenbank gibt es folgendes Phänomen mit eingeschaltetem DB-Cache:
Die Einträge _TAG_db und TAG_database scheinen doppelt vorhanden zu sein, haben den gleichen Inhalt und wachsen durchgängig weiter an, auch wenn die entsprechenden Keys schon nach Ablauf der Lifetime/des Expires aus der Redis Datenbank aufgeräumt wurden.
Hier scheint ein Aufräum-Mechanismus für die _TAG_db zu fehlen oder fehlzuschlagen. (passiert mit der mitgelieferten und der neueren PhpFastCache Version gleichermaßen)
Damit wird der serialized array in _TAB_database immer größer und vor allem die Cache writes immer langsamer.
Vielleicht hat jemand oder sogar @GTB eine Idee oder ein anderer Benutzer der Redis einsetzt kann das gegentesten.
Ansonsten wird bei knapp 100‘000 Cache Keys (Einträgen) das _TAG_database Feld auch schon allein 5MB groß und bei jedem neuen Cache Eintrag dann ausgelesen, erweitert und neu serialized geschrieben,
die Aufrufe werden dann quälend langsam durch die häufigen und riesigen serialize Aufrufe, mal von der CPU Last ganz abgesehen.
Ich bin kein Programmierer, aber ggf. passiert beim FileCache etwas ähnliches und es wird dort aus einem ähnlichen Grund auch voll oder gibt Dopplungen von IDs bei hoher Last, so dass die beiden Variablen
protected bool $secureFileManipulation = true; protected bool $preventCacheSlams = true;
zwar die Auswirkung mitigieren, aber das Problem nicht beheben.
( In unserem Fall hat die secureFileManipulation = true gereicht, um die "weißen Seiten" zu beheben, dadurch wurde der Filecache aber auch sehr langsam, insofern vermute ich da ein unterliegendes Problem )
Falls ich irgendwie unterstützen kann oder Logs/Tests liefern, lasst es mich gern wissen!
Viele Grüße,
Patrick