ShopNix

Tagebuch eines Shops auf Basis von osCommerce

Posts Tagged ‘xtCommerce

Artikel Import aus xtCommerce und CAO nach OpenERP

with 3 comments


Ein Kunde will von seinem alten Warenwirtschaftssystem CAO auf OpenERP umsteigen. Natürlich will er seine Artikel nicht noch einmal von Hand eintupfen.

Dabei stellt sich das Problem, daß er nur die aktiven Artikel aus dem Shop übernehmen will, wesentliche Daten jedoch nur in CAO vorhanden sind.

Deshalb werde ich die Artikel aus dem Shop holen und nach OpenERP importieren. Anschließend schiebe ich einzelne Attribute aus CAO nach.

Die Kunden sollen komplett aus CAO WaWi übernommen werden.

Direkt in die Datenbank von OpenERP zu schreiben ist zwar möglich, aber es bietet sich an, die XML-RPC-Schnittstelle des ERP-Systems zu nutzen. Damit soll sichergestellt werden, daß alle notwendigen Referenzen und Abhängigkeiten erfüllt werden.

Grundlage ist das Beispiel aus der Dokumentation.

Die Methode funktioniert an sich sehr gut. Die Ermittlung der erforderlichen Attribute kann über den Debug-Modus des OpenERP-Clients erfolgen. Dazu wird der Client im Terminal mit dem entsprechenden Parameter gestartet und die Ausgabe auf eine Datei umgeleitet.
./openerp-client.py -l debug_rpc &> ~/debug_rpc.txt

Ein Problem, das ich nicht lösen konnte: Der Primärschlüssel wird ignoriert. Im Allgemeinen ist das nicht kritisch, lediglich für den Kategoriebaum kann ich die Daten nicht übernehmen.

Sollte irgendjemand in der großen weiten Welt eine Lösung haben, möge er die Kommentarfunktion nutzen!

Advertisements

Written by spessart

27. August 2011 at 09:09

Performance Optimierung

leave a comment »


Alle Queries aus den Programmen zu ziehen, einzeln zu überprüfen und zu optimieren scheint eine Aufgabe für Sisyphos zu sein. Ganz so schlimm wird es allerdings nicht, wenn wir betrachten, daß der Bereich, der wirklich ins Gewicht fällt, doch relativ beschränkt ist. Gerade von den Suchmaschinen werden nur wenige Programme gezogen, wenn robots.txt richtig gepflegt ist. Schwerpunkt der Forschung müssen also die Programme sein, die robots.txt erlaubt, der Schwerpunkt ist index.php und die includierten Module.

index.php enthält keine relevanten Queries.

Fündig werde ich in den Boxen, wobei mir eine Schwäche des Template-Systems auffällt. Eine Trennung von Layout und Inhalt, die Funktionalität im Layout versteckt? Nicht so ganz gelungen.

  • templates/XXX/source/boxes/best_sellers.php
  • templates/XXX/source/boxes/whats_new.php
  • includes/modules/upcoming_products.php

Die drei Scripts sind wesentliche Übeltäter. Die Bestsellers sind leicht zu fassen, den Term
current_category_id in (c.categories_id , c.parent_id)
ersetze ich durch
(c.categories_id = '" . (int)$current_category_id . "' or c.parent_id = '" . (int)$current_category_id . "')
In Zusammenhang mit den richtigen Indizes zur Tabelle categories ist dieses Problem erledigt.

Die beiden anderen Fälle sind nicht so leicht zu lösen. Hier wird wohl eine andere Lösung notwendig.

Fortsetzung folgt. 😉

Written by spessart

22. April 2009 at 15:00

xt:Commerce – Performance

leave a comment »


Nach Einbau eines Moduls für suchmaschinenfreundliche URL brach die Performance des Systems erneut zusammen. Es wird nichts über bleiben, als mit Hilfe der Logfiles die SQL-Queries zu analysieren und nach und nach zu optimieren. MySQL hat, wie jede brauchbare Datenbank, einige Instrumente um ungünstig formulierte Queries aufzustöbern. Im ersten Schritt schalte ich in der Konfiguration (Debian: /etc/mysql/my.cnf) das Protokoll für langsame Queries ein. Für mich sind die folgenden Parameter geeignet:

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes

Ich protokolliere also alle Queries, deren Ausführung länger als 2 Sekunden dauert, und solche die keine Indizes verwenden, in einem eigenen Log-File. Ein Beispiel eines solchen Queries:

select distinct p.products_id, p.products_price, p.products_tax_class_id,
  p.products_image, pd.products_name
from  products p, products_description pd, products_to_categories p2c, categories c
where p.products_status = '1' and c.categories_status = '1'
  and p.products_ordered > 0
  and p.products_id = pd.products_id
  and pd.language_id = '2'
  and p.products_id = p2c.products_id
  and p2c.categories_id = c.categories_id
  and '424' in (c.categories_id, c.parent_id)
order by p.products_ordered desc limit 10;

Im MySQL-Client führe ich dieses Query mit dem vorgestellten Schlüsselwort EXPLAIN aus und erhalte als Ergebnis unter anderem die Zahl der sequentiell abgearbeiteten Datensätze. In meinem Beispiel sind das 1786 Datensätze. Davon werden 1780 Sätze verworfen, denn mein Query liefert unterm Strich nur 6 Datensätze zurück. Ändere ich die vorletzte Zeile meines Queries in:

  and (c.categories_id = '424' or c.parent_id = '424')

