DB Cache

[Schreinermeister]

index.html und .htaccess sind vorhanden.

Dobbelte Dateien konnte ich nicht finden.

Ich versuche mal zu prüfen ob nach 24h Files gelöscht werden.

Gruß Chris

[ambi]

Hallo NoRiddle

Habe das heute früh nochmal getestet sowohl Local wie im Live Shop (aktuelle Version)

Ich leere den Ordner Cache über die Admin Oberfläche (.htacces und Index bleiben) und stelle die DB-Cache Lebenszeit auf 60 Sek. Klicke mich dann wild durch den Shop. Im Cache Ordner werden dann ca. 1000 Dateien (txt) angelegt. Dann warte ich 2 Minuten und klicke nur auf einen Artikel. Es werden ca. 70% aller txt Dateien gelöscht und es sind nur txt Dateien mit aktueller Zeit im Cache Ordner – super.
Ich wiederhole das Spielchen und lege wieder durch wildes klicken durch den Shop ca. 1000 Dateien an. Ich warte wieder 2 Minuten und klicke auf einen Artikel.  Dann werden leider keine Dateien mehr gelöscht und Ordner füllt sich wieder.

Somit funktioniert das nur 1x mal und egal ob ich den Code original lasse oder den von Dir übernehme, es bleibt immer gleich das es nur 1x geht???????

[noRiddle (revilonetz)]

Den Code von mir solltest du ja wieder rausnehmen weil es daran nicht liegen kann, das war lediglich ein Test.
Da es bei mir mit einem unveränderten 2.0.4.2-Shop mit Orignaldateien funktioniert vermute ich ein chmod(), ein Les-/Schreibrecht-Problem. Beim ersten Mal klappt alles und danach nicht mehr weil die Rechte geändert wurden.
Das kann man nur mit Umsicht und Genauigkeit analysieren.
Änderungsdatum eines Files vergleichen, expired_time im File vergleichen, Rechte vergleichen.

Wenn ich bei mir das Verzeichnis /cache/ händisch auf Rechte 644 setze sind nach einem Aufruf einer beliebigen Frontend-Seite des Shops die Rechte auf 744 gestellt. Nach der verwendeten Config sollte es jedoch 777 sein. Das heißt, es gibt Server-Konfigurationen die das Ändern von Lese- und Schreibrechten nur begrenzt zulassen. (Thema umask). Die Files selbst stehen auf 644, was auch ausreicht.

Fragen:
Was passiert wenn du/Ihr das /cache/-Verzeichnis manuell auf 755 stellt (unter Beibehaltung der 60 sec. damit man das gut testen kann) ?
Welche Rechte haben dann die Files ?
Beides sowohl nach dem ersten Frontend-Aufruf wie auch nach mehrmaligen Aufrufen prüfen.

Taucht irgendwann ein File namens keyword_clean_up_driver_files.txt auf ?,
das würde nämlich das Löschen von unveränderten Dateien nach, soweit ich den Code durchblickt habe, 24 Std. bewirken. Faktisch sind's bei mir aber 5 Jahre, weiß nicht wo das genau herkommt.
Das ist aber auch erstmal nicht schlimm, denn, wie bereits gesagt, sollten Files überschrieben werden wenn die eingestellte "DB Cache Lebenszeit" abgelaufen ist.

Gruß,
noRiddle

[ambi]

Hallo,

soeben live und local getestet. Schreibrechte für Verzeichnis Cache (inkl. Unterverzeichnisse) auf 755 gesetzt. Die erzeugten cache files bekommen 604. Nach der abgelaufenen Zeit wird auch eine txt erzeugt mit dem Namen "keyword_clean_up_driver_files.txt" mit folgenden Inhalt:

a:4:{s:5:"value";i:86400;s:10:"write_time";s:10:"1543416876";s:10:"expired_in";i:157680000;s:12:"expired_time";i:1701096876;}

[noRiddle (revilonetz)]

Was soll mir das jetzt sagen ?
Du hast nicht alles gelesen was ich geschrieben habe ?

Ich würde sagen, lasst jemanden der Ahnung hat das untersuchen (ich habe die Zeit nicht mom.).

Gruß,
noRiddle

[ambi]

Sorry, vielleicht habe ich mich nicht klar ausgedrückt.
Also Schreibrecht für cache ist manuell auf 755 eingestellt (und bleibt auch) – DB-Cache Lebenszeit auf 60 Sek. (alle cache files wurde gelöscht)  Nach Ablauf von mehr als >60 Sek. taucht ein File auf mit dem Namen   keyword_clean_up_driver_files.txt  (mit 604) so wie du es beschrieben hast. Es werden dann auch alle files überschrieben mit aktuellem Zeitstempel. Das war‘s dann aber auch. Es funktioniert nur einmal das die files überschrieben werden. Nach weiteren > 60 Sekunden wird nichts mehr überschieben und die files werden mehr (haben dann alle 604). Nach ca. 1 Stunde sind es dann rund ca. 20.000 files.

