Extreme Performance Probleme, Artikelseite benötigt teilweise 20+ sec zum laden

Hallo liebe Oxid Gemeinde,

ein weiteres Problem beschäftigt mich derzeit mit unserem Shop.

Die Detailseiten mancher Artikel benötigtn teilweise über 20(!)Sekunden um zu laden.

Ich habe schon diverses ausprobiert, allerdings bringt lediglich opcode caching wirklich merkliche verbesserungen, allerdings auch apache errors mit sich…

Es handelt sich um einen Server mit folgender Hardwareausstattung, Athlon X2 240 mit 4 GB Ram.

Auf der Maschine läuft OpenSuse 11.2 mit dem aktuellsten Kernel, PHP 5.2.12, Apache 2.2.8 prefork, MySQL 5.0.51a.

Ich musste zu allererst mal das memory_limit in der php.ini auf 256M hochschrauben, da sonst diverse Artikel und der Bestellvorgang garnicht möglich waren (laut Debugging liegt der maximale Verbrauch der Skripts hier teilweise bei 190M!). Ohne entsprechenden Speicher gab’s nur eine weiße Seite, da die Ausfürung des Skripts wohl im Hintergrund abgeraucht ist aufgrund von Speichermangel.

Nun habe ich schon alle möglichen SQL Optimierungen durch, inklusive query_cache_size und generell maximierten cache und memore settings, allerdings komme ich gerade einmal auf folgende werte (tritt bei vielen Artikeln auf, meist haben die Artikel ca. 20 Varianten (mehrdimensional))

Execution time :17.2472
Memory usage: 136.355 MB (peak: 139.66 MB)
System memory usage: 139.75 MB (peak: 143.25 MB)
cl=details
----------------------------------------------------------
Profile start:	17.24834s	100.01%	1	*	17.24834s
Profile loadinglists:	10.02982s	58.15%	5	*	2.00596s
Profile selectVariants:	6.68478s	38.76%	2	*	3.34239s
Profile articleAssign:	6.62956s	38.44%	560	*	0.01184s
Profile articleAssignParentInternal:	2.78052s	16.12%	560	*	0.00497s
Profile articleAssignPrices:	1.97791s	11.47%	560	*	0.00353s
Profile smarty_function_oxmultilang:	1.68557s	9.77%	2323	*	0.00073s
Profile _getAmountPrice:	1.3524s	7.84%	560	*	0.00242s
Profile _getArticleUri:	0.55202s	3.2%	555	*	0.00099s

Alle weiteren Schritte laufen in unter 0.1s durch…

Jemand eine Idee wo hier der Hase im Pfeffer liegen könnte?

Schöne Grüße

Edit

Hier nochmal zum vergleich mit eAccelerator, und voll aufgebohrten SQL Caches


Execution time :16.2744
Memory usage: 136.347 MB (peak: 139.651 MB)
System memory usage: 139.75 MB (peak: 143.25 MB)
cl=details
----------------------------------------------------------
Profile start:	16.27519s	100%	1	*	16.27519s
Profile loadinglists:	9.93708s	61.06%	5	*	1.98742s
Profile selectVariants:	6.6238s	40.7%	2	*	3.3119s
Profile articleAssign:	6.56917s	40.36%	560	*	0.01173s
Profile articleAssignParentInternal:	2.75534s	16.93%	560	*	0.00492s
Profile articleAssignPrices:	1.9583s	12.03%	560	*	0.0035s
Profile smarty_function_oxmultilang:	1.50664s	9.26%	2323	*	0.00065s
Profile _getAmountPrice:	1.34732s	8.28%	560	*	0.00241s

und


mysql

Parameter	Value	Description
Ratios  
MyISAM cache hit ratio	97.91	 
InnoDB cache hit ratio	100	 
sql cache hit ratio	85.26	 
IO  
data reads	7	Number of selects (Key_reads is not accurate)
data writes	4	Number of inserts/updates/deletes * coef (Key_writes is not accurate)
Data Cache  
MyISAM data cache size	128M	 
BDB data cache size	Error:	 
InnoDB data cache size	256M	 
Memory Usage  
read buffer size	1020K	(per session)
sort buffer size	2097144	Size of sort buffer (per session)
table cache	2048	Number of tables to keep open
Connections  
current connections	3	 
max connections	100	 

