Attribute und Perfomance

[xmind]

Ich brauche für ein Produkt diverse Attribute. Die Attribute sind Textfelder oder Dropdownlisten. Mir ist dabei folgendes aufgefallen:

Ich habe einen Attributnamen [Branche], und diesem Namen Merkmale [diverse Branchen] zugeordnet und das ganze natürlich mit dem Attributmanager einem Produkt zugeordnet. Eigentlich wird dabei nicht mehr als ein HTML-Code produziert, der ein Select-Tag und die Option-Tags herstellt.

Gut, ich gebe zu, es sind halt 52 Optionen [es gibt halt einige Branchen]. Die sind zwar in keiner Art preisrelevant. Aber ich muss die Angabe haben, um das Produkt korrekt konfigurieren zu können.

Das Problem ist einfach beschrieben:
Ohne dieses Attribut (es hat die meisten Optionen) dauert der Seitenaufbau auch schon stolze:
Parse Time: 4.935 - Number of Queries: 1473 - Query Time: 3.2392811584473

Mit diesem Attribut erhöht sich der Wert auf unerträgliche:

Parse Time: 12.463 - Number of Queries: 2640 - Query Time: 7.3703369062042

Zen Cart benötigt also für das Produzieren des entsprechenden HTML-Codes (1x select, 52x option) schlappe 1167 Datenbankabfragen!!!

Meine Frage daher:
Wie kann ich das anders lösen oder wie kann ich das optimieren?

Könnte z.B. ein Produkt zwei Seiten haben, um nicht alle Attribute gleichzeitig darstellen zu müssen?

Könnte nicht der Select-Code von mir Hartcodiert eingebunden werden, damit dieser Codeschnippsel nicht von zen generiert werden muss?

Wo in Zen wird dieser Select-Code produziert? Ich habe in attributes.php oder im tpl_modules_attributes.php nicht entsprechendes gesehen. Dort werden zwar input-Tags verbaut, aber keine select- oder option-Tags.

[hintraeger]

Hab das gleiche Problem

Der Quellcode wird in attributes.php erzeugt und genau dort geht auch die Zeit verloren. Hab das ganze mal genauer untersucht um sicherzustellen, ob es mit Datenbankzugriffen zu tun hat oder mit der Auslastung des Servers oder ...
Das Performanceproblem liegt aber rein in der Ausführung des php-Quellcodes in attributes.php.
Wenn zuviele Attribute zusamenkommen dauert das einfach viel zu lange.
Hab auch schon überlegt ob es womöglich an der Anzahl der Attribute in er DB liegt, also auch durch Attribute verursacht, die dem Problemartikel garnicht zugeordnet sind.

Wär ehier auch für Hilfe dankbar.

Habe den Quellcode momentan statisch hinterlegt, was zu dem Problem führt, dass die Einstellungen der Attribute verlorengeht, wenn man vom Warenkorb über den Artikellink zurück zum Artikel springt.
Da muss ich irgendwie noch den Kontext herausfinden, in dem der Artikel geöffnet wird.

Gruß
Klaus

[webchills]

@xmind & hintraeger
Welche PHP-Version und welche MySQL-Version ist bei Euch im Einsatz?
Link zum Shop wär auch fein, auch gerne per PN

[hugo13]

Hab das ganze mal genauer untersucht um sicherzustellen, ob es mit Datenbankzugriffen zu tun hat oder mit der Auslastung des Servers oder ...
Das Performanceproblem liegt aber rein in der Ausführung des php-Quellcodes in attributes.php.

hab mal auf http://demo.zen-cart.at/index.php?ma...roducts_id=197 ~45 branchen eingefügt & tatsäclich verdreifacht sich die Query Time auf 0.53520327468872
das problem lieft allerdings nicht an der attributabfrage (das ist tatsächlich nur 1 query), sondern an der preis/steuer berechnung

[hintraeger]

Caching?

meine mysql Version 5.0.45
meine php Version 5.2.5

In includes/modules/attributes.php Zeile 72 while-Schleife über options_names und darin Zeile 106 while-Schleife über product_options
Hier geht die Zeit verloren.

Bis zum Ende der äußeren while-Schleife sind es ungefähr 600 Zeile php-code der bei einer großen Anzahl an Attributen und auch Attributsausprägungen ganz schön oft durchlaufen wird.
Also bei z.B. 10 Attributen mal im Schnitt 20 Ausprägungen, wären 200 * 600 Zeilen + diverse Funktionsaufrufe, das ist denke ich für eine Interpretersprache schon nicht ganz wenig.
Ich weis nicht, wie man den Code hier vereinfachen könnte.
Meiner Ansicht nach wäre ein Caching der Formularelement, deren Aktualisierung man im Backend anstossen könnte am elegantesten.
Ich habe bei mir den Code, der in diesen Zeilen erzeugt wird statisch eingebunden (im Backend gibt es selten Änderungen) dann habe ich perfekte Ladezeiten, kaum merklich. Muss dann allerdings immer wieder von Hand da ran. Nicht gerade optimal.

Gibt es bei zen-cart eigentlich ein Cachingkonzept für solche Dinge?
Also ich meine nicht das Caching der DB-Abfragen, die sind dneke ich eh nicht so relevant, zumindest wenn im Shop nicht soviele Besucher gleichzeitig unterwegs sind.
Also ein Caching ähnlich wie bei typo3 oder drupal oder anderen CMS-Systemen.

