search

Inxmail / inx_magento1

Inxmail Professional Email Marketing für Magento CE und EE (1.x)
0 stars 0 forks source link

Unsubscriptions werden in der Version 3.1.0.5 nicht mehr in Magento übernommen [INX-12] #24

Closed falco-knapp closed 8 years ago

falco-knapp commented 8 years ago

Der Unsubscription Cronjob funktioniert nicht mehr korrekt seit der Version 3.1.0.5. Abmeldungen in Inxmail werden nicht mehr berücksichtigt.

In den Versionen 3.1.0.3 und 3.1.0.4 funktionierte diese Funktionalität noch.

Zusätzliche Analyse:

Darüber hinaus scheint der Cronjob sehr langläufig zu sein. Ein Kunde hat eine Magento-Liste mit 350k Empfängern und 150k Abmeldungen. Laut Aussage benötigt der Cronjob 30 Minuten. Dabei ist der Shop in Australien und der Inxmail Server in Deutschland. Es gibt nun folgende Hypothesen:

  1. Die Verbindung / Nutzung der API hat eine sehr hohe Latenz, so dass 30 Minuten nachvollziehbar sind.

  2. Der Cronjob Code macht irgendwas falsch. Ich habe die Befürchtung, dass durch den Aufruf if ($subscriber->isSubscribed()) { $subscriber->unsubscribe(); }

    Der Observer ausgeführt wird und dadurch erneut der Empfänger in Inxmail abgemeldet wird. Ich habe den Cron job wie folgt interpretiert:

image

Stimmt das Diagramm und die Hypothese, dass der Observer erneut ausgeführt wird?

Fehlerbeschreibung

In Version 3.1.0.4 und früher führte eine Abmeldung in Inxmail (in einer Gruppen-Liste oder in einer Basis-Liste) dazu, dass dieser Empfänger in Magento als "abgemeldet" gekennzeichnet wurde. Die Änderung führte anschließend dazu, dass der Benutzer durch den Observer auf jeden Fall von der Basis-Liste gelöscht wurde. In Version 3.1.0.5 werden die Empfänger überhaupt nicht mehr als "abgemeldet" gekennzeichnet.

BrocksiNet commented 8 years ago

Hallo Falco, wir prüfen das gerade. Danke für die Info.

BrocksiNet commented 8 years ago

Warten auf Feedback in Issue: https://github.com/Inxmail/inx_magento1/issues/25

falco-knapp commented 8 years ago

Ich habe diesen Fall in der Version 3.1.0.4 getestet und genau dies beobachtet:

Status Vorher:

Cronjob für Abmeldungen wird ausgeführt. Die Empfänger in Magento die Abgemeldet werden werden erneut in Inxmail abgemeldet: image

Status Nachher:

BrocksiNet commented 8 years ago

Das Problem hier sollte auch mit Commit f27d5720cf28e4199fb6c40803845c9800f6644d erledigt sein. Wir bräuchten hier einen Test mit vielen Daten um entscheiden zu können ob hier am Speed noch gearbeitet werden muss. Oder könnte Ihr das machen @falco-knapp ? Ansonsten müssten wir wohl einfach zufällig Daten generieren und die in unseren Test-Account pushen. Bitte um Info.

falco-knapp commented 8 years ago

Ich kann den Test durchführen. Ich habe bereits einen Testmandanten mit sehr vielen Empfängern und kann die Resultate dann hier einbringen.

falco-knapp commented 8 years ago

Die Abmeldungen werden in 3.1.0.6 wieder in Magento übernommen.

falco-knapp commented 8 years ago

3.1.0.4 Test mit ~ 150k abmeldungen in Inxmail und ca 110 Empfänger die in Magento abzumelden sind (Insgesamt nur 110 Empfänger in Magento) 2015-11-17 12:57:01 --> 2015-11-17 13:09:56, Dauer: 12:55

Änderung der Laufzeit, wenn die Empfänger in Magento bereits abgemeldet sind: 2015-11-17 12:33:01 -> 2015-11-17 12:44:58: Dauer: 11:57 2015-11-17 13:09:56 -> 2015-11-17 13:22:01, Dauer: 12:05

3.1.0.6 gleiche Bedingungen: 2015-11-23 13:25:01 --> 2015-11-23 13:40:56, Dauer: 15:55 2015-11-23 13:57:02 --> 2015-11-23 14:12:47, Dauer: 15:45

Änderung der Laufzeit, wenn die Empfänger in Magento bereits abgemeldet sind: 2015-11-23 15:09:01 --> 2015-11-23 15:23:09, Dauer: 14:08

Die Performance hat sich also scheinbar leicht verschlechtert (um ca. 16%)

falco-knapp commented 8 years ago

Wenn die Empfänger in Magento bereits abgemeldet sind und dadurch nicht erneut durch den Observer abgemeldet werden, so ändert sich die Laufzeit lediglich um ca 1 Minute. D.h. das Optimierungspotential liegt zwischen 5 - 8% wenn die Observer-Logik verbessert wird, wobei das sehr stark vom Mengengerüst abhängt.

BrocksiNet commented 8 years ago

