Performance - Hallo Herr Steinhäuser

Moin Oxid Gemeinde,

[B]Problem:[/B]
Shop ist relativ langsam - www.Kettensaegen-Saegeketten.de

[B]Ist Zustand:[/B]

  • 10.000 Artikel
  • Sehr viele Kategorien
  • Sehr viele Variablen

[B]Tests durchgeführt, folgendes hilft:[/B]
Wenn man nur wenige Kategorien anlegt, ist der Shop wesentlich schneller…
[B]Hat hier jemand eine Idee/Lösung?[/B] (Am Server liegt es nicht!)

Gruß Holger

und warum schreist du nach marco ??

und warum solls nicht am server liegen - schreib doch mal hier rein was überhaupt für einer das is

Yep, verstehe ich auch nicht, warum du an Marco schreibst.
Schreib doch bitte was für eine Serverkonfig du hast. Hast du mit den Performanceeinstellungen mal rumprobiert. Da kannst du einiges rausholen.

Hallo

Welche konkreten Angaben benötigen Sie, wenn Sie fragen welche Serverkonfiguration man hat? Wo stehen diese geschrieben? In meinem Vertrag mit meinem Provider stehen diese jedenfalls nicht. Können Sie dann konkrete Hilfestellung anbieten?

Ich kann die Probleme von Holger Lehmann nur bestätigen, weil ich unter ähnlichen Bedingungen die gleichen Probleme im neuen PE4er habe. Und diese können nur auf den Shop bzw. die neue Datenbank selbst zurückgeführt werden, da die Bedingungen wie Performanceeinstellungen im 3er und 4er Shop bei mir gleichgeblieben sind. Auch im Admin bei Aufruf des Reiters Stamm ist bei mir die Ladezeit deutlich länger als im 3er Shop.
Das Problem wurde damals von Oxid eingeräumt - es kam dann Monate später irgendein Patch - die Probleme blieben aber - was aber Oxid anscheinend nicht weiter störte. Ich nehme an dass der Kollege deshalb auch nach Marco schreit.

Entschuldigung - vielleicht will man mit dem Oxid-Shop auch was verkaufen und nicht an irgendwelchen Servereinstellungen herumspielen. Mein Provider könnte veränderte Servereinstellungen a´la avenger gegen Bezahlung testen - dazu müßte man aber erst wissen welche genau für den eigenen Shop sinnvoll sind. Aber warum zahlt man viel Geld für ein Update und muß dann noch zusätzlich für die Behebung von Problemen zahlen??
Schließlich sollte man davon ausgehen dass nach einem Shopupdate der Shop schneller und nicht langsamer wird.

Warum äußert sich OXID nicht einmal dazu und sucht den Fehler bei sich selbst und nicht nur bei den Anderen, wenn diese offenkundig sind?

Für konkrete konstruktive Lösungsvorschläge bin ich dankbar!

[QUOTE=hboliver;22971]Mein Provider könnte veränderte Servereinstellungen a´la avenger gegen Bezahlung testen[/QUOTE]
Die ändern nichts an den internen Verarbeitungsprozessen, sondern optimieren nur den Transport und die Kommunikation zwischen Browser und Server …

Warum Dein Provider dafür Geld haben will ist mir allerdings unverständlich…

Das sind ein paar Zeilen in der .htaccess (bzw. PHP.INI, wenn PHP als CGI konfiguriert ist…).

Als erstes würde ich mal in der config-Datei “[B]$this->iDebug = 4;[/B]” setzen, dann erhält man bei jedem Seitenaufruf am Ende der Seite [B]detaillierte [/B]Informationen über die Zeiten, die im Programmcode für bestimmte Operationen und der Datenbank “verbraten” werden…

Dann kann man mal anfangen zu schauen, wo es hängt…

csimon hat zum gleichen Thema ja schon mal seine Erfahrung als Dienstleister bei einigen PE3=>PE4-Migrationen geäußert.

Und die ist, dass PE 4 i.d.R. [B]schneller [/B]ist als PE 3…

[QUOTE=avenger;22975]Als erstes würde ich mal in der config-Datei “[B]$this->iDebug = 4;[/B]” setzen, dann erhält man bei jedem Seitenaufruf am Ende der Seite [B]detaillierte [/B]Informationen über die Zeiten, die im Programmcode für bestimmte Operationen und der Datenbank “verbraten” werden…Dann kann man mal anfangen zu schauen, wo es hängt…[/QUOTE]

Danke für den Tipp. Da ich die Auswertung offensichtlich alleine machen müßte - Oxid hilft mir wohl dabei nicht :smiley: - wäre es doch einen Versuch Wert Deine Einstellungen wie auf dem Link damals von Dir beschrieben gleich einfach auf dem Server zu testen - Schlimmer kanns ja fast nicht werden. [B]Was hältst Du davon?[/B]

