Amazon Payments BestIT und Shopware 5.2.x

Shopware 5 Plugins
1

Hallo,

wir haben leider das Problem, dass wir nach einem Update auf SW 5.2.x (Testumgebung) die Zahlart Amazon Payments nicht mehr nutzen können.
Grund hierfür ist, dass die Datenbankabfragen aus dem Plugin von BestIT nicht optimiert sind.
Man teilte uns mit, wir sollen vom Hoster den MAX_JOIN_SIZE Wert erhöhen lassen. Dieses wurde allerdings abgelehnt, da der Hoster keine unoptimierten Datenbankabfragen haben möchte.

Die Frage ist nun ins Forum, hat noch jemand das Problem oder ähnliche Probleme mit Amazon Payments?
BestIT ist der Meinung, dass dieser Fehler kein Grund zu einer Reaktion sei, ob wir das Plugin und die Zahlart dann nicht mehr nutzen können, ist denen egal.

Da Amazon Pay bei uns die zweitstärkste Zahlart ist, wäre ein Update ausgeschlossen.

Freue mich auf Rückmeldung!

2

@eierund schrieb:

Hallo,

wir haben leider das Problem, dass wir nach einem Update auf SW 5.2.x (Testumgebung) die Zahlart Amazon Payments nicht mehr nutzen können.
Grund hierfür ist, dass die Datenbankabfragen aus dem Plugin von BestIT nicht optimiert sind.
Man teilte uns mit, wir sollen vom Hoster den MAX_JOIN_SIZE Wert erhöhen lassen. Dieses wurde allerdings abgelehnt, da der Hoster keine unoptimierten Datenbankabfragen haben möchte.

Die Frage ist nun ins Forum, hat noch jemand das Problem oder ähnliche Probleme mit Amazon Payments?
BestIT ist der Meinung, dass dieser Fehler kein Grund zu einer Reaktion sei, ob wir das Plugin und die Zahlart dann nicht mehr nutzen können, ist denen egal.

Da Amazon Pay bei uns die zweitstärkste Zahlart ist, wäre ein Update ausgeschlossen.

Freue mich auf Rückmeldung!

Ich denke auch, dass die Lösung ein größeres Hostingpaket oder ein anderer Hoster wären. 

3

Wir besitzen schon einen Dedicated Webserver.

Finde es merkwürdig, dass kaum jeamdn das Problem hat. Alle noch auf der alten SW Version oder nutzt keiner Amazon Pay?

 

4

Hallo,

aber wenn es sich um einen eigenen Server handelt, dann ist das doch nicht das Problem des Hosters, sondern dein eigenes Problem, wenn aufgrund einer Überlastung der Server abschmiert. Ich bin bei Mittwald und habe dort einen dedizierten Server und die aktuellste SW mit Amazon Payments am Laufen. Vom Hoster habe ich keine Beschwerden bezüglich nicht optimierter Queries erhalten. Warum auch, es ist ja eigentlich mein Server…

LG,

Chris

5

Warum mein Problem?

Es wird ein Fehler ausgeworfen wegen der zu großen SQL Querie. Dis lässt sich aber nur verhindern, wenn die großen Queries vom Webserver erlaubt werden, was man aber auch bei einem Dedicated Server nicht selbst einstellen kann. Der Dedicated Server ist ja managed by Host Europe.

Beste Grüße,

Sven.

 

6

Ich meinte das in der Hinsicht, dass es dem Hoster egal sein dürfte. Wie dem auch sei, ich kann Dir nur sagen, dass es damit aktuell auf den meisten Servern wohl keine Probleme verursacht. Jedenfalls bist Du doch sicherlich nicht der Einzige, der seinen dedizierten Server auf Host Europe betreibt…

7

Scheinbar bin ich the one and only Undecided

8

Ich hab den kleinsten aktuellen ManagedServer von Domainfactory (gehört ja auch zu HEG), das läuft ohne Probleme. Auf der Maschine läuft noch ein Magento-Multishop mit 500 Zugriffen am Tag, eine gut frequentierte WordPress-Installation, diverse Webservices mit Datenbankzugriff und noch ein Dutzend andere kleine Websites.