Hat ja nicht wirklich was gebracht :slight_smile:

Niemand eine Idee wo man hier ansetzen kann?

Habe bereits gzip aktiviert, ein bisschen mit indizes in den Tabellen gespielt etc.

Denke momentan noch über den Einsatz von opcode caching nach, aber bezweifle das hier ein Erfolg zu verzeichnen wäre.

Könnte das Performanceproblem evtl. durch unser Modul für mehrdimensionale Varianten (das von D3) hervorgerufen werden?

Oder skaliert der Oxid Shop einfach so schlecht wenn Produkte rund 400 Varianten (Größen / Farbkombinationen bei Kleidung) besitzen?

[QUOTE=RagePX;39742]Niemand eine Idee wo man hier ansetzen kann?

Habe bereits gzip aktiviert, ein bisschen mit indizes in den Tabellen gespielt etc.

Denke momentan noch über den Einsatz von opcode caching nach, aber bezweifle das hier ein Erfolg zu verzeichnen wäre.

Könnte das Performanceproblem evtl. durch unser Modul für mehrdimensionale Varianten (das von D3) hervorgerufen werden?

Oder skaliert der OXID Shop einfach so schlecht wenn Produkte rund 400 Varianten (Größen / Farbkombinationen bei Kleidung) besitzen?[/QUOTE]
Dein Problem sind definitiv die Varianten…

Profile loadinglists: 10.02982s 58.15% 5 * 2.00596s
Profile selectVariants: 6.68478s 38.76% 2 * 3.34239s
Profile articleAssign: 6.62956s 38.44% 560 * 0.01184s
Profile articleAssignParentInternal: 2.78052s 16.12% 560 * 0.00497s
Profile articleAssignPrices: 1.97791s 11.47% 560 * 0.00353s
Da geht OXID ziemlich schnell die Puste aus, wie man auch an den obigen Profiling-Zeiten sieht.

Was vor allem merkwürdig ist, dass einige Teile gleich 5 mal ausgeführt werden, wo eigentlich ein Durchlauf reichen sollte.

[B]Da muss unbedingt in OXID nachgebessert werden,

[/B]IMO ist das Variantenkonzept von OXID so nicht wirklich brauchbar,

So viele Varianten kann aber auch kein Besucher mehr verstehen…

Müssen das unbedingt Varianten sein, oder reichen auch Auswahllisten?

OXID-Auswahllisten haben natürlich das Problem, dass sie sehr limitiert sind.

So haben sie standardmäßig keine Artikelnummer, -Beschreibung und -Lagerbestand.

Wir haben das Auswahllistenkonzept für einen Kunden daher ziemlich aufgebohrt, um genau die zuvor genannten Probleme zu lösen.

