modified eCommerce Shopsoftware 2.0.6.0 rev 13500 veröffentlicht

[Tomcraft]

Die Erweiterung für den Redis-Cache kann bei uns über das Kontaktformular bestellt werden.

Grüße

Torsten

[Timm]

Oder ihr listet das mal in eurem Modulshop. Das wird ja häufiger im Forum erfragt.

Gruß Timm

[Tomcraft]

Ja, haben wir noch vor.

Grüße

Torsten

[snocer]

Ich suche und suche  ... selbst das Wiki bringt keine Lösung ...  

Während unserer Tests habe ich auf einen Linux/Apache Server mit php 8.03 und 10.3.28-MariaDB die Shopversion 2.0.6.0 installiert.
Die server_info.php unseres Servers als der des Modified-DEV-Shops zeigen faktisch gleiche Module und Werte....

Soweit ganz OK,
die Datenbank liefert zwar beim ersten Install-Versuch "keine Antwort",
also einfach die erste Seite nochmal gestartet,
dann meckert die Installroutine existierende Tabellen an, aber arbeitet letztendlich bis zum Ende durch.
(Etwas verwirrend für Neulinge) Dieser Fehler zur Datenbankanmeldung ist bei uns reproduzierbar.

Was ich nun suche? Redis !
Der Shop zeigt mir Redis nicht zur Auswahl an.

Redis zu nutzen macht nur Sinn, wenn Du einen dedizierten Server / managed Server verwendest und Du Dich alleine auf Deinem Server tummelst. Redis ist eine In-Memory-Datenbank mit einer einfachen Datenstruktur und gehört zur Familie der NoSQL-Datenbanken. Diese einfache Struktur der Datenbank eignet sich deshalb weniger für komplexe Datenstrukturen. Komplexe Datensätze und Abfragen sind nicht die Stärken von Redis. Genau wie andere In-Memory-Datenbanken benötigt Redis extrem viel Arbeitsspeicher, was ebenfalls sehr kostspielig sein kann. In der Praxis hat sich auch gezeigt, dass es zu Problemen mit einigen Webseiten gekommen ist und es je nach Anwendungsart keinen signifikanten Performanceschub gab. Ob die Verwendung nun Sinn macht, in Verbindung mit dem modified Shop System, musst Du nun selbst entscheiden.
Bei richtiger Konstellation und Einrichtung erreichen unsere Seiten immer eine PageSpeed Wert von 98-100% Mobile und 95-98% in der Desktop Ansicht. Dafür brauchen wir keine Speicher fressende Redis inMemory DB. Lieber mal MariaDB auf Version 10.5.x anheben, bringt Dir bestimmt mehr als inMemory DB mit dem diversen Zusatzaufwand für Anpassungen diverser Dateien und dadurch Verlust der Kompatibilität / Updatesicherheit zum Grundsystem. Und dem Verlust der referenziellen Integrität, den Dir InnoDB liefert. Wärst dann nicht der erste Shop, der noch viel Attribute und Bilder in der DB führt obwohl zum Beispiel der Artikel bereits gelöscht wurde. Alles eine Frage des Geschmacks. Für ChickiMiki WhatsUp etc. bestimmt Super. Für eine saubere Shop DB mit sagen wir mal 1.000.000 Artikeln wohl eher tödlich.

cu snocer

[noRiddle (revilonetz)]

Ich denke das ist ein Thema was man nicht so einfach abhandeln kann, ohne dein Wissen darüber in irgendeiner Form anzweifeln oder schmälern zu wollen (ich habe darüber wenig bis keines).
Ich denke auch, daß FräuleinGarn Redis nicht als Cache sondern als Session-Handler implementiert hat, was eine ganz andere Story ist.

Gruß,
noRiddle

[Timm]

Cache+Session

Gruß Timm

[snocer]

@noRiddle, Session Handling über den Cache / Speicher / RAM ist auch so bereits möglich, muss nicht in der DB gespeichert werden.
Aber nur für das Session Handling noch Redis zu verwenden, wem es Spaß macht gerne, aber nicht notwendig.

Tim schreibt aber er nutzt es auch für den Cache der Site. Und dann sind wir wieder bei den genannten Nachteilen.
Und am schwersten wiegt hier meiner Meinung nach der Verlust der referenziellen Integrität. Gerade in Verbindung mit einer angeschlossen WaWi. Da werden entweder die teilweise gelöschten Sätze wieder komplett hergestellt beim nächsten Abgleich im günstigsten Fall oder man zerballert sich seine WaWi DB weil Bezüge fehlen. Geschwindigkeitsvorteile bei komplexen Abfragen tendieren damit eher gegen NULL, wenn nicht sogar negativ im Shop. Für eine WordPress Blog gut geeignet aber für ein Shop System .....

cu snocer

[Timm]

Ich verstehe deine Einwände nicht. Wie soll man sich denn seine Shopdatenbank zerschießen, wenn das Caching und Session Handling in extra Redis Datenbanken geschiet, die mit der Shop DB nichts zu tun haben?