9

Hallo „eierund“,

wie auch im Support bereits angedeutet - „ganz egal“ ist uns Ihre Angelegenheit nicht.
Wir setzen eben nur nicht die höchste Priorität daran, da dies bislang ein Einzelfall ist.

Ein Hosting, auch wenn es ein „Dedicated Server“ ist, haben Sie bestimmte Ressourcen zum System, die in diesem Fall eine Serverseitige Grenze erreicht haben.
Sie sind in der Tat nicht unsere einzigster Kunde, den wir auf einem „Hosteurope“ Hosting unterstützen.

Wie dem aber auch sei - haben wir Ihnen zugesagt, dass wir im Entwicklungsticket „APA-249“ diese Sache untersuchen werden.
Wenn es ein optimierbares SQL gibt, werden wir es umsetzen. So lange wir kein stärkeres Feedback aus dem Nutzerkreis erhalten und es „nur“ aufgrund von Ressourcen eines Hostings zurück läuft, steht es eben nicht an oberster Priorität.

Liebe Grüße aus dem Müsterland

best it Support

10

Das Limit von HostEurope liegt bei 201 Millionen Zeilen. Diese SQL Abfrage vom Amazon Plugin scheint diese Grenze zu überschreiten.

SELECT s0_.id AS id_0, s0_.paymentID AS paymentID_1, s0_.customergroup AS customergroup_2, s0_.subshopID AS subshopID_3, s0_.pricegroupID AS pricegroupID_4, s0_.encoder AS encoder_5, s0_.password AS password_6, s0_.active AS active_7, s0_.email AS email_8, s0_.firstlogin AS firstlogin_9, s0_.lastlogin AS lastlogin_10, s0_.accountmode AS accountmode_11, s0_.confirmationkey AS confirmationkey_12, s0_.sessionID AS sessionID_13, s0_.newsletter AS newsletter_14, s0_.validation AS validation_15, s0_.affiliate AS affiliate_16, s0_.paymentpreset AS paymentpreset_17, s0_.language AS language_18, s0_.referer AS referer_19, s0_.internalcomment AS internalcomment_20, s0_.failedlogins AS failedlogins_21, s0_.lockedUntil AS lockedUntil_22, s0_.salutation AS salutation_23, s0_.title AS title_24, s0_.firstname AS firstname_25, s0_.customernumber AS customernumber_26, s0_.lastname AS lastname_27, s0_.birthday AS birthday_28, s0_.language AS language_29, s0_.customergroup AS customergroup_30, s0_.subshopID AS subshopID_31, s0_.pricegroupID AS pricegroupID_32, s0_.default_billing_address_id AS default_billing_address_id_33, s0_.default_shipping_address_id AS default_shipping_address_id_34 FROM s_user s1_, s_user s0_ LEFT JOIN s_user_attributes s2_ ON s0_.id = s2_.userID WHERE s2_.bestit_amazon_user_id = ?

 

Das Problem ist, ich kann nicht genau erkennen was diese Abfrage macht. Die Daten eines Benutzers auslesen, aber warum ist das Ergebnis über 200 Millionen?

Leere ich zB in der Datenbank die Tabelle s_user_attributes, dann ist der Fehler behoben. Dann sind aber leider auch alle Kundenkonten zerstört.

Kann mir jemand sagen, was genau diese Querie da ausließt? Foot-in-Mouth

11

Die Payment-Tabellen können schon ziemlich fett sein. Vielleicht müsste man sie bereinigen.

Die obige Abfrage mit bpsw. 10 statt dem ? läuft bei mir bruchteilen von Sekunden (Die Abfrage dauerte 0.0143 Sekunden.)

12

Ich habe in der s_user_atrributes etwa 70.000 Einträge.

Wie gesagt, lösche ich zB die ganzen Bonitäsprüfungen, die dort auch mit gespeichert werden, dann geht es. Laut Shopware darf man in der Tabelle aber nichts löschen.