Support » Plugin: Germanized for WooCommerce » TRUNCATE TABLE Abfrage – Warum?

  • Resolved mike8040

    (@mike8040)


    Moin,

    DHL ist nicht aktiv auf der Webseite und dennoch mit recht hoher Abrufzeit:

    Query Monitor:

    TRUNCATE TABLE W*****_woocommerce_gzd_dhl_im_products	
    
        Vendidero\G\D\A\ImProductList->update()
    
    	Plugin: woocommerce-germanized 	1 	0,1658
    TRUNCATE TABLE W*****_woocommerce_gzd_dhl_im_product_services	
    
        Vendidero\G\D\A\ImProductList->update()
    
    	Plugin: woocommerce-germanized 	1 	0,1603

    Weiß jemand was und warum sind die Tasks so behäbig?

Viewing 15 replies - 1 through 15 (of 15 total)
  • Plugin Author vendidero

    (@vendidero)

    Hi,

    hast du den Versanddienstleister Deutsche Post unter Germanized > Versanddienstleister aktiviert? Hier werden die Produktdaten einmal täglich aktualisiert.

    Grüße

    Thread Starter mike8040

    (@mike8040)

    Deutsche Post ist aktiviert. Versteh nicht warum die Anfrage bei jeder Seitenaktualisierung im Backend im Dauermodus auftaucht. Es wirkt als ob der Job im Dauermodus ausgeführt wird und nicht einmal täglich. Soll dies so sein?
    Vor dem letzten Update hatte ich auch bei den DP Login Daten und Einstellungen einen Syntax Error. Es fehlten die Eingabefelder zu den Login Daten. Irgendwas ist murks seit April.

    Plugin Author vendidero

    (@vendidero)

    Hi,

    also die Logik funktioniert eigentlich recht einfach über einen Transient, s.a.: https://github.com/vendidero/woocommerce-germanized-dhl/blob/master/src/Api/Internetmarke.php#L197

    d.h. eine Aktualisierung findet nur dann statt, wenn der transient nicht vorliegt/entfernt wurde.

    Ich habe aber diesbezüglich noch einen kleinen Bug gefunden, den ich gerade behoben habe aber ich denke nicht, dass das damit zusammenhängt, da der Bug nur dazu führte, dass der transient kein Ablaufdatum hatte. Läuft bei dir mit den transients vielleicht etwas falsch?

    Grüße

    Thread Starter mike8040

    (@mike8040)

    Also seit dem Update von 3.81 auf 3.90 ist die Wartezeit beim Abschließen einer Bestellung um ~400% gestiegen. Also der Prozess von “in Bearbeitung” auf “Abgeschlossen” hängt extrem. War es vorher unter einer Sekunde, kann man jetzt bis 4 oder 5 zählen bis die Order Detailseite aktualisiert ist. Restliche Adminseiten laden wie gewohnt oder subjektiv sogar schneller. Ab Änderung am Bestellstatus hängen extrem.
    Ich habe auch WooCommerce von 6.30 (nicht ganz sicher mehr) auf 6.41 geupdated. Die Performance ist in der Orderseite katastrophal.

    Plugin Author vendidero

    (@vendidero)

    Hm, hast du denn die Problematik mit dem DB Update der IM Produkte genauer untersucht und mal in der wp_options Tabelle nach dem Transient gesucht z.B. via option_name LIKE '%wc_gzd_dhl_im_products_expire%'? Findest du da etwas?

    Lässt du Sendungen + Labels ggf. automatisch direkt nach der Bestellung erzeugen?

    Außerdem solltest du im Zweifel testweise auch alle Plugins bis auf Woo und Germanized deaktivieren und ein Default-Theme aktivieren. Wie sieht es dann aus?

    Grüße

    • This reply was modified 6 months, 3 weeks ago by vendidero.
    Thread Starter mike8040

    (@mike8040)

    Lässt du Sendungen + Labels ggf. automatisch direkt nach der Bestellung erzeugen?

    Nein ist nicht aktiv. Jedoch ist die Option aktiv, (die uns sehr wichtig ist), welche die Bestellung automatisch auf Abgeschlossen setzt sobald die Sendung als versandt gespeichert wird. Dies war in der Vergangenheit bereits irgendwie holprig.

    Leider lassen sich auf Grund von proprietären Lizenz Strukturen vereinzelter Erweiterungen nicht alle Lizenzen auf der Staging Seite nutzen, damit lässt sich es nicht 1 zu 1 vergleichen.

    Die anderen Vorschläge werde ich im Lauf des Abends prüfen.

    Thread Starter mike8040

    (@mike8040)

    Ok sehr interessant. Ich erinnerte mich an die holprige Geschichte mit dem speichern des Statuses. Wenn die Sendung im Tab Sendungen auf “Versandt” gestellt wird und dann “Speichern” genutzt wird, dann ist die Bestellung fast instant auf Abgeschlossen gesetzt und abgelegt.
    So. Wenn man jedoch im Tab Sendungen auf “Versandt” stellt und dann “Aktualisieren” betätigt, dann rodelt er 4-5 Sekunden bis die Bestellung als solche abgelegt ist. Dies war in den vergangenen Versionen kein Thema und gleich flott.
    Wir nutzen Aktualisieren deshalb, weil dies immer sichtbar ist und für den Button Speichern man runterscrollen und suchen muss was im Lauf des Tages Zeit kostet.

    EDIT: Die “neue” Wartezeit gilt anscheinend auch für Abänderungen an der Adresse die ebenfalls mit Aktualisieren bestätigt wird.

    • This reply was modified 6 months, 3 weeks ago by mike8040.
    • This reply was modified 6 months, 3 weeks ago by mike8040.
    Plugin Author vendidero

    (@vendidero)

    Hi,

    EDIT: Die “neue” Wartezeit gilt anscheinend auch für Abänderungen an der Adresse die ebenfalls mit Aktualisieren bestätigt wird.

    Denke das hat also eher etwas mit einem Speichern-Event der Bestellung zu tun – vermutlich klinkt sich ein Plugin ein und nimmt weitere Aktionen vor. Nutzt ihr Germanized Pro (z.B. zum Erstellen von PDF-Dokumenten)?

    Grüße

    Thread Starter mike8040

    (@mike8040)

    Nein keine Pro Version. Ist aber für die Zukunft angedacht. Leider ist mal wie so häufig mit WordPress durch ein Update vieles schlimmer als besser. Das einzige was nach einem Update Sicherheit bietet, ist ein Backup. Ich habe keine Ahnung, aber bei der Palette an Änderung durch Woocommerce von x.3 zu x.41 liegt der Hund da begraben. Ich geh mal davon aus, dass ich das Backup rüberbügel und alle neuen Bestellung importiere. Kein Zeit und Lust Problemen nachzujagen, die vor 24 Stunden nicht existierten.

    Plugin Author vendidero

    (@vendidero)

    Hi,

    ich würde dir generell empfehlen solche Updates allesamt erst in einer Staging-Umgebung zu testen und erst danach in der Live-Umgebung zu updaten. Das spart jede Menge Nerven, insbesondere da es wirklich sehr schnell in WP zu Inkompatibilitäten bzw. Edge-Cases kommen kann: https://vendidero.de/debugging-woocommerce-probleme-finden-und-beheben

    Grüße

    Thread Starter mike8040

    (@mike8040)

    Das ist auch mein gängiger Vorgang und auch üblich. Diesmal zeitbedingt die Abkürzung die in einer idealen Welt auch jedem wohl lieber wäre. Ich habe eine Kopie des aktuellen Zustands auf einer neuen Staging und habe folgende Feststellung gemacht. Da ist auf jeden Fall etwas murks mit der Deutschen Post Anbindung.

    Deaktiviere ich Deutsche Post als Versanddienstleister:

    …springt die Ladezeit von 21sec auf 3,5sec bei Aktualisierung des Bestellstatus von In Wartestellung > Bearbeitung

    …springt die Ladezeit von 24sec auf 3,5sec bei Aktualisierung der Bestellstatus von Bearbeitung > Abgeschlossen

    Ladezeit Orderliste > Bestelldetails von 1,7sec auf 9sec nur wenn die Deutsche Post Integration aktiv ist`

    DB gecleant und alte Transienten gelöscht. Ruft Germanized die Produktliste jedes mal ab wenn die Bestelldetails geöffnet werden neuerdings? Wenn ja warum erneut beim in die Bearbeitung setzen oder Abschließen der Order. Nach meinem Erachten wäre dies doch erst notwendig wenn die Labelauswahlform geöffnet wird.

    //EDIT:

    Version 3.91 vs 3.84

    springt die Ladezeit von ~20sec auf 3,5sec bei Aktualisierung der Bestellstatus von In Wartestellung > Bearbeitung

    springt die Ladezeit von ~20sec auf 3,5sec bei Aktualisierung der Bestellstatus von Bearbeitung > Abgeschlossen

    Ladezeit Orderliste > Bestelldetails von 9sec auf 1,7sec

    Also irgendwas ist seit der Versio 3.84 passiert was hier das Backend so gar nicht mag

    • This reply was modified 6 months, 3 weeks ago by mike8040.
    • This reply was modified 6 months, 3 weeks ago by mike8040.
    • This reply was modified 6 months, 3 weeks ago by mike8040.
    • This reply was modified 6 months, 3 weeks ago by mike8040.
    • This reply was modified 6 months, 3 weeks ago by mike8040.
    • This reply was modified 6 months, 3 weeks ago by mike8040.
    Thread Starter mike8040

    (@mike8040)

    Als ware es so einfach. Der Grund für das Updaten war das Ende letzter Woche die DP Anbindung und die Labelform plötzlich den Dienst quittierten mit der Meldung “Falscher Benutzername oder Passwort”. Die Daten waren aber korrekt.
    Auf der Live Site bin ich nun auf 3.84 zurück und dieser Fehler besteht weiterhin. Im Reiter Labels steht folgendes:
    API Fehler
    Falscher Benutzername oder Passwort

    In der heutigen Staging ist dies Problem nicht vorhanden. Lösche ich den Benutzer und das Passwort und speichere, tauchen die Login Daten wieder auf. Das gilt auch für die Versionen. x.80 – 0x.84. Wobei bei 3.81 sind sie leer und speichere ich sie, verschwinden sie gleich wieder.

    Plugin Author vendidero

    (@vendidero)

    Hi,

    also ich denke immer noch, dass das Problem damit zusammenhängt, dass deine Produktdaten nicht korrekt in die DB geschrieben werden können, sodass es ständig zum Update der DP Produktdaten via API kommt, was definitiv nicht normal ist und sich für mich auch nicht reproduzieren lässt. Das solltest du also definitiv kontrollieren (z.B. ein paar Testausgaben hier vornehmen: https://github.com/vendidero/woocommerce-germanized-dhl/blob/master/src/Api/ImProductList.php#L379 bzw. https://github.com/vendidero/woocommerce-germanized-dhl/blob/master/src/Api/Internetmarke.php#L200 vornehmen). Normalerweise ist die DB Abfrage natürlich schnell, insofern nicht immer die API bemüht werden muss.

    Grüße

    Thread Starter mike8040

    (@mike8040)

    Also um das Thema abzurunden. Es ist alles back to normal bzw. etwas flotter im Backend Seitenaufbau. Grund für dieses Theater war ein Upgrade des Siteground Optimizers Plugins das separat zu den globalen Einstellung im Account, im Plugin selbst pro Seite die MemCache steuert/aktiviert. Die Option war nach dem Update aktiviert. Auch wenn SG breit bewirbt, dass MemCache so toll ist für dynamischen Content, ist meine Erfahrung genau das Gegenteil. Leider eine völlige Performance Bremse bei den Herren von SG

    Plugin Author vendidero

    (@vendidero)

    Hui, interessant aber freut mich, dass es nun wieder passt 🙂

    Grüße

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘TRUNCATE TABLE Abfrage – Warum?’ is closed to new replies.