Gruß
Klaus

[hugo13]

In includes/modules/attributes.php Zeile 72 while-Schleife über options_names und darin Zeile 106 while-Schleife über product_options
Hier geht die Zeit verloren.

die zeit wird hier liegengelassen:

$new_attributes_price = zen_get_attributes_price_final($products_options->fields["products_attributes_id"], 1, '', 'false'); 

dies entspricht 22 db-queries pro attribut-ausformung; dies kannst du vermeiden, wenn du bei den artikel-attributen das ermässigt flag auf false setzt (== Rabatte verwenden die vom
Artikel verwendet werden = NEIN);
vergleiche die artikel http://demo.zen-cart.at/index.php?ma...roducts_id=200 && http://demo.zen-cart.at/index.php?ma...roducts_id=197

Meiner Ansicht nach wäre ein Caching der Formularelement, deren Aktualisierung man im Backend anstossen könnte am elegantesten.
Ich habe bei mir den Code, der in diesen Zeilen erzeugt wird statisch eingebunden (im Backend gibt es selten Änderungen) dann habe ich perfekte Ladezeiten, kaum merklich. Muss dann allerdings immer wieder von Hand da ran. Nicht gerade optimal.

preisrelevante sachen zu cachen, macht für mich keinen sinn; die attribute sind nicht nur "einfache" formularelemente sondern preisrelevant

Gibt es bei zen-cart eigentlich ein Cachingkonzept für solche Dinge?
Also ich meine nicht das Caching der DB-Abfragen, die sind dneke ich eh nicht so relevant, zumindest wenn im Shop nicht soviele Besucher gleichzeitig unterwegs sind.
Also ein Caching ähnlich wie bei typo3 oder drupal oder anderen CMS-Systemen.

es gibt 2 caching module
- http://www.zen-cart.com/forum/showthread.php?t=109160
- http://www.zen-cart.com/forum/showthread.php?t=116879
ob die der weisheit letzter schluss sind, weiss ich nicht
in typo3 hast du eine ähnliche caching problematik; kommt es zu user-bezogenem content ( & dies ist bei zen-cart ja der fall) wirds auch in typo3 recht eng;

mir erscheint dein server ein wenig schwach, da mein uralt läppi ungefähr auf gleiche seitenaufbau zeiten kommt

[xmind]

@ hintraeger: "Habe den Quellcode momentan statisch hinterlegt,..."

Bin auch gerade daran, dies zu versuchen. Habe eine spezielle tpl_modules_attributes_x.php angelegt, die aufgerufen wird, wenn ich das entsprechende Verzeichnis anwähle. Nur: Es ist immer noch langsam.
Wie hast Du es denn gemacht? Wo hast Du den statischen Code eingebunden?

@ webchills

Server Betriebssystem: Linux 2.4.34.2
Datenbank: MySQL 5.0.67
Server Up Time: 7:21pm up 49 days 10:33, 7 users, load average: 0.77, 0.34, 0.28
HTTP Server: Apache/1.3.34 (Unix) PHP/5.2.6
PHP Version: 5.2.6 (Zend: 2.2.0)
PHP Memory Limit: 128M
PHP Safe Mode: Off
Datenbank Daten Größe: 635 kB
Datenbank Index Größe: 546 kB

@ hugo13

Werde das mal probieren mit dem Rabatt-Flag.

[xmind]

ok, der tipp von hugo13 fruchtet.

vorher:

Parse Time: 6.276 - Number of Queries: 2673 - Query Time: 3.000489197998

nachher:

Parse Time: 0.553 - Number of Queries: 210 - Query Time: 0.23378545549011

damit kann ich leben.

[hintraeger]

@ hintraeger: "Habe den Quellcode momentan statisch hinterlegt,..."

Bin auch gerade daran, dies zu versuchen. Habe eine spezielle tpl_modules_attributes_x.php angelegt, die aufgerufen wird, wenn ich das entsprechende Verzeichnis anwähle. Nur: Es ist immer noch langsam.
Wie hast Du es denn gemacht? Wo hast Du den statischen Code eingebunden?

@ webchills

Server Betriebssystem: Linux 2.4.34.2
Datenbank: MySQL 5.0.67
Server Up Time: 7:21pm up 49 days 10:33, 7 users, load average: 0.77, 0.34, 0.28
HTTP Server: Apache/1.3.34 (Unix) PHP/5.2.6
PHP Version: 5.2.6 (Zend: 2.2.0)
PHP Memory Limit: 128M
PHP Safe Mode: Off
Datenbank Daten Größe: 635 kB
Datenbank Index Größe: 546 kB

@ hugo13

Werde das mal probieren mit dem Rabatt-Flag.

sorry für die späte Antwort, habe an diesem Projekt bisher nicht weiterarbeiten können.

Ich habe die statische Datei in includes/modules/pages/product_info/main_templates_vars.php eingebunden direkt vor tpl_page_body = 'tpl_product_info_display.php'
und mit return ausgestiegen.

Das ist aber sicher keine gute Lösung muss jetzt mal den Performancegewinn testen, wenn ichm wie von hugo134 vorgeschlagen Rabatte verwenden die vom
Artikel verwendet werden = NEIN setze.

Klaus