Wenn man z.B. ein Produkt wie dieses nimmt ( http://www.alternative-haustechnik.de/Gas-Brennwerttechnik/Broetje/Abgassysteme/KAS-80-2-Abgasleitung-einwandig-im-Schacht-DN80.html ), so hat dieses aufgrund der vielen Optionen schlappe 11.943.936.000 (knapp 12 Milliarden) Varianten(Produkt(!) aus den möglichen Optionen pro Eigenschaft)

Dabei sieht das doch so harmlos aus…

Mit (modifizierten) Auswahllisten noch handhabbar mit Varianten sicher nicht mehr…

Durch unsere Erweiterungen hat man auch die Möglichkeit, jeder Option ein Bild und Kurz-/Lang-Beschreibungen zuzuordnen.

In dem zuvor gezeigten Produkt wird das nicht genutzt, aber z.B. hier: http://www.alternative-haustechnik.de/Biomasse/KWB/KWB-Easyfire-Typ-USP-S-mit-Knickschnecke.html?searchparam=kwb

Da ist bei einigen Optionen eine Beschreibung und Bild vorhanden, was natürlich beim Wechsel der Option mit ausgetauscht wird.

Eine Lagerbestandsführung pro Option ist auch möglich.

Hi,

erst mal danke für deine Antwort avenger!

Ich habe jetzt mal ein wenig herumexperimentiert, und zum Beispiel deaktiviert das der Artikel nochmal in der Detailseite mit einer kompletten Variantenauswahlbox unten angezeigt wird, die “zuletzt angesehenen Artikel” deaktiviert, das Crosselling abgeschaltet, einige Indizes in der DB gesetzt und xCache installiert.

Das Ergebnis ist das wir jetzt wenigstens schonmal auf gute 5 Sekunden Execution time gekommen sind, was gefühlt immer noch eine Ewigkeit ist :slight_smile:

Profile start:	5.06697s	100.02%	1	*	5.06697s
Profile loadinglists:	4.35459s	85.96%	3	*	1.45153s
Profile selectVariants:	4.33581s	85.59%	4	*	1.08395s
Profile articleAssign:	4.26159s	84.12%	556	*	0.00766s
Profile articleAssignPrices:	1.95646s	38.62%	556	*	0.00352s

Bezüglich der Variantenproblematik, wir setzen Oxid schon seit Version 4.1 ein und dort waren mehrdimensionale Varianten so wie wir sie Benötigen noch nicht vorhanden. Daher haben wir hier das D3 Modul gekauft und nutzen dies seitdem (auch jetzt mit der 4.4er).
Ich denke nicht das sich das Ganze so über Auswahllisten realisieren lassen würde (zumindest nicht ohne sehr viel Aufwand), wir haben hier wie gesagt Kleidung im Shop und wenn du bei einem T-Shirt Rot / Größe L wählst, dann wird dir auch hier das entsprechende Bild angezeigt.
Zumal bei einigen Sachen unterschiedliche Größen auch unterschiedliche Preise haben.

Was genau wir während der “Profile” die im debug angezeigt werden eigentlich gemacht? Kann man das irgendwo einsehen was genau zB Bestandteil von “loadinglists” ist?

Vielleicht kann man hier noch optimierungspotenzial finden :slight_smile:

Schöne Grüße

[QUOTE=RagePX;39760]Was genau wir während der “Profile” die im debug angezeigt werden eigentlich gemacht? Kann man das irgendwo einsehen was genau zB Bestandteil von “loadinglists” ist?

Vielleicht kann man hier noch optimierungspotenzial finden :slight_smile:

Schöne Grüße[/QUOTE]
Um das zu sehen muss man mit einem Debugger den Ablauf im Quellcode nachverfolgen.

Habt Ihr das schon mal ohne das Modul probiert?

Was mich schon stört ist, dass manche Code-Teile 5 mal durchlaufen werden.

Ich weiss nicht, ob OXID das auch alleine so macht.

Also ohne das Modul mit mehrdimensionalen Varianten im Oxid selbst aktiviert ändert sich an den laufzeiten nichts. Gut ausser das der Arikel dann nicht jedes mal wenn man ein Attribut auswählt komplett neu geladen wird. (Dafür kann man aber auch nicht direkt Größe + Bild sehen).

Ich habe auch zusätzlich mal das “FastOxid” modul (alist => fastOxid/foalist) eingebaut, das bringt auch noch mal runde 0,3 Sekunden in der Execution time.

Was mich wundert ist das die Querys alle wirklich relativ schnell durchlaufen werden (fast alles im Bereich von 0,00Xs). Also muss doch der Hase da irgendwo im Php code liegen?

Ich meine wir haben das jetzt auf nem relativ flinken dedizierten Server.

Core i7-920
8GB Ram

Apache, php, mysql alles aktuell.

Da muss doch irgendwie mehr rauszuquetschen sein :frowning:

Hallo,

wir haben genau das gleiche Problem, sind inzwischen auf einem Server mit 24 Gb Ram usw. und es ist trotzdem noch teilweise sehr langsam. Das betrifft bei uns nur die Produktseiten, der Rest ist schnell genug.
Unser Provider sagte das es am PHP liegt und nicht an der Datenbank. Wenn man es mit unserem vorherigen XT-Commerce Shop vergleicht ist es eine massive Verschlechterung.
Wir wären daher auch an einer Lösung des Problemes sehr interessiert!
Wir würden es auch gerne irgendwo in Auftrag geben, nur wissen wir nicht so richtig wer in diesem Bereich schon Erfahrungen hat…

Gruß, Eike