Jump to content

Extrem langsames Backoffice 1.6.0.11


schibulski

Recommended Posts

Speziell das Bearbeiten eines Artikels ist eine Qual in 1.6.0.11. Die Speichernbuttons rotieren eine gefühlte Ewigkeit im Kreis. Habe den Effekt sowohl bei einem von 1.5 "geupdateten" Shop, als auch bei einer ganz frischen 1.6.0.11 Neuinstallation.

Im englischen Forum ist dieser Umstand auch in vielen Threads nachzulesen.

Das Problem scheint hier zu sein dass die Buttons erst dann klickbar werden wenn alle Tabs vollständig geladen sind.

Bei dem Updateshop kann das teilweise Minuten dauern, da der Kategoriebaum sehr groß ist (4500 Kategorien) und es circa ebensoviele Artikeleigenschaften gibt. Der Kategorientab braucht im Gegensatz zur 1.5 Version des Shops auch unglaublich viel mehr "php_memory limit"

Dass die Buttons aber auch einem frisch installierten System so lange "rotieren" ist ja eher nicht normal. Hab das ganze mit verschiedenen Hostinganbietern getestet, überall das Selbe

 

Kurzum: Das Bearbeiten von Artikeln ist in einer Produktivumgebung nicht möglich.

 

Mich wundert dass hier im deutschen Forum noch nichts dazu aufgetaucht ist. Jemand ähnliche Erfahrungen gemacht?

 

Ein Hoch auf AJAX!

Link to comment
Share on other sites

ja, das ist bei normalen Serverumgebungen leider so.

 

Minuten sollte das allerdings nicht dauern, da stimmen die Servervorraussetzungen nicht, oder Du hast falsche Einstellungen,

das kann leider so vieles sein.

 

Wenn Du das ebay-modul installiert hast, schmeiss das gleich wieder raus.

 

Wenn Du viele Artikel importiert hast, und diese noch nachbearbeiten must, mach das Schrittweise, also nicht gleich 1000 Artikel importieren und dann in Prestashop nacharbeiten, sonder 100 importieren und die dann bearbeiten, dann die nächsten und so weiter

 

noch besser wäre, wenn Du die Artikel gar nicht in Prestashop, sondern in einer ordentlichen Warenwirtschaft bearbeitest und dann nur noch ganz wenig in PResta abbarbeiten must.

 

Vielleicht bekommen wir ja in einer finalen Version das ganze flüssiger.

 

gruß

 

PS: wer ist AJAX ?

Edited by kulli (see edit history)
Link to comment
Share on other sites

Am Server liegt es definitiv nicht. Der gleiche Shop hat mit 1.5.6.2 im Backoffice Ladezeiten von Durchschnittlich 0.3s.

 

