Bilder Cache bläht Server immens auf

[Mediaresort]

Hallo,

bei uns bläht sich der Server durch ständiges Erstellen von Bildern im Cache mächtig auf.

Es werden für verschiedene Sprachen verschiedene Bilder im Cache angelegt.

Es werden, obwohl jpg angegeben ist teilweise auch PNG`s erstellt.

Der Storage-Ordner hat gerade mal 2370 MB, der Product-Ordner immense 38875.37 MB.

Da stimmt doch was nicht... Warum werden ständig Bilder in verschiedensten Versionen erstellt ?

 

[css-umsetzung]

was ist den daran so schlimm?
von jedem Bild werden drei oder vier Versionen erstellt, um die Ladezeit zu minimieren bzw. den Server zu entlasten.
so lange wie du dem Artikel nichts tust, liegt die Datei einfach nur rum und ärgert niemanden.

Das macht so ziemlich jedes vernünftige System auf die eine oder andere Art so und das ist auch gut so.

 

[Mediaresort]

Ja, aber welchen Sinn macht es, für jede Sprache ein extra Bild zu cachen und noch viel interessanter wäre zu wissen, welchen Sinn das Cachen sowohl eines Jpgs, als auch eine PNGs hat...

Wozu brauche ich das PNG, wenn nur JPG gefordert ist ? Volle Server machen auch lahm.

 

[ag-websolutions.de]

Kannst du mal bitte einen screenshot einstellen, auf dem ersichtlich ist, dass die Bilder "je Sprache" estellt werden.

Was PNG/JPG angeht ... hast du zwischenzeitlich vllt. im Shop-Admin mal die Bildart umgestellt?

 

[Mediaresort]

Guten Morgen,

ja wir hatten von PNG auf JPG umgestellt, aber wir hatten nach der Umstellung alle Bilder aus dem Cache und auch aus dem Storage gelöscht. Haben dann alle Produktbilder neu über die Wawi hochgeladen und dann im Shop über Bilder > Übersicht neu geniert, so dass alle Bild im Cache erstellt wurden - machte dann eine venünftige Grüße von 9,32 GB ( was auch jetzt immernoch dort angezeigt wird. )

Jedoch werden weiterhin ständig neue Bilder erstellt, so dass der Cache jetzt schon wieder knapp 40 GB beträgt ( siehe dritten Anhang )

Bild 1 zeigt PNG und JPG

Bild 2 zeigt Bilder für verschiedene Sprachen, aber selbes Produkt

Bild 3 zeigt, wie groß das Ganze ist, obwohl 9,5 GB reichen sollten.

 

[css-umsetzung]

Aber wenn eure Produkte in den drei Sprachen unterschiedliche Namen haben, wäre es doch verständlich, ohne jetzt die Programmierung anzuschauen, dass er für jede Sprache eine eigene Namentlich benannte Grafik erstellt.
Ihr habt ja sicherlich eingestellt, dass die Bilder Seonamen verwenden sollen.

Das mit den PNG Bildern ist ein BUG habe ich gerade festgestellt, Ihr hattet ja vorher PNG Bilder, das heißt das Suchmaschinen vermutlich diese schon gelistet hatten, wenn nun jemand kommt und das Bild direkt aufruft, dann wird das durch den Shop generiert, da der Shop denkt es wurde noch nicht erstellt, dass könntet Ihr vorübergehend nur über eine .rewrite Regel in der .htaccess lösen.

Da muss JTL jedenfalls nachbessern und diese Umleitung selbst herstellen wenn gar keine PNG Bilder erstellt werden sollen, da hat bestimmt keiner dran gedacht, das ist ja auch wirklich ein Sonderfall.

 

[css-umsetzung]

Das hier an dieser Stelle in der .htaccess sollte euch vorübergehend helfen

RewriteRule ^media/image/product/(.+/.+/.+)\.png /media/image/product/$1.jpg [r=301,L]
#Regeln fuer das Rewrite der URLs von JTL-Shop4 <-- steht schon in der .htaccess

und wenn Ihr einen Serverzugriff habt, könnt Ihr wenn ihr euch in media/image/product/ befindet, mit diesem Befehl alle vorhanden .png Files killen

find . -name "*.png" -print0 | xargs -0 rm -rf

 

[hula1499]

Das Thema mit den "mehreren Bildern pro Sprache" ist ja jetzt nichts neues und wurde auch schon mit David per Ticket angesprochen.
Er meinte, er spreche das mal intern durch, da man ja sowieso keine extra Bilder / Sprache anlegen kann.

Macht überhaupt keinen Sinn bei den derzeitigen Gegebenheiten, dass pro Produkt in allen vorhandenen Sprachen extra 3-5 Bilder erzeugt werden, da man im Artikel sowieso sprachlich keine Bilder zuordnen kann.

 

[css-umsetzung]

Macht überhaupt keinen Sinn bei den derzeitigen Gegebenheiten, dass pro Produkt in allen vorhandenen Sprachen extra 3-5 Bilder erzeugt werden, da man im Artikel sowieso sprachlich keine Bilder zuordnen kann.

Ja das ist klar das das nicht geht, ich bin ja kein SEO aber ich denke ja schon das es gut ist, dass die Bilder dann zumindest die Namen des Artikels haben und das lässt sich,
da ja ohne Tabellenbeziehung (Produkt->Bildname) gearbeitet wird, eben nur durch unterschiedliche Bildernamen je Sprache lösen.

Ich finde die Sprachen abhängige Unterscheidung gut und Speicher kost ja nix, wenn man das noch über die Attribute regeln könnte das man selbst die Namen, auch in anderen Sprachen vergibt, wäre es natürlich TOP

 

[hula1499]

Gerade aus SEO Sicht ist das eher fraglich, ob es nicht schadet.

5 Sprachen bedeutet 4x3-5 double content Bilder. Google kann ja den Bildinhalt unterscheiden und in vielen Fällen mischt er dann von den Bildern her einfach die Sprache:
.) manchmal ist DE das Hauptbild (also das Bild, das im Bildcache bei Google liegt)
.) manchmal EN
.) manchmal FR usw...

Ich finde die sprachenabhängige Unterscheidung unnütz, da ich sie sowieso nicht umstellen/einstellen/verändern kann. Bei Texten wird so "toll" mit der Fallbacksprache gearbeitet, aber bei Bildern wird tonnenweise doppelter content erzeugt.

Top oder sagen wir einfach "normal" wäre es, dass ich in der WaWi einem Artikelbild unterschiedliche Sprachen zuordnen könnte (was jetzt technisch ja nicht so die Hexerei wäre, wenn man es machen wollen würde).
Es soll ja auch Varianten geben, bei denen Bilder sprachlich/textmässig beschrieben sind, was hat so ein Bild (wenn es auf DE beschrieben ist) zb. bei Ama co.uk, ebay.com oder shop in der Sprache FR zu suchen....genau, nix

Nachtrag: ja, der Speicher selbst kostet nix, aber performance des Servers kostet etwas, genauso wie Auslastung, Bandbreite usw.