[noRiddle (revilonetz)]

Okay, die Aussagen sind schon besser, vor allem, daß die 755 auf /cache/ geblieben ist.
Ich kann mom. aus Zeitgründen nicht genau prüfen ob 604 für die Files ausreicht. Bei mir ist es 644, wobei die 4 anstelle der 0 an zweiter Stelle eigentlich die Leserechte für "Group" sind, die normalerweise nicht benötigt werden, Hauptsache der "Besitzer" hat alle Rechte. Aber vielleicht blicke ich da nicht ganz durch.
Sagen die /log/-Files irgendetwas ?

Wenn ich manuell ein Cache-File auf 604 setze macht das Skript wieder 644 draus und es wird überschrieben.

Frage doch bitte mal deinen Hoster warum du mittels chmod() in einem PHP-Skript (diesen Befehl benutzt das hinterliegende Skript) nicht Rechte verändern kannst. Der Server muß bei chmod(FILE_PATH, 777) bei Verzeichnissen zumindest 755 und bei Files mindestens 644 zulassen.

Ich bin kein Server-Fachmann, wäre gut wenn man mal eine Antwort dazu von einem Betreiber/Hoster hätte.
Bei mir geht's ja auch nicht alles auf 777, obwohl das Skript das versucht, aber immerhin werden ausreichend hohe Rechte vergeben.

Gruß,
noRiddle

[Timm]

Und guckt doch mal bitte ob Benutzer und Gruppe, für durch Skripte vom Server erstellte Dateien, mit den normalen hochgeladenen Dateien des Shops übereinstimmen. Meißt die letzte Spalte in filezilla. Also ob der Cacheordner den gleichen Besitzer und Gruppe hat wie die erstellte Cachedatei.

Also diese CHMOD Geschichte und falscher User, sodass man per FTP die Datei nicht löschen oder überschreiben kann / darf, ist typisch für den "falschen Hoster". Hatte das selbst einmal vor vielen Jahren, Hoster-Wechsel brachte die Lösung. Rest war nur nervig, da man per Hoster-Admin (Web-FTP o.ä.) oder Skript immer die Benutzer und Rechte korrekt setzen lassen musste.
Liegt glaub ich prinzipiell daran, wenn PHP nicht richtig am Server konfiguriert wurde. Tritt z.B. gerne auf wenn PHP als Modul läuft und nicht als CGI.

von hier: Problem mit dem Default CHMOD von Produkt-Bildern

Ich hatte auch mal so eine Situation bei einem selbstverwalteten Server eines Bekannten bei Hetzner. Da war das auch so und ich konnte zb die von mir hochgeladenen Bilder über den kcfinder danach nicht mehr löschen, weil sie durch das Modul andere Besitzer und Gruppe hatten. Haben aber nie herausgefunden an welcher Einstellung des Servers es lag und ich bin umgezogen zu Bitpalast und hatte meine Ruhe.

Gruß Timm

[noRiddle (revilonetz)]

Sehr .

Hab's übrigens eben, allerdings bei einem "Managed Server" bei Hetzner getestet. Da ist das okay konfiguriert.
Verzeichnisse bekommen 755 und Dateien 644. Das Skript für den Cache versucht zwar 777, wie ich bereits sagte, aber 755 für das Directory und 644 für die Files ist ausreichend, also okay konfiguriert.

Auf jeden Fall den Hoster "lang" machen .
Wenn es sich allerdings um "Shared Hosting" handelt wird der Hoster da nichts darn ändern wollen, dann unbedingt upgrade-n auf min. einen V-Server.

Ich werde zu der ganzen Cache-Problematik noch ein Ticket schreiben und dort auch dringend empfehlen, daß in der Installations-Anleitung oder den Voraussetzungen das chmod()-Problem angesprochen wird.

Um es nochmals übersichtlich darzustellen:
Die Problematik der Cache-Einstellungen im Backend sind:

• unzureichende oder verwirrende Namen und Erklärungen zu den Einstellungsmöglichkeiten
• "Cache benutzen" bezieht sich auf's Template.
  Wenn man es ausgeschaltet hat wird in /templates_c/ ohnehin gecacht,
  wenn es eingeschaltet ist zusätzlich in /cache/.
  Wofür soll das gut sein ?
  Und wenn es einen Sinn haben sollte, sollte man ein anderes Verzeichnis als das für den DB-Cache dafür wählen.
• "Cache Ordner" wird überhaupt nirgends benutzt (lediglich in zwei Funktionen im /inc/-Ordner die nicht benutzt werden)
• Überarbeitung der REDIS-Cache-Möglichkeit (ist bei einem Kunden bei Hetzner installiert, bei Versuch das zu verwenden => weiße Seite völlig ohne Errors, auch nicht im Log)
• In dem Zusammenhang auch Ticket # 268 beachten, wo ich auch bereits Kommentare zu dem Thema geschrieben habe.

