Neu Neues Plugin: JTL Supercache

[eRock Marketing]

Müssen wir uns in der Tat genauer anschauen, denn wir haben keine Routinen bei der Installation/Deinstallation des Plugins, sprich hier hat sich pluginseitig durch die Aktion nichts geändert, sondern eher im Shopcore.
Ein deaktiviertes Plugin sollte daher genauso reagieren wie ein deinstalliertes - und wäre Baustelle vom JTL Shop Core.

 

[css-umsetzung]

Bitte auch immer daran denken das der Cache bei vielen Anbietern (auch JTL) begrenzt ist bei JTL würde ich auf 250MB tippen.

 

[saw]

Bitte auch immer daran denken das der Cache bei vielen Anbietern (auch JTL) begrenzt ist bei JTL würde ich auf 250MB tippen.

Wenn ich in die Stats unseres Redis schaue, sehe ich:

Komplette Größe:	133735560 Bytes (127.54 MB)
Anzahl Einträge:	4793

Und beim Supercache:

Gecachte Seiten 320

Größe Standardcache 45,1 MB

Größe Dateicache -

Größe Datenbankcache 16 KB

Die "geringe" Anzahl der Seiten im supercache kommen mir bei 3300+ Artikeln einfach zu wenig vor.

Wäre schön wenn Knöll da was zu sagen könnte.

 

[Inge]

Ein paar Statistiken von uns, ggf. hilft es bei der Optimierung des Plugins.

DB: Redis
KM-SuperCache: File-Based





Mir ist aufgefallen, dass wenn man den chmod 777 unter km_supercache/version/104/frontend/cache <- vergisst, das ganze Plugin richtig zählt und so tut als ob es geht, faktisch aber keine Dateien ablegt.
Das endet dann bei "Größe Dateicache -" wer hier ein Minus stehen hat und den Filecache nutzt hat den chmod vergesen. Das könnte man ggf. nochmal gezielt abfragen.
Zum Objektgrößenunterschied zwischen Redis und SuperCache kann ich nichts sagen, daher erstmal nur für den Entwickler zur Hilfe.

 

[Inge]

01.03.2020

JTL:





KM-SuperCache:

 

[eRock Marketing]

Vielen Dank für die ganzen Infos.

Wir sind hier natürlich am Thema dran - derzeit gibt es absolut widersprüchliche Informationen.
Während bei einem zu lange Daten im Cache gespeichert werden, werden bei anderen Daten zu kurz gespeichert.

@saw Ist die geringe Anzahl in der Tat verwunderlich? Bedenke, dass wenn sich etwas zum Artikel ändert die Detailseite und die Listingseite wieder aus dem Cache gelöscht werden muss. Ein Richtwert dazu ist: Wieviele unterschiedliche Seiten wurden aufgerufen und wieviele Artikel wurden bestellt? Beispiel: Es wurden 100 Detailseiten aufgerufen und 50 unterschiedliche Artikel bestellt, dann dürften nur 50 Artikel im Cache sein (die Kategorieseiten sicherlich durch die 50 Artikel bereits geleert, jedoch zusätzlich Infoseiten wie z.B. Versand falls diese aufgerufen wurden).
Kurzum: Bitte einmal grobe Nährungswerte an Hand von Statistiken vergleichen.


Zu den Limits: Im JTL Hosting gehen maximal 250mb - dann werden die ältesten Einträge überschrieben. Da der Supercache recht große Datenmengen speichert würde ich im Fall der Limitüberschreitungen (auch bei anderen Hostings!) empfehlen auf den Dateicache im Supercache zu wechseln - sonst haben wir 100 sehr schnelle Seite und 100 noch langsamere Seiten, da hier dann nicht mal die Datenobjekte (JTL Standard) im Cache gespeichert sind, weil diese wieder überschrieben wurden. Sollten jedoch solche Limits erreicht sein ist häufig die Frage ob es nicht an der Zeit ist auf einen eigenen Server / andere Lösungen zu wechseln - aber klar, das ist ein anderes Thema.

 

[martinwolf]

@KnoellMarketing Was mir eben bei einem Kunden aufgefallen ist, im Zuge einiger Templateanpassungen: Ich nutze in Hypnos eine Abfrage um für Crawler bestimmten Code nicht zu rendern. Wenn nun jedoch ein Crawler auf die Seite kommt, dann wird dessen Ansicht in den Cache geschrieben, sofern diese da noch nicht vorhanden ist. Nun ruft ein echter User diese gecachte Seite auf und bekommt die Ansicht des Crawlers präsentiert, mit reduziertem Content. Könnt ihr das mit aufnehmen, sodass der Cache nicht durch den Besuch von Crawlern erzeugt wird?

 

[eRock Marketing]

Das ist ja schon etwas spezieller.
Gerne können wir das aber in die nächste Version mit einfliesen lassen, sofern es eine Grundfunktion von Hypnos ist und keine Individualgeschichte.
An Hand welcher Basis wird das denn unterschieden?

In der Zwischenzeit kann man den Reiter "Proficonfig" nutzen um dort eigene Prüflogiken zu hinterlegen.

z.B.

if($_GLOBALS['isBot'] === true) 
    $cache_id .= '_bot';

Dieser Code wird in Hook 132 ausgeführt.

 

[martinwolf]