kann der Optimizer auf Primärschlüssel zurückgreifen und das Query wird performant abgearbeitet. Damit ist zwar die technische Lösung gefunden, aber leider noch lange nicht implementiert. Diese Methode zeigt mir nämlich nicht, wo das Query in der Software vorkommt. Da die Queries in der Shop-Software dynamisch zusammengebaut werden, kann ich auch nicht ohne weiteres nach einer Zeichenkette suchen. Es ist eben wie so oft: Vor den Preis haben die Götter den Schweiß gesetzt.

Dieses spezielle Query fand ich in templates/XXX/source/boxes/best_sellers.php, und stoße damit auf eine erhebliche Schwäche des vielgerühmten Templatesystems. Offensichtlich gelang es nicht, Code und Design zu trennen, denn das Query ist im „Design“ enthalten.

Written by spessart

18. April 2009 at 21:14

Veröffentlicht in Performance, xtCommerce

Tagged with , , ,

xt:Commerce – MySQL 5.0 – Performance

leave a comment »


Die Performance von xt:Commerce ist generell schlechter als die von osCommerce. Das ist zum einen zwangsläufig so, weil mehr Features eben auch mehr Aufwand bedeuten. Ein Teil der Probleme liegt allerdings auch in der kleinen Installationsbasis, die zwangsläufig zu geringerem Feedback führt.

Einen Teil der Probleme kann man durch Tuning der Datenbank reduzieren. Sehr hilfreich ist dazu das Script tuning-primer.sh das z.B. mit wget http://www.day32.com/MySQL/tuning-primer.sh erhältlich ist. Unter Debian ist das Paket bc Voraussetzung für das Script.

Entsprechend der Empfehlungen des Scripts habe ich die Parameter table_cache, read_buffer und join_buffer_size angehoben.

Anschließend habe ich eine Meldung im Supportforum abgesetzt und erhielt postwendend Antwort:

ALTER TABLE `shipping_status` ADD INDEX ( `language_id` );
ALTER TABLE `products` ADD INDEX ( `products_startpage` );
ALTER TABLE `products_to_categories` ADD INDEX ( `categories_id` );
ALTER TABLE `orders_products` ADD INDEX ( `orders_id` , `products_id` );
ALTER TABLE `zones_to_geo_zones` ADD INDEX ( `geo_zone_id` );
ALTER TABLE `tax_rates` ADD INDEX ( `tax_zone_id` );
ALTER TABLE `products` ADD INDEX ( `manufacturers_id` );

Damit reduziert sich das Problem (zumindest auf den ersten Blick) ganz erheblich.

Auf Grund meiner Auswertungen werde ich wohl noch einige Schlüssel hinzufügen. Dabei ist zu beachten, daß diese Indizes natürlich auch von der installierten Version und eventuellen Zusatzmodulen abhängen.

alter table whos_online add index (session_id);
alter table whos_online add index (time_last_click);
alter table specials add index (expires_date);
alter table products add index (session_id);
alter table personal_offers_by_customers_status_1 add index (products_id);
alter table products_description add index (language_id);
alter table customers add index (customers_status);
alter table products add index (products_ordered);
alter table specials add index (products_id);
alter table orders add index (orders_status);
alter table customers add index (customers_email_address);
alter table search_keywords add index (search_text);
alter table products_xsell add index (products_id);
alter table products_xsell add index (products_xsell_grp_name_id, products_id);
alter table content_manager add index (language_id, content_group);

Um Notwendigkeit und Wirkung eines Schlüssels zu testen, betrachte ich zunächst die Queries, die in mysql-slow.log protokolliert werden und kopiere sie mit dem vorangestellten Schlüsselwort „explain“ in den MySQL-Client zur Ausführung. Dann lege ich den oder die Schlüssel an, von denen ich mir eine Performancesteigerung erwarte. Anschließend lasse ich mir wieder mit explain die Auswirkungen anzeigen. Wenn ein Schlüssel keinen Vorteil bringt, lösche ich ihn sofort wieder, denn auch ein Index zuviel ist nicht gut für die Gesamtleistung des Systems.

Written by spessart

30. März 2009 at 16:15

Veröffentlicht in osCommerce, Performance, xtCommerce

Tagged with , ,

xt:Commerce vs osCommerce

leave a comment »


Das Shopsystem xt:Commerce ist ein Abkömmling oder Branch von osCommerce. Zwar widerspricht das System meiner Philosophie eines möglichst schlanken Systems, dafür sind einige nette Gimmicks enthalten, die sich meine Kunden wünschen.

Erste Erfahrungen zeigen, daß der Umstieg (für den Programmierer) nicht ganz einfach ist, und mit einiger Wahrscheinlichkeit für keinen Beteiligten allzu großen Vorteile bringt.

Das beginnt mit der in xt integrierten Template-Engine, die Applikation und Layout (oder Design) voneinander trennen soll. Das ist mit einigem Aufwand verbunden, aber nicht vollständig gelungen.

Weiteres in Kürze.

Written by spessart

16. September 2008 at 11:58

Veröffentlicht in osCommerce, xtCommerce

Tagged with , ,