Wir müssen das Cachen doch endlich mal auf die Reihe bekommen, das ist wichtig für die Performance.
Allerdings könnte es auch weitere Probleme mit dem Cachen von DB-Queries geben.
Evtl. gibt's da Probleme im Zusammenhang mit diesem Thema im Forum ab Post 34.

Gruß,
noRiddle

[Timm]

Die Rechte waren bei dem Hetzner Server auch richtig. Aber halt anderer Besitzer und Gruppe und deshalb konnte man das nicht ändern oder löschen. Mein Bekannter war da aber auch extrem Sicherheitsbewusst, wie vielleicht auch einige Hoster und es war schwierig ihn zu überzeugen da was zu ändern. Deshalb musste ich dann zu einem Webhoster und bin mit meiner Wahl sehr glücklich. Und am Ende ist das Shared Webhosting sogar wesentlich schneller als der eigene Server bei Hetzner. (Das Forum ist soweit ich weiß auch auf einem eigenen Server bei Hetzner.......)Es muss also nicht immer gleich ein eigener Server sein.

Das du dafür ein Ticket erstellst find ich super. Immer besser wenn das jemand mit Hintergrundwissen macht. Und du bist nicht der erste Experte, der nicht genau weiß was welche Cache-Funktion im Backend genau macht. Das hab ich auch schon anderswo gehört. Und so sollte es ja nun wirklich nicht sein. Wie soll das dann der Normaluser verstehen. Bei mir ist der DB Cache sogar ausgeschalten, um keine Probleme zu bekommen. Was nicht schön ist, aber man kann nicht alles immer ausprobieren und bei der nächsten Version gehts dann wieder nicht. War ja bei 2.0.4.0 auch so, dass zb auf einmal keine Filter und Rezensionen mehr gingen mit eingeschaltetem DB Cache.

Gruß Timm

[mei chan]

Hallo,

PhpFastCache verwendet normalerweise Unterordner um das "vollaufen" zu vermeiden.
Das Team hat sich aber für die Verwendung ohne Unterordner entschieden.

/includes/external/phpfastcache/phpfastcache.php

Code: PHP  [Auswählen]

//'skipSubdir'    => true,
 

Ansonsten ist das DB Caching seit der 2er imo ganz gut gelöst.
Was aber das HTML Caching betrifft, kann ich noRiddle nur zustimmen.
Es sollte unbedingt überarbeitet werden, in ein separates Verzeichniss erfolgen und besser dokumentiert werden.

Gruß

neroBRN

[noRiddle (revilonetz)]

...
Ansonsten ist das DB Caching seit der 2er imo ganz gut gelöst.
...

Ja ja, aber das chmod()-Problem ist halt eines. Denn wenn der Server die erforderliche Rechtevergabe nicht zulässt laufen die Directories eben immer voller. Das muß vehindert werden.
Es muß also 1. in der Dokumentation / Instalationsanleitung / den Voraussetzungen das Problem erwähnt werden und 2. evtl. geprüft werden, ob die effektiv gesetzten Rechte ausreichend sind.

Was das HTML-Caching betrifft blicke ich da nicht durch.
Es geht nicht nur um ein von den DB-Cache-Files getrenntes Verzeichnis sondern auch darum wofür das genau da ist. Denn in /templates_c/ wird immer smarty-gecacht, egal ob "Cache benutzen" angeschaltet ist oder nicht.
Ich frage mich also ob das was nach Aktivierung von "Cache benutzen" geschieht nicht redundant ist.

Gruß,
noRiddle

[GTB]

templates_c ist kein Cache Verzeichnis, sondern das Compile Verzeichnis von Smarty. Dort wird der Mix aus HTML und Smarty compiliert nach PHP in HTML.

Das Caching wird gerade nochmals überarbeitet, da es im Moment noch zu starr ist.

@noRiddle
Was REDIS angeht. Willst du es als Cache oder Session Handler verwenden ?

Gruss Gerhard

[noRiddle (revilonetz)]

Hallo GTB.
Ah, okay, das mit /templates_c/ hatte ich gar nicht geprüft. Danke für die Info.

REDIS habe ich als Cache-Handler zu verwenden versucht, indem ich einfach unter Erw. Konfiguration => "Cache Engine" 'REDIS' ausgewählt habe; dies in der Annahme, daß die phpFastCache-Klasse das dann handle-t.

Wenn euch das nicht sowieso schon klar ist bitte ich beim Überarbeiten des Cachings meine Aufzählung hier im Thread zu beachten.
Insbesondere auch wegen verständlicher Bezeichnungen/Erklärungen und des (bislang) nirgends benutzten "Cache Ordner", aber auch die Sache mit dem chmod() und das im verlinkten Post zitierte Ticket wo es um die Cache-Directories und deren Definition geht.

Gruß,
noRiddle