Neu /admin/cache lädt 20s für leere/defekte Statistik UND der Shop ist 0.3s langsamer - Zusammenhang?

[Have a nice day! :) ♡]

(... - Das ist meine einzige, konsistente Erfahrung mit dem Cache.)

Kontext: v5.3.1 (Nova Template angepasst, keine Shop Dateien verändert & "Dateien"-Cache als häufigste Option)

• Ein JTL- Shop-Agentur Entwickler war im Team u. meinte das sind halt die JTL-Shop Fehler... (auch bzgl. dem 2. Fehler, dass wir Feed-Export nicht verwenden konnten, weil 2% der Produkte fehlten u. die allermeisten doppelt waren - ist das nicht beides essenziell? Bin sprachlos verblieben..)
  • Der Shop lief also 1 Jahr mit: 1s durchschnittl. Antwortzeit. (wie gemessen o.a. vom Google HTML crawler https://search.google.com/search-co...ldown?resource_id=http://________&file_type=1 )
    [ Shopware: 0.6s ] [ OPC seiten Portlets mehr, z.B. 3.5s ]
  • Nun hat eine JTL Agentur den Shop vor Monaten unverändert migriert
    und es ist genau seit dem Tag an schlechter bei 1.3s.
    • Die Agentur konnten auch nur öfter zwischen Dateien & Redis hinundher stellen. Redis sah normal aus (unter /admin/cache), aber war genauso langsam. Inzwischen wurde auch der Shop geleert & Wawi-abgeglichen; Plesk wurde neu installiert; MariaDB's .conf viel Ram gegeben.
    • Vermutl. liegt's einfach daran, dass die eine VM genommen haben(??) (keine dedizierten SSDs)
      • 160/s DB queries; 4k Write-test: 32MB/s (alter Server: 117MB/s). Und grade nur 17MB/s (vielleicht lief deren backup grad um 4am? - Kurz danach wieder 39MB/s. Und wir müssen ja nur paar 1000 Besuche/Tag versorgen - nicht Millionen.
    • (also Fazit b. a. W. : Shop wechseln oder JTL empfehlen mehr zu Debuggen? u. o. alles ab sofort per Ram Disk betreiben. 'Ram gibt dir doch noch recht')

Dateien-Cache mit der defekten (typischen) Statistik (Live Shop):

---

Gesamtgröße:	7654321 Bytes (7654.32 MB)
Anzahl Einträge:	234567

TEMPLATE- CACHE

Dateien Frontend	7654
Dateien Backend	90

	TYP	BESCHREIBUNG	EINTRÄGE	AKTIV
	Artikel	Enthält Artikeldaten	1234
	Kategorien	Enthält Kategoriedaten	0
	Sprache	Enthält Sprachvariablen und Übersetzungen	0
	Templates	Enthält Template-Einstellungen	0
	Optionen	Enthält allgemeine Einstellungen	0
	Plugins	Enthält Plugin-Daten	0
	Core	Enthält JTL-eigene Daten	0
	Objekte	Enthält allgemeine Objekte	4
	Boxen	Enthält Boxen und deren Einstellungen	0
	Blog	Enthält Blogbeiträge und -kategorien	0
	Attribute	Enthält Attributdaten	0
	Hersteller	Enthält Herstellerdaten	0
	Artikelfilter	Enthält Filterdaten	321
	Status	Enthält Status für Mitteilungen	0
	OPC	Enthält Daten des OPC	0

@FMoche @Enrico-w @JulianG

Vergleich wenn's geht: (alter Server; keine Änderungen; auch v5.3.1 )
CACHE

Gesamtgröße:	1104802632 Bytes (1053.62 MB)
Anzahl Einträge:	32557

OPCACHE

Aktiviert:	ja
Belegter Speicher:	50.64 MB
Freier Speicher:	77.36 MB
Anzahl Skripte im Cache:	2133
Anzahl Keys im Cache:	3441
Hits:	163553
Misses:	2140
Hit-Rate:	98.71%

TEMPLATE-CACHE

Dateien Frontend	672
Dateien Backend	175

TYP	BESCHREIBUNG	EINTRÄGE	AKTIV
	Artikel	Enthält Artikeldaten	17376
	Kategorien	Enthält Kategoriedaten	2123
	Sprache	Enthält Sprachvariablen und Übersetzungen	3
	Templates	Enthält Template-Einstellungen	4
	Optionen	Enthält allgemeine Einstellungen	20
	Plugins	Enthält Plugin-Daten	8
	Core	Enthält JTL-eigene Daten	14
	Objekte	Enthält allgemeine Objekte	14
	Boxen	Enthält Boxen und deren Einstellungen	10
	Blog	Enthält Blogbeiträge und -kategorien	6
	Attribute	Enthält Attributdaten	0
	Hersteller	Enthält Herstellerdaten	50
	Artikelfilter	Enthält Filterdaten	1234
	Status	Enthält Status für Mitteilungen	0
	OPC	Enthält Daten des OPC	1

 

[NoOne]

Lahme HDDs? -> Schlechte Cacheperformance, wenn man Datei- Cache nimmt. Den man ohnehin eigentlich nur nehmen sollte, wenn es nicht anders geht.
Redis nicht als lokale Instanz, sondern extra Server? -> Performance geht durch Overhead verloren. Normalerweise nicht unbedingt spürbar, aber wenn da jemand rumbastelt und etwas verbastelt, kann das katastrophal langsam enden.
Persistenter Redis, obwohl er als Cache benutzt wird? -> Kann auch heftigst Performance kosten, wenn RDB oder AOF falsch konfiguriert sind. Und wenn lahme HDDs zum Einsatz kommen.

Die Statistik ist übrigens nicht unbedingt defekt. Der Shop kümmert sich nur nicht darum abgelaufene Cache-Dateien zu löschen. Weswegen der Datei-Cache eigentlich auch nur die absolute Notlösung sein sollte. Da bleiben viele verwaiste Dateien zurück.

Edit:
Was soll das übrigens für ein Fehler beim Exportfeed sein? 2% der Produkte fehlen und viele sind doppelt? Das ist mir noch nicht wirklich untergekommen. Mein Fazit wäre eher die Agentur zu wechseln.

 

[Have a nice day! :) ♡]

hi! @NoOne - HDDs natürlich wohl nicht. (Hatte SSD & DB Metriken am Ende erwähnt, als 33MB/s im 4k write test und z.B. 160DB queries/s)


inzwischen auch schon 800 queries/s gesehen. Aber dann wäre man ja nur am Limit wenn jeder query etliche writes or reads machen wurde.

Redis lief lokal mit standard config. D.h. häufige RDB snapshots können aber ja nicht sehr viel SSD Last machen.

Die Statistik ist übrigens nicht unbedingt defekt. Der Shop kümmert sich nur nicht darum abgelaufene Cache-Dateien zu löschen. Weswegen der Datei-Cache eigentlich auch nur die absolute Notlösung sein sollte. Da bleiben viele verwaiste Dateien zurück.

Unbedingt defekt, weil viel zu wenig Artikel und Kategorien Null, wie auch die anderen Zahlen.
Aber Frage wie bekannt euch dieser Bug ist und ob der auch hinweist das was nicht stimmt mit dem Cache oder der Cache Performance.

2% der Produkte fehlen und viele sind doppelt?

Werd ich nochmal testen / und in JTL's bug tracker schauen

 

[NoOne]

33 MB/s ist halt eher eine schlechte bis mittelmäßige SSD. Sofern es sich um Random 4k writes handelt. Wenn das Sequential 4k writes sind, dann wäre das absolut unterirdisch. Oder der Hoster schraubt I/O mit Absicht runter, damit beim Shared- Hosting bzw. den einzelnen VMs nicht zu viele Engpässe entstehen. Ob die Cache-Implementation an sich verbuggt ist oder wie oft da was schiefgeht, weiß ich nicht. Datei-Cache würde ich selbst bei perfektem Code nur im Notfall einsetzen.

Eine genaue Analyse kann ich dir halt nicht geben. Performance mit oder ohne Cache hängt von vielen Faktoren ab. Ich hab da nur fix die "Pitfalls" aufgeschrieben, die mir eingefallen sind. Bei RDB kosten Forks z.B. Performance. Ich meine aber Forks gibts mit den Standardeinstellungen nicht.

 

[Have a nice day! :) ♡]

Hallo liebe/r @NoOne, bist du Systemintegrator? ( Ja, 33MB/s 4k random, wären dediziert neu eingerichter sehr unwahrscheinlich/alt/schlecht/TLC/QLC, aber auch eine sparsam dimensionierte VM ist ja nicht gleich schlechter,
solange noch nichts zum Flaschenhals wird)

Wir wollen also einfach ganz sicher gehen, sehen, ob bzw. wann der JTL shop soo hungrig ist?
Auch deshalb die drei JTL-Shop Mitarbeiter verlinkt, um zu sehen ob/was diese sagen können/wollen.

Ob die Cache-Implementation an sich verbuggt ist oder wie oft da was schiefgeht, weiß ich nicht. Datei-Cache würde ich selbst bei perfektem Code nur im Notfall einsetzen.

Im JTL-Shop dürfte es das Simpelste, Häufigste und Älteste sein und nichts anderes lief hier lange, oder konnte empfohlen werde (auch wenn man *JTL Shop Hosting mit Redis* kaufen kann. Und auf das Datei- Cache-Paradox bzw. Datenträgerlatenz kommt's ja nicht mehr an seit SSDs.