Alles was Geschwindigkeit bringt ist aktiviert (nginx führt den php code aus, APC cached das Frontend, CGI und FastCGI sind aktiviert, alle CCC Funktionen sind unterstützt und aktiviert und so weiter und sofort. Das Frontend ist auch weiterhin rasend schnell (Hab dort auch Ladezeiten deutlich unter 0,5 Sekunden. Die Probleme wurden auch von Leuten berichtet die dedizierte Server haben.

 

Ich habe auch schon mit allen oben genannten Funktionen gespielt und jede Kombination ausprobiert. Nix zu machen.

 

Fast jede Seite im BO hat Ladezeiten von durchschnittlich 12 Sekunden! In der Produktbearbeitung ist es besonders schlimm. Hab eben mal die Zeit gestoppt: 12 Sekunden Ladezeit, und nochmal 36 Sekunden drauf bis die Speicherbuttons aufhören zu rotieren und "klickbar" werden.

 

Bei einer frischen Installation mit null Produkten, Kategorien und Zusatzmodulen sinken die Ladezeiten auf durchschnittlich die Hälfte der oben angegeben Werten.

 

Das Backoffice des 1.5.6.2 dagen fühlt sich fast wie eine Desktopanwendung an.

 

1.6 war zwar schon immer etwas langsamer als die 1.5, was aber aufgrund der Neugestaltung auch okay war, diese massiven Probleme treten erst ab 1.6.0.11 auf. Und das wie gesagt massenhaft. Man durchsuche nur mal die englischen Foren hier oder googelt nach "Prestashop 1.6.0.11 very slow backoffice"

 

Wie gesagt: Es ist zwar ein shared Hosting, aber in nem ziemlich fetten Paket bei SSD-Webhosting. Daran liegt es mit Sicherheit nicht, schon garnicht wenn man das mit dem exakt gleichen Shop auf 1.5.6.2 vergleicht.

  • Like 1
Link to comment
Share on other sites

Update:

 

Der Fehler ist gefunden und behoben. Nachdem ich mal den Network Monitor und den Debug Modus von Presta eingeschaltet habe stellte sich heraus dass das Problem im Hook "displayBackOfficeHeader" zu finden war. Bei den Modulpositionen mal nachgeschaut was sich da eingenistet hat: Das Modul "CronTasks Manager" von Prestashop und der ThemeConfigurator waren darin zu finden. Als erstes Mal den Cron Manager vom Hook entfernt: Problem gelöst! Einzig und alleine die Modulseite hat noch genausolange geladen. Hab den Cron Manager dann komplett deinstalliert und seitdem läuft auch die Modulseite im BO wieder flüssig. Halleluja!

Das BO hat jetzt durchweg Ladezeiten von 0.100 bis 0.300 Sekunden. :) :) :)

 

Da stellen sich mir 2 Fragen:

 

1. Wieso zur Hölle war das Modul überhaupt installiert, kann mich nicht erinnern dass installiert zu haben ?!

 

und

 

2. Warum wird es bei der Installation in den o.g. Hook geschrieben?

 

P.S.: Den Theme Configurator habe ich auch aus dem Hook entfernt. Oder gehört der da wirklich rein?

Edited by schibulski (see edit history)
  • Like 1
Link to comment
Share on other sites

Hast du denn jobs im Cron Manager hinterlegt? Ich hatte dort nämlich keinen einzigen Job drin, und als ich mal in die Einstellungen des Moduls gegangen bin stand dort in rot "Keine Verbindung zum Prestashop Cron Dienst möglich" (oder so ähnlich) Eventuell hat das bei mir zu diesen ewigen Ladezeiten geführt.  :blink:

 

Hab meine Lösung jedenfalls auch im englischen Forum publiziert.

Link to comment
Share on other sites

Ich könnte mir aufgrund meiner Fehlermeldung auch vorstellen dass die Cron Dienste nur für die Cloudversion von Prestashop gemacht sind. Bei der selbst gehosteten Variante definiert man seine Cron Jobs doch eher über den Server selbst. Das würde auch erklären warum das Modul plötzlich in 1.6.0.11 von Haus aus aktiv ist...

 

Nachtrag: Ich habe das Modul gerade auch mal bei einem frisch installierten Shop bei einem völlig anderen Hoster (sehr langsam) deaktiviert. Mit dem Modul: ca. 5-6 Sek. Ladezeit auf jeder Seite im BO, mit deinstalliertem Modul: signifikante Verbesserung auf Ladezeiten knapp unter 1 Sekunde!

 

Das Modul "Cron Tasks Manager" sorgt definitv für extreme Leistungseinbrüche im BO

Edited by schibulski (see edit history)
Link to comment
Share on other sites

Daumen hoch!

Ich kann den Performance-Schub sowohl für den normalen Online-Shop unter 1.6.0.11 wie auch für die Cloud-Version nur bestätigen!

 

 

Ich könnte mir aufgrund meiner Fehlermeldung auch vorstellen dass die Cron Dienste nur für die Cloudversion von Prestashop gemacht sind. Bei der selbst gehosteten Variante definiert man seine Cron Jobs doch eher über den Server selbst. Das würde auch erklären warum das Modul plötzlich in 1.6.0.11 von Haus aus aktiv ist...

 

 

Das sehe ich genau so. Es gibt ja auch keinen direkten Zugriff auf ein wie auch immer geartetes Backend des Hosters, wo sich Cronjobs manuell einrichten ließen. Selbst ein Datenbank-Restore ist künftig ein kostenpflichtiger Dienst. Und es versteht sich wohl von selbst, dass bekannte Funktionen wie etwa die Installation von Modulen oder Templates bei der Cloud-Version ausschließlich auf Kaufprodukte auf PrestaShop Addons verlinkt -  alles "aus Sicherheitsgründen" (Honi soit qui mal y pense).  ;)

Per Direktimport via FTP soll es zwar aktuell noch gehen - fragt sich aber, wie lange noch. Ausprobieren konnte ich das allerdings noch nicht, denn trotz mehrerer Versuche erwies sich bisher das Einrichten eines einfachen FTP-Zugangs zur Cloud als unüberwindliche Hürde.

 

Je nachdem, wie stark PrestaShop auf die Cloud hin ausgerichtet wird, kann es so durchaus passieren, dass die Community-Version außerhalb der Cloud in nicht allzuferner Zukunft zum Auslaufmodell wird.

Link to comment
Share on other sites

zum Auslaufmodell wird.

 

Jetzt mal den Teufel mal nicht an die Wand...

 

würde mich aber auch nicht wundern - wir haben das mit Mondo-Shop schonmal mitgemacht. Zuerst alles in der Community zur Perfektion gebracht und dann kriegste einen Tritt in den A.....

 

Und zum Thema Cloud kann ich nur immer wieder einen alten (da gab es sowas noch gar nicht) Rat geben: Gib niemals Deine Daten außer Haus. Durch die verschiedenen Verkaufskanäle sind wir Händler eh schon ziemlich durchsichtig.....

Link to comment
Share on other sites

Auch wenn ich das Problem persönlich durch oben genannte Lösung abstellen konnte, poste ich hier nochmal einen äußerst interesanten Artikel der sich im Speziellen mit endlos lang rotierenden Save Buttons in presta 1.6.0.11 beschäftigt:

 

http://nemops.com/spinning-save-button-prestashop-1-6/#.VNiRWXbomcY

 

Hier wird nochmals deutlich beschrieben dass die Buttons erst dann klickbar werden wenn alle Tabs der Artikelseite geladen sind und wie man mögliche Fehlerquellen identifiziert und beseitigt. Ich hoffe der ein oder andere kann das gebrauchen, mir hat es jedenfalls sehr geholfen.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

Hallo schibulski,

 

ich habe hier mal mitgelesen und zumindest hat das mit dem Cron auch bei mir etwas gebracht.

Auch den Artikel aus deiner letzten Post habe ich gelesen.

 

Ich bin leider nicht so tief in den PS Strukturen drin wie ihr das wohl seid.

Jetzt würde mich in diesem Zusammenhang interessieren was genau du gemacht hast damit dir das geholfen hat.

Was hat sich dadurch deutlich verbessert? Der rotierende Speicher Button kommt jetzt sofort schwarz?

 

Hast du das File aus dem Github geladen und gegen irgendetwas ersetzt? Wenn ja, wie genau hast du das gemacht?

 

Würde mich echt selbst interessieren weil das ist so ziemlich das nervigste Thema.

 

Danke

Gregory beschreibt hier leider nicht was genau zu tun wäre.

Link to comment
Share on other sites

  • 2 weeks later...

ich habe dasselbe Problem, kann keine bestehenden Produkte bearbeiten und keine neuen Produkte erfassen.

Der Speichern button dreht und dreht... habe das nach 20 Minuten abgebrochen.

 

Die beiden Module ThemeConfigurator und CronTasks Manager kann ich im displayBackOfficeHeader ebenfalls nicht finden.

 

Irgend jemand eine Idee?