Wenn ich meine Seite 20 mal Neulade, dann habe ich konstant die gleichen, niedrigen Ladezeiten. Wenn ich mir andere Shops anschaue, dann schwankt das bei jedem Aufruf extrem und ist wesentlich langsamer.

Vielleicht mag @GTB ja noch was dazu sagen.

Gruss Timm

[Tomcraft]

[...]
Und am schwersten wiegt hier meiner Meinung nach der Verlust der referenziellen Integrität. Gerade in Verbindung mit einer angeschlossen WaWi. Da werden entweder die teilweise gelöschten Sätze wieder komplett hergestellt beim nächsten Abgleich im günstigsten Fall oder man zerballert sich seine WaWi DB weil Bezüge fehlen. [...]

Welche Wawi Schnittstelle greift denn über den Cache auf die Datenbank zu!?
Das wäre mir wirklich neu!

Grüße

Torsten

[snocer]

@Tomcraft, dann bitte alles lesen und im Kontext verstehen.
Durch die in Memory DB verlierst Du die Relationen, Bezüge. Es ist möglich einen Artikel zu löschen und die Attribute und oder Bilder bleiben als Leichen in der Shop DB. Beim Synchronisieren des Artikelstamms zum Beispiel erkennt die WaWi die fehlenden Einträge und würde diese wieder im Shop ergänzen. So das die Löschung nichts gebracht hat. Synchronisation vom Shop zu WaWi gestaltet sich dann noch etwas schwieriger, weil eventuell unvollständige Datensätze übertragen werden. Der Shop prüft nicht bei Verwendung einer inMemory DB ob das was er liefert dann auch vollständig ist. Ich kratz mich mal lieber nicht am Kopf.

PS: eine inMemory DB ist eben eine Cache DB und lädt und verarbeitet eben erst einmal alles im Cache bevor es dann wirklich gespeichert wird. Bei der Synchronisation wird dann natürlich nicht auf den Cache zugegriffen,  hier besteht jetzt schon die Gefahr von Dateninkonsistenzen.

cu snocer

[Tomcraft]

[...]
Durch die in Memory DB verlierst Du die Relationen, Bezüge. Es ist möglich einen Artikel zu löschen und die Attribute und oder Bilder bleiben als Leichen in der Shop DB. [...]

Nein das stimmt nicht! Redis-DB (Cache & Sessions) und Shop-DB sind zwei paar Schuhe! Und ich kenne wie gesagt keine einzige Wawi-Schnittstelle, die auf den Cache des Shops zugreifen würde.

Grüße

Torsten

[snocer]

Natürlich greift keine WaWi auf den Cache zu. Sondern auf die Shop DB. Redis lädt aber alle Daten in den Speicher.
Wenn hier jetzt gleichzeitig Transaktionen laufen und Artikel gelöscht werden in der products Tabelle löscht es nicht gleichzeitig die Bezüge in den Tabellen wie products_image und products_attributes etc. Redis kennt meines Wissens keine Relation. Und das Rückschreiben in die Shop DB dauert eben auch etwas. Durch das fehlen der Bezüge, bleiben eben die genannten Leichen in der DB stehen. Schon mehrfach gesehen. Kann man natürlich alles wieder mit Scripten und SQL Anweisungen lösen, aber ob das dann der Vorteil ist?

Und noch einmal ich habe nirgends erwähnt oder geschrieben, das eine WaWi auf die Cache DB zugreift. Da machen es Wiederholungen auch nicht richtiger.

Vielleicht klärt uns mal einer auf, was hier Redis verbessern soll. Außer das mehr Ressourcen benötigt werden.

cu snocer

[Tomcraft]

Redis löscht auch keine Daten in der Shop-Datenbank oder aktualisiert dort Dinge. Es wird nur für das Caching und die Sessions verwendet. Ich weiss wirklich nicht, wie ich es noch anders schreiben soll?

Ich klinke mich jetzt hier aus... Habe alles dazu gesagt und wir haben das erfolgreich bei großen Kunden im Einsatz, die keinerlei Probleme damit haben und den Geschwindigkeitsvorteil zu schätzen wissen.

Grüße

Torsten

[snocer]

Vielleicht hätte dann gereicht es auch mal so zu schreiben. Redis läuft nur für das Caching und die Sessions. Redis an sich ist auch ein noSQL DB und kann auch anders verwendet werden. Daher mein Unverständnis was ihr nun mit Redis bezweckt.

können wir nun beenden. Jetzt habe ich es auch kapiert. Ich habe es jedenfalls noch nicht benötigt und habe Kunden mit mehr als 100.000 Artikeln mit durchschnittlich 20 Attributen und mehr pro Artikel. Habe noch keine Performance Probleme feststellen können. Was entweder an modified liegt oder an den verwendeten Servern.

[Tomcraft]

Timm schrieb doch, dass er unser Modul im Einsatz hat:

[...] Bei @GTB kannst du eine kostenpflichtige Lösung anfragen. Hab ich im Einsatz und bin sehr zufrieden.
[...]

Und er schrieb auch:

Cache+Session
[...]

Dachte das wäre damit klar!?

Grüße

Torsten