Hallo Zusammen! Die kleine Anpassung am Imageprocessing Modul erhöht die Geschwindikeit beim erstellen der Bilder drastisch! Das Problem bei dem vorhandenen Modul ist: --> Bei jedem Request wird das komplette "original_images" Verzeichnis gescannt und in ein Array gelegt, das kann bei 5000 Bildern schon mal seine +/- 5 Sekunden brauchen. Um dieses Problem zu umgehen wird das Array für eine Stunde im Cache behalten. Getestet mit GX 2.0.14.4 Einfach unter admin/includes/modules/export die Datei austauschen oder die "neue" Datei umbennen und einfügen. Achtung - Benutzung auf eigene Gefahr! Nachtrag: Die "cache" Datei wird unter admin/cache_imageprocessing.xtc abgelegt. (Schreibrechte etc...)
Löst aber immer noch nicht das schwerwiegendere Problem des Timeout bei der Berechnung vieler Bilder.... Meine Ansatz der "On-the-fly"-Artikelbilder löst das grundsätzlich, weil solche generellen Imageprocessings gar nicht mehr notwendig sind. http://www.gambio-forum.de/threads/11342-“On-the-fly”-Artikelbilder?highlight=on-the-fly
Das ist eigentlich "ziehmlich" das selbe... Beim Imageprocessing wird pro ajax call ein Bild erzeugt. Bei Deinem "on-the-fly" processing passiert das selbe wie bei einem ajax call, wenn das Bild nicht existiert. Wenn es ein Timeout geben sollte, wird es bei der "on-the-fly" Version auch so sein.
Nein, das stimmt so nicht. "on-the-fly" werden immer nur 3 Varianten eines Bildes in einem Durchlauf berechnet, während in Deinem Modul immer noch 3 Varianten aller Bilder bearbeitet werden.
Diese Aussage ist richtig. Der Unterschied: bei dem "on-the-fly"-Konzept wird immer nur 1 Bild bearbeitet, bei dem normalen Imageprocessing alle Bilder. Und das führt eben bei vielen Bildern zum Timeout. Und von einem "ajax call" kann ich in Deinem Modul nichts sehen.
Btw. das ist das Orginal Imageprocessing von Gambio, da sind nur ein paar Zeilen anders. Okay stimmt! Tatsache, das sind keine "ajax calls", nur ein mieses iframe das per JS abgefeuert wird... Das sollte allerdings auch die Timeout Problematik aushebeln. Gestern hatte ich das Script "ohne" caching mindestens 5 Stunden laufen, habe es dann von Hand abgebrochen da er nicht mal die Hälfte hatte.
ich bekomm von meinem Großhändler ca 30.000 Bilder. ich brauche nur ca 7.000 davon aber in der Dropbox sind halt ALLE. Wenn ich per csv nun 100 neue Artikel habe läd das image processing alle 30.000 BIlder nach und nach. bei Avengers on the fly werden nur die fehlenden BIlder beim 1. Aufruf des Artikels abgearbeitet. Alte Methode ca 15-20 Stunden Serverlast Neue Avenger Methode - verteilte serverlast die ab dem 2. mal massiv extrem reduziert wird da nur noch die 100 neuen Artikel mit Bildern versorgt werden.
Theoretisch könnte man auch eine Abfrage einbauen -> ob Grafik bereits vorhanden, bzw. die bereits vorhandenen Grafiken aus dem Array von den Originalen entfernen... Naja, ist ja jedem selbst überlassen wie er das Handhaben möchte.
wollte auch nciht sagen das deine umsetzung schlecht ist. nur veranschaulichen wo genau der unterschied besteht.
Ein extremes Beispiel, das aber die Vorteile des "on-the-fly"-Konzepts sehr deutlich macht..... Aus meinen OXID-Aktivitäten habe ich hier noch ein Modul von mir 'rumliegen, bei dem die Bilder nach der "on-the-fly"-Erstellung (per FTP) sogar auf einen separaten Bild-Server ausgelagert, und dann von dort geladen werden.... Um die Ladezeit der Bilder zu optimieren.... Alles voll-transparent für den Shop, dort sind keinerlei Änderungen notwendig.... Mal schauen ob ich das irgendwann für Gambio umsetze.... Könnte man vermutlich noch so erweitern, dass man sich das Originalbild von einem externen Server lädt.... Da steckt noch eine Menge Potential drin.
Ja CDN Speicher wird ja auch immer günstiger und bezahlbarer. Könnte man sicher noch mal paar ms mit rauskitzeln.
Hallo David, habe zu der Erweiterung mal ne Frage. Bitte melde Dich mal dazu bei mir. Nummer müsstest ja haben Danke Kerim
Hallo weiß jemand, ob es den David aka m00ncr4wler überhaupt noch gibt? Hat jemand in der letzten zeit, was von ihm gehört? Grüßle aus Kyritz Kerim