Hallo Falco, bist du dir sicher das eure API bei beiden Test in der gleichen Geschwindigkeit geantwortet hat? Also können wir das als schwankenden Faktor ausschließen?

Ansonsten natürlich die Frage ob wir dann hier noch nach Optimierungspotential schauen sollen?

falco-knapp commented 8 years ago

Ich werde morgen nochmal beide Versionen nacheinander Testen um das soweit wie möglich auszuschließen.

Ich würde erstmal noch nicht effektiv nach Optimierungspotential suchen und die Messungen von morgen nochmal abwarten.

falco-knapp commented 8 years ago

Was ich auf jeden Fall beobachte: Ein Cronjob der jede volle Stunde ausgeführt wird, obwohl alles ausgestellt ist in Backend-Config:

| 5897 | dndinxmail_subscriber_synchronize_unsubscribed | success | NULL | 2015-11-23 15:57:02 | 2015-11-23 16:00:00 | 2015-11-23 16:00:02 | 2015-11-23 16:17:11 | | 5960 | dndinxmail_subscriber_synchronize_unsubscribed | pending | NULL | 2015-11-23 16:56:02 | 2015-11-23 17:00:00 | 2015-11-23 17:00:01 | NULL |

falco-knapp commented 8 years ago

Hallo Björn,

dieser Cronjob der immer ausgeführt wird ... wie kommt der zustande?

Danke und Gruß,

Falco

Ich versuche die Frage selbst zu beantworten:

  1. Die Cronjobs sind in Magento per xml konfiguriert. Die Cron-Expression ist Leer bzw. wird geleert, wenn der Cronjob im Backoffice deaktiviert wird.
  2. Falls das Magento-Modul deaktiviert wird (Inxmail -> Config -> Allgemein), dann wird die Cron-Expression nicht geleert wenn die Cron-Config abgeschaltet wird.
  3. Wenn Modul Aktiviert, Crons Deaktiviert und eine Cron-Expression dennoch existiert (kann man mit AOE_Scheduler sehen), dann wird der Cronjob auch tatsächlich ausgeführt. Der unsubscription Cronjob überträgt dann tatsächlich die Abmeldungen, obwohl im Backoffice der Cronjob als "deaktiviert" gekennzeichnet ist.
  4. Unklar ist aber immer noch, warum der Cronjob scheinbar immer zur vollen Stunden ausgeführt wird. Liegt dies an der "Default" config? Jetzt hatte ich gerade den Fall, dass der cronjob nicht zur vollen Stunde gestartet wurde. Das ist für mich noch nicht schlüssig. Config in diesem Fall war: Modul aktiv, Cronjobs deaktiviert, in AOE_Schedular wird der Cronjob als Aktiv aber ohne Cron expression angezeigt.
  5. Nach Reaktivierung des Cronjobs, wurde dieser seltsamerweise 2x ausgeführt.
falco-knapp commented 8 years ago

Heutiger Test zwischen 3.1.0.4 und 3.1.0.6:

3.1.0.6: alle Empfänger in Magento sind bereits abgemeldet, nur 1 Storeview. ~ 150k abmeldungen in Inxmail und entsprechend ~107 in Magento (abgemeldet): 2015-11-24 08:39:01 --> 2015-11-24 08:51:08, Dauer: 12:07 24.11.2015 10:04:01 --> 24.11.2015 10:16:50, Dauer: 12:49

3.1.0.4: alle Empfänger in Magento sind bereits abgemeldet, nur 1 Storeview. ~ 150k abmeldungen in Inxmail und entsprechend ~107 in Magento (abgemeldet): 2015-11-24 09:19:01 --> 2015-11-24 09:29:14, Dauer: 10:13 2015-11-24 09:39:01 --> 2015-11-24 09:48:57, Dauer: 09:65

Ich denke, dass somit mit hoher Wahrscheinlichkeit die API Responsezeiten selbst nicht schuld an der leichten Verschlechterung sind.

falco-knapp commented 8 years ago

Das Fehlverhalten der Cronjobs konnte ich auch in Version 3.1.0.4 beobachten. Daher ist dies kein Folgefehler der Anpassungen hier. Ich werde für diesen Fehler ggfls. ein separates Ticket öffnen.

@bjoern-flagbit: Gibt es eine Erklärung, warum die Performance sich verschlechtert haben könnte?

BrocksiNet commented 8 years ago

Die Erklärung scheint zu sein das wir die Empfänger jetzt abhängig vom Store holen und das es auf dieser Tabelle in Magento keinen Index gibt und es deshalb langsamer ist als vorher. Es gibt quasi ein zusätzliches Select welches nur die Empfänger eines bestimmten Stores holt. Unten noch das genaue Feedback von Alex in English.

Feedback von Alex

I think at least one of the reasons is that we load subscriptions by few fields and magento loads them by only one field that has index, but there are no composite indexes for subscription table in default magento. We can try to add composite indexes for "newsletter_subscriber" table, such as:

  1. customer_id, store_id
  2. subscriber_email, store_id
falco-knapp commented 8 years ago

Ok, danke für den Hinweis. Für 3.1.0.6 werden wir dies aber nicht weiter optimieren. Damit ist dieses Ticket erstmal getestet und ich schließe es daher.