wir nutzen die CE-Version 4.7.6
Derzeit haben wir arge Probleme mit der Geschwindigkeit im Shop.
Erst haben wir dies auf das Echtzeitmodul von idealo geschoben, weil dort
eine trigger.php in regelmäßigen Abständen unseren Shop kontaktiert.
Wir haben das Modul also deaktiviert, die Geschwindigkeitseinbußen bleiben.
Nun ist uns aufgefallen, daß wenn wir im Backend arbeiten (wir haben einige Artikel mit jeweils 30 Varianten gelöscht) das Frontend fast zum Stillstand kommt. Zugriffszeiten von 12 Sekunden und mehr…
Ebenfalls bleibt der Shop fast stehen, wenn man die implementierte Suchfunktion nutzt. Die phonetische Suche liefert rasend schnell ein Ergebnis. Wenn man die Suche auf normalenm Wege nutzt dauert es Ewigkeiten, bis ein Suchergebnis angezeigt wird.
In der Exception-Log ist kein Eintrag dazu vorhanden.
Wie können wir das Problem lösen?
Kann es sein, das die oxseo oder / und oxseohistory etwas damit zu tun haben?
Schwierig zu sagen, woran das liegt. Wir waren auf einem shared hoster (Strato), bei dem war die Performance katastrophal. Nach dem Umzug auf einen dedizierten vServer ist die Performance jetzt brilliant, nachdem wir die Tabelle oxlogs bereinigt haben.
Ansonsten habe ich nur eine generische Idee: Da ich PHP-Entwickler bin, würde ich die xdebug-Extension aktivieren und mir anschauen, wo die meiste Zeit bei einem Request verbraten wird. Das empfielt sich aber auch nur dann, wenn du dich grundlegend mit Debuggern und dem valgrind-Outputformat und den entsprechenden Tools (kcachegrind) auskennst.
@vschmi hat schon recht: Es ist einfach sehr sehr schwierig zu sagen, ohne genaue Hintergründe zu kennen. Performance hat tausend Ecken wie z.B. Hosting Provider, verwendeter Server, Anzahl Artikel/Kategorien/Varianten und das Verhältnis dazwischen, Anzahl konkurrierender gleicher Benutzer usw.
Performance ist immer Projektgeschäft und kann nicht pauschal ohne jegliche Daten debugged werden.
Auf was für einem Server läuft denn der Shop und wie viele Produkte, Varianten und Kategorien habt ihr drin? Treten die Probleme im Frontend nur auf bestimmten Seiten auf (z.B. Artikeldetailansicht, Kategorieansicht,…) oder generell?
Unser Shop liegt auf einem managed Server beim Profi-Hoster.
Wir werden von dort super unterstützt und haben in der letzten Zeit gemeinsam viele Einstellungen verändert.
Max-User-Connections wurden hochgesetzt etc.
Wir haben nur einige tausend Artikel (meist mit Varianten), ca. 30 Hersteller, etwa 60 Kategorien.
Wenn unsere Besucher die integrierte Suche nicht nutzen, und wenn wir nicht im Backend arbeiten läuft der Shop rund.
Die langen Ladezeiten treten - wenn - dann im gesamten Shop auf jeder Seite auf.
Die Suche z. B. braucht bis zu 20 Sekunden für die Ergebnisanzeige,
liefert dann ein Ergebnis. In der exception-log ist kein Fehler eingetragen.
Können wir - gefahrlos - bestimmte Tabellen leeren?
Wir vermuten dort den Flaschenhals.
Wie geschrieben, haben wir es erst dem idealo-Echtzeit-Modul angelastet.
Der dazugehörige Trigger sendet aktualisierte Artikelinformationen an die Preissuchmaschine.
Nun ist es so, daß z. B. bis zu 20.000 Artikel aktualisiert werden wollen, obwohl wir nichts verändert haben. Das Shop-System wird also beim Seitenaufruf durch unsere Besucher irgendwo in einer Tabelle einen Zeitstempel oder ähnliches eintragen. idealo erkennt dies dann als Änderung und der Trigger legt los, und sendet pro Tick 100 Aktualisierungen.
Wir haben es daher in Zusammenarbeit mit idealo momentan so gelöst, daß wir die Aktualisierung manuell durchführen.
Den Shop-Link gebe ich gern per PN weiter, ich möchte verhindern, dass alle hilfsbereiten Menschen hier auf einmal die Suchte testen
bevor du “bestimmte” Tabellen löschst musst du auf jeden Fall ein Backup / Dump machen. Es gibt Tabellen die man löschen kann, in der Regel sollte man dies aber nicht machen! (Log Tabellen vielleicht, bei dem Rest würde ich immer aufpassen). Benutze auch die Suche nach dem Tabellennamen, um vielleicht weitere Infos über die Tabelle zu erhalten (habe Marco mal einen ordentlichen Schrecken eingejagt, als ich eine Tabelle gelöscht habe )
Bleib auf jeden Fall an dem spannenden Thema dran! 20.000 ? Artikel inkl. Varianten sind zwar nicht gerade wenige, aber der Shop sollte die bewältigen können. Wenn du sehr viele Besucher hättest wäre dies ja auch PH aufgefallen.
Performance-Einstellungen mal geprüft, da gab es auch mal BottleNecks.
[QUOTE=frabo;127203]
Die Suche z. B. braucht bis zu 20 Sekunden für die Ergebnisanzeige,
liefert dann ein Ergebnis. In der exception-log ist kein Fehler eingetragen.
Können wir - gefahrlos - bestimmte Tabellen leeren?
Wir vermuten dort den Flaschenhals.
[/QUOTE]
Tabellen leeren bringt imho nichts. Die Suche macht ja nicht so wahnsinnig viel, das kann man eigentlich gut debuggen. Debug auf 1 in der config.inc liefert profiling infos, profiling-Blocks kann man auch selbst setzen, wenn man ein SQL identifiziert hat kann man das per echo ausgeben und testen.
Hallo,
vielen Dank für die Tips.
Wir können diese erst heute abend abarbeiten, wenn nicht viele Besucher im Shop sind. Ergebnisse werden wir hier kundtun.
@Firefax
Performanceeinstellungen haben wir durch, und alles was nicht nötig ist
abgeschaltet.
Viele zeitgleiche Besucher stören den Shopbetrieb nicht, das ist okay.
@Marco
Die Dateien hatten wir gecheckt, heute abend kann mein Herzblatt das zur Sicherheit nochmal machen.
@Frank
Debuggen können wir heute abend, wenn nicht mehr so viele Besucher ihre Einkaufskörbe in eine Bestellung umwandeln.
Das mit den profiling-blocks können wir wahrscheinlich nicht umsetzen, da sind wir überfordert… Mal sehen…
Wir haben unsere Daten übrigens damals vom 4.4 er Shop importiert.
Unsere Denkweise war, daß in ein paar Tabellen noch alte Daten stehen, die dann entfernt werden könnten.
Der Performanceverlust ist aber unseres Wissens nach erst seit dem Update auf 4.7.5 aufgetreten. Die Hoffnung, bei Version 4.7.6 ist alles wieder gut erfüllte sich leider nicht.
Vielleicht noch ein paar Infos zu unseren Modulen:
Wir haben die Module deaktiviert, die Fehlermeldungen verursachen bzw. weil sie nicht ordnungsgemäß funktionieren ( Kategoriemanager, Bulk-Edit)
Zahlungsdienstleister und Backend-Order funktionieren.
Das Backend-Order-Modul braucht auch lange Zeit, um Artikel zu finden.
Auch dieses sucht sich “wund”, zeigt aber nach einer langen Zeit des Wartens dann die Artikel in der Auswahlliste an.
@Marco
So, oxchkversion ist gecheckt - es sind 4 Dateien “modified” die da wären:
article_variant.tpl - Ein Feld für die EANs wurde hinzugefügt
bottomnavicustom.tpl - Eintrag für ein Modul vorhanden
cust_lang.php - Diverse Lang-Änderungen
myorder.php - Einträge z.B. von Billpay
@leofonic
Beim Debug auf 1 kam der Eintrag im Anhang für die Suche. Die Suche hat ca. 48 sec. gedauert
Wenn man z.B. mit dem Firefox surft und die Suche nutzt, kann man gleichzeitig mit einem anderen Browser im Shop surfen ohne das es dort wirklich langsam ist. Die Suche im im ersten Browser legt derweil den Shop lahm.
Jetzt könntest du das SQL in oxarticlelist.php mal ausgeben:
public function selectString( $sSelect )
{
startProfile("loadinglists");
$oRes = parent::selectString( $sSelect );
/*eingefuegt:*/
echo $sSelect;
stopProfile("loadinglists");
return $oRes;
}
(vorsicht, zerlegt die Seite, nur nachts machen)
Und das mal in PHPmyadmin testen mit verschiedenen Suchbegriffen (Begriff suchen und Ersetzen im Statement).
Was steht denn im PhpMyadmin bei den Variablen unter “innodb buffer pool size”?
folgender Text wurde ausgegeben … im PHPmyadmin ausgeführt dauerte die Abfrage immer ca. 24 sec.
select oxv_oxarticles_de.oxid, oxv_oxarticles_de.oxparentid, oxv_oxarticles_de.oxvarstock, oxv_oxarticles_de.oxstock, oxv_oxarticles_de.oxstockflag, oxv_oxarticles_de.oxshopid, oxv_oxarticles_de.oxvarcount, oxv_oxarticles_de.oxvarname, oxv_oxarticles_de.oxtitle, oxv_oxarticles_de.oxvarselect, oxv_oxarticles_de.oxthumb, oxv_oxarticles_de.oxpic1, oxv_oxarticles_de.oxtprice, oxv_oxarticles_de.oxvat, oxv_oxarticles_de.oxvarminprice, oxv_oxarticles_de.oxskipdiscounts, oxv_oxarticles_de.oxprice, oxv_oxarticles_de.oxvarmaxprice, oxv_oxarticles_de.oxunitquantity, oxv_oxarticles_de.oxweight from oxv_oxarticles_de LEFT JOIN oxv_oxartextends_de ON oxv_oxarticles_de.oxid=oxv_oxartextends_de.oxid where ( oxv_oxarticles_de.oxactive = 1 and ( oxv_oxarticles_de.oxstockflag != 2 or ( oxv_oxarticles_de.oxstock + oxv_oxarticles_de.oxvarstock ) > 0 ) and IF( oxv_oxarticles_de.oxvarcount = 0, 1, ( select 1 from oxv_oxarticles_de as art where art.oxparentid=oxv_oxarticles_de.oxid and ( art.oxactive = 1 ) and ( art.oxstockflag != 2 or art.oxstock > 0 ) limit 1 ) ) ) and oxv_oxarticles_de.oxparentid = ‘’ and oxv_oxarticles_de.oxissearch = 1 and ( ( oxv_oxarticles_de.oxtitle like ‘%lotus%’ or oxv_oxarticles_de.oxsearchkeys like ‘%lotus%’ or oxv_oxartextends_de.oxlongdesc like ‘%lotus %’ ) )
Warning: Cannot modify header information - headers already sent by (output started at /shop/application/models/oxarticlelist.php:88) in /shop/core/oxutils.php on line 1144 Warning: Cannot modify header information - headers already sent by (output started at /shop/application/models/oxarticlelist.php:88) in /shop/core/oxutils.php on line 1144 Warning: Cannot modify header information - headers already sent by (output started at /shop/application/models/oxarticlelist.php:88) in /shop/core/oxutils.php on line 1144 Warning: Cannot modify header information - headers already sent by (output started at /shop/application/models/oxarticlelist.php:88) in /shop/core/oxutils.php on line 1144 Warning: Cannot modify header information - headers already sent by (output started at /shop/application/models/oxarticlelist.php:88) in /shop/core/oxutils.php on line 1144
Zusätzlich hatten wir heute einen Eintrag in der exception-log Datei
Führe mal bitte folgendes SQL-Statement in deinem phpmyadmin aus:
explain select `oxv_oxarticles_de`.`oxid`, `oxv_oxarticles_de`.`oxparentid`, `oxv_oxarticles_de`.`oxvarstock`, `oxv_oxarticles_de`.`oxstock`, `oxv_oxarticles_de`.`oxstockflag`, `oxv_oxarticles_de`.`oxshopid`, `oxv_oxarticles_de`.`oxvarcount`, `oxv_oxarticles_de`.`oxvarname`, `oxv_oxarticles_de`.`oxtitle`, `oxv_oxarticles_de`.`oxvarselect`, `oxv_oxarticles_de`.`oxthumb`, `oxv_oxarticles_de`.`oxpic1`, `oxv_oxarticles_de`.`oxtprice`, `oxv_oxarticles_de`.`oxvat`, `oxv_oxarticles_de`.`oxvarminprice`, `oxv_oxarticles_de`.`oxskipdiscounts`, `oxv_oxarticles_de`.`oxprice`, `oxv_oxarticles_de`.`oxvarmaxprice`, `oxv_oxarticles_de`.`oxunitquantity`, `oxv_oxarticles_de`.`oxweight` from oxv_oxarticles_de LEFT JOIN oxv_oxartextends_de ON oxv_oxarticles_de.oxid=oxv_oxartextends_de.oxid where ( oxv_oxarticles_de.oxactive = 1 and ( oxv_oxarticles_de.oxstockflag != 2 or ( oxv_oxarticles_de.oxstock + oxv_oxarticles_de.oxvarstock ) > 0 ) and IF( oxv_oxarticles_de.oxvarcount = 0, 1, ( select 1 from oxv_oxarticles_de as art where art.oxparentid=oxv_oxarticles_de.oxid and ( art.oxactive = 1 ) and ( art.oxstockflag != 2 or art.oxstock > 0 ) limit 1 ) ) ) and oxv_oxarticles_de.oxparentid = '' and oxv_oxarticles_de.oxissearch = 1 and ( ( oxv_oxarticles_de.oxtitle like '%lotus%' or oxv_oxarticles_de.oxsearchkeys like '%lotus%' or oxv_oxartextends_de.oxlongdesc like '%lotus %' ) )
Die Ausgabe bitte hier posten. Möglicherweise fehlen dir Indizes auf der Datenbank, weshalb es so langsam ist. Bei mir wird das Query in 0.003 Sekunden ausgeführt.
Zu deiner Meldung im Exception Log: Da weder “GOOGLEAGE” noch “oxefiexportedshops” im OXID-Code vorhanden sind, würde ich vermuten, daß das von irgendeinem Modul kommt. Hast du irgendein Modul, welches dafür verantwortlich sein könnte?
Wie ich es vermutet hatte: Dir fehlen Indizes (Possible Keys: NULL).
Ich weiß nicht, wie es dazu kommt, und ich kann dir ohne Aufwand nicht die ganzen Key-Create Statements posten, aber das ist definitiv der Grund. Bei mir sieht das so aus:
