Ich schätze, dass die Sache im Off-Canvas-Warenkorb an dem Express-Checkout-Button liegt. Den gibts ja bei Amazon auch.
Also das Amazon Pay Plugin hatte zumindest im Frontend kein “Nach-Hause-Telefonieren-Syndrom”, das mir umgehend aufgefallen wäre. Ich werde aber noch mal darauf achten, wenn es mal wieder benutzbar ist.
Insgesamt ist das Thema Datensammelwut nervig und ärgerlich, gehört aber nur so halb hier rein. Erst mal müsste das Amazon Pay Plugin so weit funktionieren, dass es nicht den Shop lahmlegt. 
Doch ich stelle insbesondere im Ajax-Warenkorb eine Verlangsamung fest. Teilweise meldet Firefox dann sogar „Eine Webseite verlangsamt Ihren Browser“. Das passiert z.B. dann wenn man einen Artikel der bereits im Warenkorb liegt nochmal in den Warenkorb legt.
Das ist doch wohl vermutlich der gleiche Krampf, wie aktuell auch (noch) im PayPal.
Was hat eine Zahlungsart - die womöglich ja noch gar nicht vom Kunden ausgewählt wurde - im Warenkorb, erstrecht im Ajax-Warenkorb, aktiv zu sein, und ggf. (ungefragt) den Warenkorb bei AMAZON zu tracken? Klingt mir nach:
Man kann das ja bei beiden Plugins problemlos deaktivieren. Ich glaube aber, dass das schon gerne angenommen wird.
Klar kann man es deaktivieren. Allerdings ist doch der ganze Witz dabei, dass der Kunde durch die Express-Buttons möglichst schnell auschecken kann. Nimmt man die Express-Buttons weg, geht der Vorteil flöten bzw. der Kunde übersieht diese Möglichkeit und kauft im Zweifel nicht.
Die Datensammelei sehe ich getrennt davon und ich erachte sie als unnötig in Bezug auf die eigentliche Funktion. Ein einfacher Button würde es in jedem Fall auch tun. Selbst den “In-Context-Modus” lasse ich nicht gelten. (Mal davon abgesehen, dass wir diesen bei PayPal gar nicht nutzen und es bei Amazon Pay diesen so gar nicht gibt.)
Aber noch mal zurück zum Thema: Wichtig ist doch ob und inwiefern diese Datensammelei die Performance beeinflusst.
- iframe statt einfacher Button: beeinflusst die Frontend-Performance
- unnötiges Laden von JS-Code: beeinflusst ebenfalls die Frontend-Performance
- Was auch immer der Auslöser dafür ist, dass der (AJAX-)Warenkorb langsam lädt (und offensichtlich auf Server-Seite die Performance runterzieht)
- Was auch immer die Cronjobs bei Amazon Pay so lahm macht (und die Server-Load in die Höhe treibt)
Dazu noch mal eine Frage in die Runde: Wie ist denn bei Euch die max execution timeout gesetzt? Das könnte bei uns eventuell einen Teil erklären. Ich spiele aber ungern an solch zentralen Werten herum.
1 „Gefällt mir“
300
Es kommt vor, dass man meint die wäre hoch gesetzt, wird aber vom master überschrieben;
https://forum.shopware.com/discussion/comment/233850/#Comment_233850
Und bei Euch geht Server Load auch durch die Decke? Oder hält sich das in Grenzen?
Ich muss gestehen, dass ich es auf -1 stehen habe. Das ist noch so ein Überbleibsel aus der Migrationsphase. 300 scheint mir ein mehr als ausreichender Wert für die allermeisten Dinge. Die Randfälle kann ich mir ja noch mal ansehen. Besten Dank für die Info!
90 sollten auch reichen
Es kommt ja nicht alleine auf die max_execution an; es kommt drauf an dass der Server insgesamt ordentlich eingerichtet ist
Wir schreiben ja auch schon die ganze Zeit über die Beta, bei der das so nicht mehr vorkommt (bis jetzt).
Der Server ist eigentlich korrekt eingerichtet – soweit ich das beurteilen kann. Zumindest bin ich mit dem Hoster zufrieden. Bei manchen Werten könnte man wahrscheinlich noch Feinheiten justieren (memory_limit z.B.), aber das hat alles nicht die Probleme erklärt, die wir hatten. Das Amazon Pay Plugin ist eindeutig der Auslöser.
Ich bin mal auf das nächste Release gespannt.
Das neue offizielle ist jetzt online - viel Glück
Das ging jetzt doch schneller als gedacht.
Dann teste ist mal “live”.
Puh … also die Bestellungen im Backend brauchen schon wieder deutlich länger, bis sie offen sind. Das macht schon mal keinen Spaß. Serverload muss ich im Auge behalten, sobald der Cache aufgewärmt ist. (Wobei das Aufwärmen schon mal zügig vorangeht.)
Was macht denn dieses verdammischte Plugin, dass es das Öffnen von Aufträgen so massiv verlangsamt!?
Wegen Datensammelei. Positiv: Kein iframe um den Button herum. Negativ: Es werden „aus Prinzip“ mehrere JS-Dateien geladen und mindestens 3 XHR-Requests abgefackelt.
Nachtrag:
Bei Produkten, die eigentlich nicht kaufbar sein sollten, taucht der Amazon Pay Button trotzdem auf. Ich habe diesen daher bei uns erst mal für die Produktseiten deaktiviert.
Die Probleme habe ich bereits an den Best IT Support gemeldet. Ich wollte das nur für die anderen Händler hier festhalten.
Eben wurde ich von Amazon Pay angeschrieben, weil denen aufgefallen ist, dass wir die Zahlart im Shop nicht mehr aktiv haben :D
Ich teste das Ding auch eben in der produktiven Umgebung. Ich habe auch die Befürchtung, dass der Shop schon wieder langsamer reagiert. Aber lange nicht so gravierend, wie es neulich gewesen ist.
ich lasse diesmal die Finger davon, probiere es auch erst wieder wenn es ne längere Zeit stabil läuft.
Ich werde berichten.
Bisher sieht es (bis auf die genannten Problemchen) gut aus. Shop-Frontend läuft – nach meinem Dafürhalten – schnell.
Na da sind wir ja mal gespannt
Moin zusammen,
bis jetzt läuft es tadellos und das Frontend, wie auch das Backend haben eine gute Performance. Auch Fehlermeldungen, wie zum Beispiel “nicht erlaubter Templatepfad” bleiben dieses Mal gottseidank aus. Ihr könnt Euch meiner Meinung nach ruhig trauen, das Ding in einer Liveumgebung einzusetzen.
Bin am Testen, Frontend ist schnell, Backend ebenfalls, Jetzt heisst es warten, ob die Kunden tatsächlich damit zahlen können. Bei den letzten Malen gab es nur Errormeldungen beim Kunden. Ja die waren dann weg. Und das Plugin dann auch.
Also: Amazon Pay die 10.
Zahlungen kommen bei uns rein (und werden bei Amazon nach Versand abgeholt). Fehlermeldungen im Log sind in der Form “User not logged in”. Ich schätze mal, dass das also eher unkritisch ist.
Performance im Frontend: alles OK.
Performance im Backend: nach wie vor öffnen sich bei uns die Bestellungen sehr zäh. Ansonsten keine Auffälligkeiten.
Server-Load: alles im grünen Bereich
Wir hatten heute Nacht server load Fehlermeldungen und das um 2:54 Uhr also einer Uhrzeit mit eher weniger Besuchern. Kann aber nicht zu 100% sagen, was das ausgelöst hat.