Posts by ArtCore7

    Auch gut finde ich die damals ja aktuellen Zeichen im <title> - = Netcup = - :D

    Kannst ja für dich übernehmen :D


    WordPress Seite und schlechte Performance bei Netcup im Webhosting... Ich glaub dieses Lied wiederholt sich langsam zu oft.


    Ich werde auf jedenfall die Tage ein Ticket an den Support aufmachen. Es kann doch nicht sein, dass der Webspace echt gut läuft und die Datenbank Server wohl über die Grenzen hinaus komplett überbucht sind.


    PS: Ja es liegt zu 95% am DB Server von Netcup


    [netcup] Felix P. : Eventuell kann man hier mal was dazu sagen. Ich will ja nicht die Performance wie auf meinem VPS500 mit einer DB. Aber Ladezeiten bis 10 Sekunden (im schlechtesten Fall) im WordPress Backend verkrault eben eure Kunden (siehe Thread Starter)

    Gleiche Probleme habe ich auch festgestellt und kann dir nun mit Sicherheit sagen es liegt bei WordPress an den Datenbank Servern.


    Da ich noch einen ungenutzten VPS500 hatte habe ich dort mal die DB hingezogen und siehe da. Ich hab Query Monitor Zeiten von unter einer Sekunde im Backend. Da macht das Arbeiten wieder Spaß.


    Bin grad am Handy, aber hier auch ein Screenshot aus Query Monitor im Dashboard.


    Screenshot_20200624-070655_Chrome.jpg

    Gerade nochmal mit


    mysqld  Ver 10.2.32-MariaDB-1:10.2.32+maria~bionic for debian-linux-gnu on x86_64 (mariadb.org binary distribution)


    getestet, hier tritt der Fehler nicht auf.


    Edit: War wohl ne Sekunde schneller :D

    Gerade gefunden bei meinem Pagebuilder .... die haben es wohl gefixt. Ich hab es nicht upgedated (Lizenz ausgelaufen)


    Bug Fixes

    • Fixed database query issue when duplicating layouts on MariaDB 10.3+


    PHP
    1. // @codingStandardsIgnoreStart
    2. $wpdb->query( "INSERT INTO {$wpdb->postmeta} (post_id, meta_key, meta_value) values ({$new_post_id}, '{$meta_key}', '{$meta_value}')" );
    3. // @codingStandardsIgnoreEnd


    Trotzdem bleibt ja der Fehler bei UNION ALL bestehen.

    Version in meinem Fall:


    Code
    1. mysqld Ver 10.4.13-MariaDB-1:10.4.13+maria~focal for debian-linux-gnu on x86_64 (mariadb.org binary distribution)


    Hab dann auch noch schnell getestet:


    'fl_builder_data' als erstes SELECT ausführen, und danach die anderen "kurzen" Daten.

    - Auch beim ersten SELECT mit den langen Daten wird das ganze gekürzt.


    'fl_builder_data' mit "Lorem ipsum" Text ersetzen und erneut versuchen.

    - Auch mit Lorem ipsum Text wird das ganze gekurzt. Also auch kein Problem mit meinen Daten.

    Werde später noch ein wenig rumspielen und mal gucken ob es mit "Lorem ipsum" Text zu den selben Problemen kommt. Nur aktuell leider keine Zeit.


    Geplannte Versuche:

    • 'fl_builder_data' als erstes SELECT ausführen, und danach die anderen "kurzen" Daten.
    • 'fl_builder_data' mit "Lorem ipsum" Text ersetzen und erneut versuchen.
    • PHP Script umbauen, das er jedes Query einzeln an die DB schickt <- Workaround. (Nach Update des Pagebuilder immer wieder dran denken <X)

    Der einzelne Select klappt.

    Kann ich bestätigen auf der MariaDB


    PHP
    1. $sql_select[] = "SELECT {$new_post_id}, '{$meta_key}', '{$meta_value}'";}
    2. $sql .= implode( ' UNION ALL ', $sql_select );
    3. // @codingStandardsIgnoreStart
    4. $wpdb->query($sql);
    5. // @codingStandardsIgnoreEnd


    Das ganze wird ja hier so aufgebaut, wahrscheinlich damit nur eine Datenbank-Verbindung aufgebaut werden muss und nicht "x"-Verbindungen für jede postmeta. Könnte die Funktion mal umschreiben, das er jedes Select einzeln schickt.

    Hab das ganze gerade nochmal mit Server version: 8.0.20 MySQL Community Server - GPL probiert und siehe da... der Mag das komplette Query.


    mysqld 8.0.20:

    | 3964 | _fl_builder_data | 116311 |


    Edit: Ohh doch nicht 100% die gleiche Länge, dies kann aber eventuell an einem anderen Insert liegen, welches ich noch offen hatte. Aber er bricht nicht bei 50k ab.

    So ThomasChr hat es mal bei einer neuen MariaDB Installation probiert, alles ein wenig Komisch.


    | post_id | meta_key | length(meta_value) |


    Original:

    | 3838 | _fl_builder_draft | 116523 |


    ThomasChr Ergebnis:

    | 3964 | _fl_builder_data | 50987 |


    Mein Ergebnis:

    | 3964 | _fl_builder_data | 51016 |

    Schönes Rätsel, halt uns auf dem laufenden :-)


    Code
    1. /* Neu angelegte Werte in Datenbank */
    2. s:13:"margin_bottom";s:1:"0";s:20:"margin_bottom_medium";s:0:"";s:24:"margin_bottom <- ENDE
    3. /* Werte die kopiert werden sollten */
    4. s:13:"margin_bottom";s:1:"0";s:20:"margin_bottom_medium";s:0:"";s:24:"margin_bottom_responsive";s:0:"";s:11:"margin_left"; -> MEHR
    5. /* Werte aus dem Query Log */
    6. s:13:\"margin_bottom\";s:1:\"0\";s:20:\"margin_bottom_medium\";s:0:\"\";s:24:\"margin_bottom_responsive\";s:0:\"\";s:11 -> MEHR
    7. // Bemerkung addslashes ( ) //


    Hier auch kein Super Sonderzeichen zu sehen, welches die Speicherung in die Tabelle unterbrechen sollte.

    Steht auf 16MB sollte also für die paar Zeichen reichen :D
    max_allowed_packet = 16777216


    General log mitlaufen lassen

    INSERT INTO wn_postmeta (post_id, meta_key, meta_value)

    UNION ALL SELECT 3964, '_fl_builder_data', '---> ALLE DATEN <---'


    Also kommen die Daten richtig an werden aber nicht komplett gespeichert.


    Eventuell ein Unicode Problem der Verbindung? (Stichwort utf8mb4)

    SET NAMES utf8mb4
    SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'


    Wird beim verbinden von Wordpress zur DB also richtig gesetzt.


    Oder befindet sich an der abgeschnittenen Stelle vielleicht zufällig irgendein Sonder-/Steuerzeichen?

    Ok meine nächste Aufgabe, ich danke schonmal für die Denkanstöße, ich guck mir mal die vielen Zeichen an. :D

    Hallo Netcupler,


    Heute benötige ich mal wieder eure Hilfe um ein kleines Problem in den Griff zu bekommen. Ich habe ein Webhosting (4000er) und ein VPS (500er) da beim Webhosting das Wordpress immer langsamer wurde und die Datenbank Queries immer länger gebraucht haben, dachte ich mir setz doch mal schnell auf dem leeren VPS500 eine MariaDB Docker auf und guck wie schnell die Seite dann ist. Hat auch gut funktioniert und die Seite ist um EINIGES schneller geworden. Jetzt kommen wir aber zum Problem:


    Auf der Wordpress Seite verwende ich Beaver Builder, um einen Beitrag / Seite zu duplizieren hat Beaver Builder dafür eine Funktion, wenn ich diese ausführe wird die Seite auch erstellt aber leider werden in der Datenbank einige KB's von wichtigen Daten geschluckt oder kommen da eben nicht an. Ich hab mir die Funktion dann mal angeschaut.


    Was passiert:

    Original Beitrag (ID 3838) fl_builder_data:

    pasted-from-clipboard.png


    Duplizierter Beitrag (ID 3935) (auch beim zweiten duplizieren, wieder 36270 Zeichen)

    pasted-from-clipboard.png


    Also habe ich es mit einem anderen Beitrag erneut versucht (Ausgang ca. 100.000 Zeichen, nach dem duplizieren dann 36.807 Zeichen). Also verschluckt er irgendwo beim Senden oder Empfangen die Zeichen.


    Die Funktion:


    Also eigentlich was ganz einfaches, erstelle einen neuen Beitrag und lese die "postmeta" Daten aus und füge sie dem neuen Beitrag hinzu.


    So, dann hab ich mir eine Testseite erstellt, um zu gucken ob er die vollständige postmeta ausließt:

    PHP
    1. $post_meta = $wpdb->get_results( $wpdb->prepare( "SELECT meta_key, meta_value FROM {$wpdb->postmeta} WHERE post_id = %d", $post_id ) );

    Zieht alle postmeta Daten richtig aus der Datenbank, die Zeichen passen (116.430)


    Also schauen wir mal ob die Daten gesendet werden (in der foreach hab ich folgendes eingebaut:)

    PHP
    1. echo('postID: '.$new_post_id.'<br> meta_key: '.$meta_key.'<br> metavalue_len: '.strlen($meta_value).'<br>');

    Siehe da, auch hier werden die Daten komplett angezeigt und die Länge passt überein.


    Also dachte ich mir, eventuell irgendwo Probleme, dass der mariadb Server nicht mehr wie 32kb an Daten annimmt (LONGTEXT ist richtig gesetzt -> bis 4GB), hab dann eine Datenbank angelegt und die 116.430 Zeichen an die Datenbank geschickt. Hier kommen die Daten ohne Probleme in voller Länge an.


    Frage:

    Fällt euch noch was ein, wo die Daten verloren gehen können ? Oder hab ich gerade einen groben Denkfehler.