ShopNix

Tagebuch eines Shops auf Basis von osCommerce

Archive for April 2009

Linkverfolgung

leave a comment »


Ich möchte gerne wissen, wie gut externe Links auf meinen Shop bzw. auf einzelne Produkte angenommen werden. Die einfachste Möglichkeit, solche Links differenziert aufzunehmen ist die Vergabe einer ID, die an den Link angehängt wird. An zentraler Stelle (am Ende des Scripts includes/application_top.php) hänge ich eine Funktion an, die auf die GET-Variable „idseo“ prüft und ggfls. einen Zähler hochsetzt. Dazu ist natürlich auch die neue Tabelle sx_idseo in der Datenbank nötig.

Der Link sieht dann beispielsweise so aus:

http://vapr.shopnix.de/shop/product_info.php?products_id=26&idseo=3

So kann ich z.B. auch sehen, ob eine geschaltete Anzeige gut angenommen wird, ob mir ein Bannertausch den erwünschten Erfolg bringt und vieles mehr. Natürlich soll das im Backend abzufragen und zu verwalten sein.

Dazu kopiere ich zunächst die Dateien languages.php (Programm und Sprachkonstanten) auf sx_idseo.php und passe entsprechend an.

Dann kommt natürlich der Menüeintrag hinzu, und das alles funktioniert nur, wenn ich auch die Tabellen und Dateinamen als Konstanten in database_tables.php und filenames.php hinterlegt habe.

Solche Techniken können unter der Rubrik SEO (Search Engine Optimization) oder Suchmaschinenoptimierung verbucht werden.

Advertisements

Written by spessart

27. April 2009 at 16:26

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 , , ,