Mag sein dass der 4er schneller ist als der 3er bei Artikeln mit wenigen Varianten und bei geringer Kategorienanzahl. Wenn sich diese aber erhöhen, behaupte ich dass der 4er unter dieser Konstellation ein generelles Performance-Problem hat. Ein oxidnaher Systembetreuer und mein Provider haben es ebenfalls bereits festgestellt. Außerdem waren wie gesagt waren alle Einstellugen im Admin und Bedingungen unverändert. Das läßt wohl nicht mehr viele andere Schlüsse zu. Und wie siehts bei Euch eigentlich beim Laden des Stamm-Menüs unter Produlte verwalten -> Produkte aus. Nicht umsonst hat Oxid in der 4er Version eine Sanduhr eingebaut. Oxid hat das Performance-Problem seinerzeit selbst mit dem angekündigten Patch eingeräumt - nur hat es m.E. nichts gebracht. Und was hilft es mir, wenn es in der Regel schneller in der 4er Version von statten geht, wenn ich nicht zu der Regel gehöre und anscheinend ein paar Andere auch nicht. Warum kann mir der bezahlte Telefonsupport von Oxid nicht weiterhelfen. Die sind gut zum Erklären von Dingen wenn man noch nie mit einem Online-Shop zu tun hatte, aber mit solchen Fragen überfordert.
LG :wink:

Ich fand die Performance der CE auch für einen Moment als nicht ausreichend. Im Vergleich zu unserem alten Shopsystem auf Cold Fusion-Basis dauerte es eine Ewigkeit, bis der Server mal eine HTTP-Antwort startete…

Habe es dann mit Xcache hingekriegt (Cache für die PHP-Skripte).

http://xcache.lighttpd.net/

Hat die Antwortzeit etwa halbiert und zusammen mit einer HTTP-Kompression im Apache-Webserver sind die Seiten nun nach maximal 1,5 Sekunden komplett beim Client-Browser.

Das ist ausreichend.

Gruß,
Achim

[QUOTE=oxal;23191]Ich fand die Performance der CE auch für einen Moment als nicht ausreichend. Im Vergleich zu unserem alten Shopsystem auf Cold Fusion-Basis dauerte es eine Ewigkeit, bis der Server mal eine HTTP-Antwort startete…

Habe es dann mit Xcache hingekriegt (Cache für die PHP-Skripte).

http://xcache.lighttpd.net/

Hat die Antwortzeit etwa halbiert und zusammen mit einer HTTP-Kompression im Apache-Webserver sind die Seiten nun nach maximal 1,5 Sekunden komplett beim Client-Browser.

Das ist ausreichend.

Gruß,
Achim[/QUOTE]

Hallo Achim,

Danke für den Tipp. Aber:

Ich habe inzwischen ein noch größeres Performance-Problem: Ladezeit eines Variantenartikels (100 Varianten) im 3er Shop auf alter Hardware: 2 Sekunden. Im neuen 4er Shop unter gleichen Bedingungen: mindestens 10 Sekunden im Frontend. Mit neuer Hardware (IntelCore 2 Quad) 4MB RAM 4 Sekunden im 4er Shop und 0,5 Sekunden im 3er Shop. Bin ziemlich verärgert bei gleichen Performance-Einstellungen im Shop. Nach 1 1/4 Jahren Umstellungszeit auf die 4er Version nun das. Profihost kann sich diesen Performcanceabfall auch nicht erklären. O.K es gibt Schlimmeres, aber wirklich prickelnd ist das nicht.:smiley:

Das XCache wird von allen beteiligten Profis eher als letzte mögliche Optimierungsmaßnahme angesehen, da bei mir bereits ein ähnlicher Optimierer eaccelerator auf dem Server installiert ist. Was meinst Du Oxal eigentlich mit HTML-Komprimierung? Wie sieht die Implementierung von XCache bei Dir konkret auf dem Server aus?

Eine Auswertung wie von avenger empfohlen brachte Folgendes.

Bei Aufruf des Artikels folgende Meldung:

Profile start: 2.86719s 103.15% 1 * 2.86719s
Profile articleAssign: 1.87808s 67.57% 230 * 0.00817s
Profile loadinglists: 1.84765s 66.47% 5 * 0.36953s
Profile selectVariants: 1.68812s 60.73% 8 * 0.21102s
Profile loadVariants: 0.83749s 30.13% 14 * 0.05982s
Profile articleAssignPrices: 0.61305s 22.06% 230 * 0.00267s
Profile articleAssignParentInternal: 0.41806s 15.04% 230 * 0.00182s
Profile _getAmountPrice: 0.21262s 7.65% 658 * 0.00032s
Profile oxNew: 0.15554s 5.6% 4190 * 4.0E-5s
Profile _getArticleUri: 0.05413s 1.95% 114 * 0.00047s
Profile _applyVAT: 0.03821s 1.37% 364 * 0.0001s
Profile buildTree: 0.02525s 0.91% 1 * 0.02525s
Profile _assignPriceInternal: 0.02121s 0.76% 226 * 9.0E-5s
Profile fround: 0.01409s 0.51% 2802 * 1.0E-5s
Profile getCategoryUri: 0.01399s 0.5% 36 * 0.00039s
Profile getCategory: 0.00459s 0.17% 1 * 0.00459s
Profile _getLangTranslationArray: 0.00351s 0.13% 115 * 3.0E-5s
Profile MultiVariant::GetFullVariantList: 0.00275s 0.1% 1 * 0.00275s
Profile _sortCats: 0.0015s 0.05% 1 * 0.0015s
Profile tagCloud: 0.00127s 0.05% 1 * 0.00127s
Profile parseThroughSmarty: 0.00122s 0.04% 93 * 1.0E-5s
Profile oxviewconfig::getViewConfigParam: 0.00103s 0.04% 174 * 1.0E-5s
Profile MultiVariant::check4MultiVariant: 0.00078s 0.03% 4 * 0.0002s
Profile MultiVariant::GenerateVarSelectList: 0.00041s 0.01% 1 * 0.00041s
Profile oxviewconfig::__get: 8.0E-5s 0% 1 * 8.0E-5s
Profile oxviewconfig::setViewConfigParam: 5.0E-5s 0% 12 * 0s

Kann es sein dass es daran liegt dass der neue PE4 Shop mit dem mehrdimensionalen Variantenmodul von D3 nicht mehr so gut kann?

Wenn jemand eine Idee hat gerne - habe auch nichts gegen eine konstruktive Stellungnahme von Oxid.

Dabei sollten auch Informationen über die SQL-Zugriffe auf die Datenbank angezeigt werden…

Was man aus dem PHP-Profile sehen kann ist das eigentlich alles im grünen Bereich

Profile start: 2.86719s 103.15% 1 * 2.86719s
Der komplette Programmdurchlauf dauerte 2.86719s.

Auffällig sind diese Operationen…

Profile loadinglists: 1.84765s 66.47% 5 * 0.36953s
Profile selectVariants: 1.68812s 60.73% 8 * 0.21102s
Alles andere liegt im Milli- bis Mikro-Sekunden-Bereich.

Man sollte sich jetzt mal die ADODB-Statistik, die bei diesem Debug auch erzeugt wird, genauer ansehen, welche SQL-Befehle hier Zeit fressen…

In Deinem letzten Posting war an dieser Stelle ein Fehler in ADODB vermerkt, vermutlich beim Aufruf dieser Statistik, meiner Erinnerung nach ging es da um fehlende Zugriffsrechte auf die Datenbank…

Wenn solche ADODB-Exceptions auch im laufenden Betrieb auftreten, kann das natürlich auch viel Zeit fressen…

…habe auch nichts gegen eine konstruktive Stellungnahme von OXID.
Du darfst nicht vergessen, dass das hier ein “Community”-Forum ist, bei dem sich die OXID AG (richtigerweise!?) mit direktem Support zurückhält.

Aber als PE-Support-Kunde solltest Du doch Zugriff auf den Support haben…

Wobei solche Probleme allerdings m.E. auch schon über den Rahmen normaler Hotline-Fragen hinaus gehen, da man schon ein profundes Wissen in einigen Bereichen mitbringen muss.

Solche Analysen schüttelt man nicht einfach mal so aus dem Ärmel…

[QUOTE=hboliver;23652]
Das XCache wird von allen beteiligten Profis eher als letzte mögliche Optimierungsmaßnahme angesehen, da bei mir bereits ein ähnlicher Optimierer eaccelerator auf dem Server installiert ist. Was meinst Du Oxal eigentlich mit HTML-Komprimierung? Wie sieht die Implementierung von XCache bei Dir konkret auf dem Server aus?
[/QUOTE]

Hi,

ich denke, dass e-accellerator und xcache im prinzip das selbe erledigen. müßte mal geprüft werden, ob dein webserver auch so konfiguriert ist, dass deine oxid-installation wirklich in den genuß des php-cachings kommt.

besonders installiert habe ich das teil bei mir nicht, halt nach anleitung. man muß aber eben in der konfig des apache auch die richtigen module laden. wenn dein provider sagt, dass er den eaccellerator auf deinen oxid losgelassen hat, tja dann weiss ich auch nicht.

HTTP-kompression kriegt man mit dem apache-modul mod_deflate.so - das erhöht die cpu-last des servers unmerklich, reduziert aber den rausgehenden texttraffic auf 20%. kannst du gut im firebug unter netzwerk überprüfen. da muß dann stehen, dass deine dateien mit gzip ausgeliefert werden. die oxid.css ist dann zB nur noch 11 KB gross.

http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

allerdings hilft dir das nur nach den 2,8 Sekunden, nach denen es bei Dir erst los geht.

viel erfolg,
achim

Hallo,

Du darfst nicht vergessen, dass das hier ein “Community”-Forum ist, bei dem sich die OXID AG (richtigerweise!?) mit direktem Support zurückhält.

Danke Avenger, so ist es. Meist liegt es auch einfach am bösen Zeitfaktor, ich schaffe es kaum noch, im Forum mitzulesen. Die oben beschriebenen Probleme lassen sich ganz sicher auch nicht über’s Forum mal schnell so debuggen sondern erfordern ganz sicher Zugriff auf das System; dafür gibt’s einen Support- und Wartungsvertrag und eine ganz eigene Abteilung namens “Support”, die nicht nur telefonisch erreichbar ist sondern auch per E-Mail Dinge bewegen kann.

Gruß