Das ist ja schon etwas spezieller.
Gerne können wir das aber in die nächste Version mit einfliesen lassen, sofern es eine Grundfunktion von Hypnos ist und keine Individualgeschichte.
An Hand welcher Basis wird das denn unterschieden?

In der Zwischenzeit kann man den Reiter "Proficonfig" nutzen um dort eigene Prüflogiken zu hinterlegen.

z.B.

if($_GLOBALS['isBot'] === true)
    $cache_id .= '_bot';

Dieser Code wird in Hook 132 ausgeführt.

Ja geil, das hilft mir ungemein. Für alle Hypnos nutzer:

if (isset($crawlerDetected) || strstr($_SERVER['HTTP_USER_AGENT'], 'Lighthouse')) {
    $cache_id .= '_crawler';
}

 

[deliman]

Hallo,

habe seit einigen Tagen ein Problem mit dem Auslösen des shopinternen Cronjobs und Herr Wolf hat das mal geprüft. Der Fehler liegt an einer Datei vom Supercache-Plugin.
Hier die Fehlermeldung:
Parse error: syntax error, unexpected 'km_deleteCacheFile' (T_STRING), expecting '(' in /var/www/vhosts/meinshopname.de/httpdocs/includes/plugins/km_supercache/version/103/frontend/cron.php on line 2
(Da fehlen wohl einige Klammern...)

Sollte dringend mit geprüft und gefixt werden. Herr Wolf hat bei uns jetzt eine bearbeitete Datei eingespeilt und nun funktionieren die Cronjob für den Newsletterversand und die Google-Shopping-Feeds wieder.

 

[css-umsetzung]

habe seit einigen Tagen ein Problem mit dem Auslösen des shopinternen Cronjobs

Unabhängig von dem Fehler der natürlich nicht vorkommen sollte, ist es wirklich sinnvoller, wenn du den Cron nicht über das Template ansteuerst sondern über einen echten Cronjob.
Es gibt wenn dein Hoster das nicht anbietet, die Möglichkeit sich von z.B. cronjob.de, kostenlos und ich glaube sogar minütlich triggern zu lassen.

 

[deliman]

Habe ich seit 2 Tagen auch eingerichtet, hatte aber bislang auch nicht funktioniert. Mal sehen, ob es jetzt geht. Wir haben es jetzt nur mal "händisch" angestoßen um zu prüfen ob durch die Änderung an der Datei der Fehler behoben ist.

 

[eRock Marketing]

Vielen Dank für die Rückmeldung.
Der Fehler tritt bei uns nicht auf - das ist jedoch ein Fehler der, sofern der Cronjob angestoßen wird und es etwas "zum ausführen" gibt, immer auftauchen müsste.

Ich schaue mir das mal genauer an, teste diverse PHP und Shopversionen durch.

Welche wurde in dem Fall verwendet? Sprich: PHP Version, JTL Shop Version, System (apache/nginx). Danke.

 

[deliman]

PHP 7.0.33, Shop 4.06.17, JTL- Hosting (ich denke dann apache)

 

[eRock Marketing]

Danke, ich sehe allerdings dass noch Version 1.03 eingesetzt wird.
Hier sollte bitte auch auf V1.04 geupdatet werden - tritt der Fehler dann noch auf?

 

[saw]

Ich muss nochmal wegen der Seitenanzahl nachhaken. Redis lifetime 604800, Rund 1000 User im Shop und 11 Seiten im Cache. Siehe Anhang. Das ist doch echt wenig.
Mit dem Hypnos "Fix" im Proficonfig
if (isset($crawlerDetected) || strstr($_SERVER['HTTP_USER_AGENT'], 'Lighthouse')) {
$cache_id .= '_crawler';
}

 

[eRock Marketing]

Das Problem lag hier im beschränkten Redis- Cache.
Leider war dies ähnlich bei der Umstellunge auf "Datenbank" - da auch diese beschränkt ist und dann recht langsam reagierte.

Kurzum: Für ein JTL- Hosting empfehlen wir die Nutzung von "Dateien" in unserem Plugin (und werden das in der kommenden Version nochmals deutlicher kennzeichnen).

 

[deliman]

@KnoellMarketing

Seit 1.04 laufen die Cronjobs bislang problemlos.

 

[eRock Marketing]

Hallo zusammen,

eine kleinere neue Version ist erschienen:

Version V1.05 - mit den folgenden Anpassungen:

• Cache pro URL im Shopbackend löschbar (interessant für z.B: angepasste Inhaltsseiten)
• Mehr Cachetags für Artikellisting und Detailseiten (z.B. von Artikel aus dem Cross-Selling)
• Supercache wird deaktiviert wenn man Admin ist
• sowie weitere kleinere Verbesserungen

Mehr dazu wie immer hier: https://shop.knoell-marketing.de/JTL-Supercache

 

[eRock Marketing]

Hallo zusammen,

nun ist unser Supercache für Shop 5 auch im Extension Store freigeschaltet.
Ihr könnt aber weiterhin auch in unserem Shop die Downloads beziehen: https://shop.knoell-marketing.de/JTL-Supercache

In der Version für Shop 5 konnten wir nochmals stärker die Serverantwortzeiten reduzieren - alle weiteren Funktionen sind identisch zum Shop 4 Plugin (auf Stand von Shop 5 natürlich).