Link to comment
Share on other sites

  • 3 weeks later...
  • 4 weeks later...

Danke für die Tips, auch bei 1.6.0.9. trat dieses Problem auf nach dem ein Crontask Modulupdate eingespielt wurde.

Gleichzeitig waren noch andere Module in dem Hook "displayBackOfficeHeader" eingehangen, wo sich mir der Sinn nicht erschliessen ließ.

Nachdem wir im Hook aufgeräumt hatten und Crontask komplett rausgeschmissen, läuft die Seite wieder optimal. Ladezeiten um die 0.2 bis 1 Sekunden bei "normalen" Seitenaufrufen.

 

Vielen Dank nochmal, saved my day!

Link to comment
Share on other sites

  • 1 month later...

Ich habe euer Troubleshooting sehr interssiert verfolgt. Ich muss dazu sagen, dass ich kein gelernter Webmaster bin. Aber dennoch konnte ich damit versuchen das zu bereinigen.

 

Aber: Ich hab die Hooks und den Crontask entfernt.  Auch Ebay und Paypal  deaktivirt. Ohne jedes Resultat. Mir ist aufgefallen, jeh mehr Produkte ich einstelle um so länger dauert es bis die Rotationen der Save Buttons wieder aufhören. Derzeit zum Teil eine Minute. Bei gerade mal rd. 100 Artikel. Das Arbeiten wird zur Qual und es dauert ewig bis man weiter machen kann. Ich habe jetzt schon alle möglichen Foren durch und weiß mir nicht mehr weiter zu helfen. Ich benutze Presta 1.06.14  Wenn jemand dazu neue Erkenntnisse hätte wäre ich sehr dankbar.

Link to comment
Share on other sites

Vielen Dank für die Hilfe.

 

Der Shop läuft auf einem Deticated Server der neuesten Generation mit Centos 7 als Betriebssystem, das sollte keinerlei Problem darstellen.

Die Module die nicht benötigt werden habe ich deinstalliert.

Zum Prestashop Marktplatz war ich von vorne herein nicht angemeldet.

Der Cache wurde anschließend geleert

 

Aber es hat sich keinerlei Änderung gezeigt. Ich bin für weitere Vorschläge mehr als offen, denn so langsam verzweifle ich daran.

Link to comment
Share on other sites

Ich denke die sind großzügig eingestellt:

 

memory_limit 512M

max_execution_time 1000

max_input_time:   -1

post_max_size   48M

allow_url_fopen:  Standard

files_upload:   Standard

max_input_vars: 10000

short_open_tag: =on

 

Ich denke, dass das normale Einstellungen sind die für 1.06.0.14 fuktionieren sollten.

Link to comment
Share on other sites

Vielen Dank, ich habe das geändert. Allerdings ohne jedweden Erfolg. Die Speicher Buitton drehen nach wie vor ewig.

Ich bin für neue Ideen offen. Was ich nicht verstehe ist,  dass Prestashop da nicht was unternimmt und ein update macht. Die Foren sind doch voll

von diesem Problem.

Link to comment
Share on other sites

setze mal die max_execution_time runter auf 300

und wenn möglich das memory_limit auf 1024

 

bringt wahrscheinlich nix - ist nur so eine tüftelei

 

weitere Testereien: (immer eins nach dem anderen um das ganze besser einzugrenzen)

- nicht benötigte Statistikmodule deaktivieren und deinstallieren

- die Verbindung zum Prestashopmarktplatz trennen,

- in den Voreinstellungen die maßnahmen(Artikeleigenschaften) deaktivieren, falls sie nicht gebraucht werden,

- Voreinstellung - Leistung den server-cache (ganz unten) abschalten,

- Bei der Verschlüsselung eventuell blowfish verwenden, (prüfen ob mcrypt in den php-eistellungen aktiviert ist)

- in Debug-Modus Artikel bearbeiten; eventuell mal Apache-Optimierung abschalten

 

nochmal alle sachen im englischen Forum durchgehen.

 

habe fertig

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...