Ansprache remote DB-Host (2. Root-Server im gleichen vLAN) steigert Seitenladezeit um 300%

  • Liebe Community,


    ich habe ein Problem mit der Ansprache eines Remote-DB-Host innerhalb eines vLan zwischen 2 Netcup-Root-Servern.


    Hintergrund:

    Initiales Wordpress auf Root-Server langsam, Galera-Cluster mit Load-Balancer aufgesetzt – funktioniert, aber Zugriffszeiten sind gegenüber der ursprünglich bereits bemängelten, lokalen Installation mit Nginx und mariadb auf dem gleichen Server statt besser sogar massiv schlechter (!) geworden.


    Habe weiter geforscht und das Problem auf die grundsätzliche Ansprache eines externen DB-Host eingrenzen können. Dazu folgendes Testsetting:


    2 Netcup-G9.5 Root-Server über Cloud vLAN Free in einem vLAN verbunden.

    Auf beiden Servern läuft identisches Debian + Plesk, Nginx + MariaDB mit identischen Konfigurationen von Nginx und mariadb

    • RS 8000 G9.5 | lokale IP: 192.168.0.10
    • RS 1000 G9.5 | lokale IP: 192.168.0.50

    è vLan steht, Latenzzeiten scheinen mir ok:


    von a) nach b)


    root@gallant-jepsen:~# ifconfig eth1


    eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500


    inet 192.168.0.10 netmask 255.255.255.0 broadcast 192.168.0.255


    inet6 fe80::4858:a7ff:fea9:5b30 prefixlen 64 scopeid 0x20<link>


    ether 4a:58:a7:a9:5b:30 txqueuelen 1000 (Ethernet)


    RX packets 52602 bytes 223049414 (212.7 MiB)


    RX errors 0 dropped 0 overruns 0 frame 0


    TX packets 44606 bytes 5202949 (4.9 MiB)


    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



    root@gallant-jepsen:~# traceroute 192.168.0.50


    traceroute to 192.168.0.50 (192.168.0.50), 30 hops max, 60 byte packets


    1 192.168.0.50 (192.168.0.50) 1.280 ms 0.459 ms 1.249 ms



    Von b) nach a)


    root@modest-murdock:~# ifconfig eth1


    eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500


    inet 192.168.0.50 netmask 255.255.255.0 broadcast 192.168.0.255


    inet6 fe80::47c:50ff:fefc:5dcc prefixlen 64 scopeid 0x20<link>


    ether 06:7c:50:fc:5d:cc txqueuelen 1000 (Ethernet)


    RX packets 76253 bytes 8801545 (8.3 MiB)


    RX errors 0 dropped 0 overruns 0 frame 0


    TX packets 71676 bytes 371647133 (354.4 MiB)


    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



    root@modest-murdock:~# traceroute 192.168.0.10


    traceroute to 192.168.0.10 (192.168.0.10), 30 hops max, 60 byte packets


    1 192.168.0.10 (192.168.0.10) 0.403 ms 0.377 ms 0.376 ms



    Auf beiden Servern liegt das gleiche Wordpress-Paket (htdocs und SQL-Inhalt identisch).

    Bei Nutzung des jeweils lokalen DB-Servers (egal ob DB-HOST per localhost / 127.0.0.1 / vLAN-IP / externe IP angegeben) ergeben sich auf beiden Servern Seitenladezeiten von ca. 2,5 Sekunden. Nicht doll – aber in der Sache wohl unumgänglich.



    Problem:

    Sobald ich den DB-HOST per vLAN-IP auf den jeweils anderen Server schauen lasse, verlängern sich die Seitenladezeiten auf das 3-4 fache (also 8 Sekunden statt 2,5).



    Auf beiden Servern ist in der /etc/mysql/my.cnf skip-name-resolve=ON gesetzt, so dass sinnlose DNS-Abfragen nicht der Grund sein dürften.



    Hat jemand eine Idee?



    Viele Grüße



    Stephan

  • Wie schnell sind SQL Abfragen, wenn du diese auf der Konsole ausführst? Hast du dir mal die Querys in WP anschaut, wie Umfangreich das alles ist?

    Wie hast du die 2.5sec gemessen und von wo aus? Das ist nur zum Verständnis woher die Werte kommen.

  • aber Zugriffszeiten sind gegenüber der ursprünglich bereits bemängelten, lokalen Installation mit Nginx und mariadb auf dem gleichen Server statt besser sogar massiv schlechter (!) geworden.

    Erwartbar - immerhin steuerst du die Datenbank über einen LoadBalaner an - wer weiß, welchen Server dieser noch auswählt - über ein VXLAN statt eines Unix Domain Sockets.



    mit Load-Balancer

    MariaDB MaxScale? Hast du mal eine Config?



    Initiales Wordpress auf Root-Server langsam

    Wie setzt du PHP ein? Hast du die Config angepasst?

    Setzt du ein Caching ein?


    Ich würde hier ansetzen - die Datenbank wird hier kaum das langsamste sein.

    Wenn du die Datenbank auslagern willst, weil sie "langsam" ist, halte ich das für die falsche Herangehensweise.

  • Remote DB ist eben so. Latenz gilt für jedes Query einzeln, bei Seitenaufrufen mit vielen Queries summiert sich das dementsprechend. Obendrauf kommt dann noch die Bandbreite, die jedes Query benötigt. Hier wird oft zuviel abgefragt (SELECT * ohne Limit) was dann tatsächlich gar nicht benötigt wurde. Lokal fällt das oft nicht weiter auf, Remote tut es sehr schnell ziemlich weh. Da hast du dir mit mehreren Servern dann keine zusätzliche Performanz geschaffen, sondern nur einen schönen Flaschenhals gebaut.


    Wenn deine Anwendung nicht speziell darauf optimiert worden ist, bist du mit der Remote DB auf dem Holzweg.

  • […] Galera-Cluster mit Load-Balancer aufgesetzt

    […] Dazu folgendes Testsetting:

    2 Netcup-G9.5 Root-Server über Cloud vLAN Free in einem vLAN verbunden.

    Auf beiden Servern läuft identisches Debian + Plesk, Nginx + MariaDB mit identischen Konfigurationen von Nginx und mariadb

    seaac : Unabhängig vom geschilderten Problem: Vielleicht lese ich das Obige falsch, aber einen MariaDB-Cluster mit einer geraden Anzahl von Knoten zu betreiben, ist grundsätzlich keine gute Idee, es sei denn, wir reden hier von einem Master-Slave-Szenario – das widerspräche aber obengenannten „identischen Konfigurationen“.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Hallo zusammen,

    vielen Dank für die Antworten!

    Ich habe mich aber wohl blöd und nur verkürzt ausgedrückt:

    1) Gestartet bin ich mit einem Root-Server (RS 8000 G9.5) der bei Verwendung der lokalen DB (Netcup Image Debian 10 + Plesk) die Seite im isolierten Testbetrieb 2,5 Sekunden ausliefert. Diese 2,5s sind nicht toll, aber dem Unterbau von Wordpress geschuldet und kurzfristig nicht änderbar


    2) Das Problem tritt auf, wenn mehrere Anwender zugreifen - dann stauen sich die queries und die Auslieferzeiten steigen in inakzeptable Bereiche (>10 Sekunden). Daher die Idee die DB per Cluster zu replizieren und mehrere parallele Instanzen zu schaffen. Dieses finale Setting besteht aus dem ursprünglichen Webserver (RS 8000 G9.5) der durch 4x RS 1000 G9.5 für das Galera Cluster ergänz wurde. Diese 4 zusätzlichen Instanzen teilen sich auf in 1x (Galera Manager + Galera LoadBalancer) sowie 3x Nodes. Alle 5 Server sind per vLan über eth1 verbunden, Latenzzeiten sind ok.

    Beobachtung: Seitenauslieferung steigt bei Änderung des DB-Host von localhost Webserver auf lokale IP des LoadBalancers auf ca. 8 Sekunden


    3) Erster test: Load Balancer umgangen, einzelne Node per vlan-IP direkt angesprochen - keine maßgebliche Änderung. Der ausbleibende Hop über den LoadBalancer ist marginal-merklich (Auslieferungszeit sinkt von 8 auf 7,5 Sekunden) - aber grundsätzliches Problem bleibt bestehen


    4) Sämtliche bei Onkel Google gefundene MariaDB-Optimierungen auf der einzelnen Node durchgeführt - vielleicht war ich ja zu blöde die Datenbank sinnvoll zu konfigurieren. Kein maßgeblicher Effekt


    5) Jetzt besagtes Testsetting um die Ursache zu finden:

    Cluster stillgelegt, eine Node mit neuem Image ausgestattet (identisch zu Webserver, Webauftritt kopiert, DB dort ebenfalls lokal hinterlegt). Beobachtung: Direktaufruf auf beiden nun vollwertigen Webservers jeweils bei Verwendung von localhost: 2,5Sekunden - sobald ich die Server Kreuzverschalte (ergo DB-Host auf vLan-IP des anderen Servers) Sprint die Auslieferungszeit auf 7-8 Sekunden


    Ergo: Beide Datenbanken liefern flott (2,5 Sekunden bei lokaler Ansprache) - die massive Verlangsamung ist eindeutig auf den Hop von Webserver auf externen DB-Server zurückzuführen - und das trotz vLAN-Verbindung. Das vLAN-selber erschient mir in Ordnung - siehe Latenzzeiten. Dass so ein Hop zusätzliche Zeit braucht, sehe ich ein - aber Steigerung der kumulierten Zeit von 2,5 auf 8 Sekunden? Das wäre das Todesurteil für jeden remote-DB-Host...


    Meine starke Vermutung ist, dass ich ein Routing-Problem habe - ich habe nur keinen Dunst, so ich jetzt hinschauen müsste...


    Viel Grüße


    Stephan

  • Du könntest mal ein tcpdump mitschneiden und schauen ob die Anfragen direkt hintereinander auch abgeschickt werden.

    Alternativ das ganze Mal ohne VLAN über Internet machen (wer ne Datenbank ned offentlich macht der hat was zu verbergen!!!eins!!!11!elf)


    Ich könnte mir schon vorstellen dass das deutlich mehr Zeit kostet, aber ja, das erscheint mir doch etwas viel mehr.

  • Hay,


    wie aus den Beiträgen anderer hervorblitzt, bin ich der Meinung, dass hier ggf. mit Kanonen auf Spatzen geschossen wird.

    RS 8000

    Unterbau von Wordpress geschuldet und kurzfristig nicht änderbar

    Ich betreibe auch einen RS 8000. Ich habe mehrere Wordpress Instanzen laufen, teils mit einer unnötigen Anzahl von Plugins, teilweise komplex, Webserver (Apache & nginx-Proxy), MySQL alles lokal auf diesem einen Server. Ich habe nirgens, never irgendwo Wartezeiten von 2.5 Sek, außer ich sehe in der Laufzeitanalyse, dass irgendwo eine XHR-Anfrage länger auf ein externes Ergebnis wartet oder der Abhängigkeitspfad von unterschiedlichen JavaScripts einfach falsch aufgebaut ist - was z.B. durch async laden repariert werden könnte.


    Deswegen (sorry, wenn das jetzt etwas hart klingt) glaube ich nicht, dass es die Datenbank ist. Ich würde so herangehen und erst mal schauen, ob MySQL tatsächlich (lokal) auf der Console dieselben Anfragen genauso langsam beantwortet. Dann ist meist im Datenbankdesign etwas falsch und es ist häufig damit getan, einen weiteren Index zu erstellen oder bei JOINS darauf zu achten, dass sie dieselben Feldlängen und Typen haben, damit nichts implizit konvertiert werden muss.


    Oder - die SSD-Performance ist nicht optimal - gibt hier mehrere Thread dazu, dass es der falsche virtuelle Treiber sein kann oder es einfach ein Problem mit dem node gibt.


    Der RS8000 ist nämlich so gesehen sauschnell. MySQL war bei mir noch nie ein Engpass und ich habe teilweise Nutzer drauf, von denen 150-200 über 20 Minuten parallel eine Anwendung von mir nutzen, die fleißig SQL-Abfragen über API macht (wobei Webclient und der API-Server auf demselben System liegen). Ok, zugegeben, meine SQL-Anfragen sind recht durchoptimiert...


    mehrere Anwender

    Das ist jetzt genau die Frage, was ist "mehrere". 1, 10, 100, 1000, 10000? 200-300 steckt der RS 8000 ohne Maßnahmen normalerweise locker weg... natürlich kennen wir ja auch nicht Dein sonstiges Setup und wieviele Besucher Du überhaupt erwartest...


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

    2 Mal editiert, zuletzt von CmdrXay ()

    Gefällt mir 4
  • Hallo nochmal,


    ThomasChr:

    Remote-Ansprache über öffentliche IP ist ein interessanter Punkt und ich war sicher, das probiert zu haben - habe es gerade aber nochmal getan und bin verwundert:

    - Bei DB_HOST = localhost: 2,5 Sekunden

    - DB_HOST = remote vlan 192.168.0.50: 8 Sekunden,

    - DB-HOST = öffentliche IP des Remote-Servers: HOSSA - 2,8 Sekunden (0,3 mehr als Ansprache der lokalen DB - das erscheint mir plausibel)

    In der Summe bestätigt das meine Routingproblemvermutung - irgendwas läuft mit dem vlan schief...die Leistung sollte doch keinesfalls schlechter sein, die die der öffentlichen IP


    Ich habe getan:

    auf beiden Instanzen in /etc/network/interfaces hinzugefügt

    allow-hotplug eth1

    iface eth1 inet static

    address 192.168.0.10 | address 192.168.0.50

    netmask 255.255.255.0


    traceroute funktioniert ja - aber fehlt da noch irgendein Routing-Ding?


    CmdrXay:

    D'accord - absolut korrekt - eigentlich sollte der RS 8000 das alles problemlos schaffen. Das Hauptproblem ist definitiv die Zusammenstöpselung des Wordpress-Unterbaus. Es handelt sich nicht um einen Webauftritt im klassischen Sinne, sondern um ein ausgewuchertes Portal, das viele hundert Webservices für verschiedenste gewerbliche Anwender zusammenführt und auf Knopfdruck Reportings erstellt. Rückblickend war WP ganz offensichtlich die falsche Basis - aber wie immer musste alles schnell gehen und die erweiterten Funktionen kamen peu a peu. Ganz aktuell steht im Zuge der Energiekrise die Aufschaltung vieler hundert Infrastrukturkomponenten an - und muss noch in diesem Monat passieren. Da ist leider keine Zeit für Neubau und ich muss kurzfristig eine Lösung finden, wie das Ding die zusätzliche Auslastung irgendie verkraften können wird - und so kam ich zu der Idee der DB-Clusterung


    Viele Grüße

    Stephan

  • Hay,

    In der Summe bestätigt das meine Routingproblemvermutung - irgendwas läuft mit dem vlan schief...die Leistung sollte doch keinesfalls schlechter sein, die die der öffentlichen IP

    gut, wenn wir dann auf dieser Infrastruktur sind, habe ich noch zwei Gedanken:


    1 - Das CloudVLan free hat ja nur 100 MBit, während der RS8000 mit 2.5 Gbit angeschlossen ist. Das ist ein erheblicher Geschwindigkeitsunterschied und ggf. gibt es hier irgendwo einen Buffer der über- oder unterläuft - und deswegen Pakete verloren gehen, die einen Resend auslösen. Direkter Server-Kontakt per 2.5 GB, dafür öffentlich, ist keine solche Geschwindigkeitsänderung. Halte ich aber IM GENERELLEN eher für unwahrscheinlich, weil ich selbst das tägliche Backup meines RS8000 auf einen anderen VPS laufen lasse und da gingen seit einem Jahr etliche TB durch, ohne dass ich eine Störung verspürt habe. Ok, mir ist aber auch egal, wie lange das wirklich braucht, aber als ich die letzten Male gemessen habe, waren es um die 10MByte/Sek, also passt. Und es sind ja große Dateien, nicht viele kleine Datenfragmente durch die SQL-Abfragen. Trotzdem ist es für mich einen Gedanken wert.


    2 - Man könnte ja eine Zwischenlösung zwischen dem VLan und der öffentlichen IP gehen - über ein eigenes kleines VPN per Software. Der Transfer zählt natürlich zum Trafficverbrauch, also nicht unbedingt ideal, wenn da wirklich viele Abfragen drüberlaufen. Aber den VLan Traffic kann man noch komprimieren (mein OpenVPN macht das), dadurch tauschst Du Bandbreite und Latenz gegen CPU-Last, gewinnst aber die 2.5 GBit zurück und ggf. besteht die Ungewissheit wegen oben 1 auch nicht mehr.


    CU, Peter.

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

    2 Mal editiert, zuletzt von CmdrXay ()

  • Hallo und danke nochmal,


    ich glaube der erste Gedanke ist der Schlüssel zu Lösung - habe nochmal direkt in der Konsole gespielt:


    Ausgangsvoraussetzung:

    vLAN steht, traceroute liefert vertretbare Latenzzeiten


    Konfiguration:

    Webserver in /etc/network/interfaces

    allow-hotplug eth1

    iface eth1 inet static

    address 192.168.0.10

    netmask 255.255.255.0


    ifconfig eht1 liefert:

    eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

    inet 192.168.0.10 netmask 255.255.255.0 broadcast 192.168.0.255

    inet6 fe80::4858:a7ff:fea9:5b30 prefixlen 64 scopeid 0x20<link>

    ether 4a:58:a7:a9:5b:30 txqueuelen 1000 (Ethernet)

    RX packets 537483 bytes 2417065579 (2.2 GiB)

    RX errors 0 dropped 0 overruns 0 frame 0

    TX packets 455848 bytes 44846860 (42.7 MiB)

    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


    traceroute to 192.168.0.50 (192.168.0.50), 30 hops max, 60 byte packets

    1 192.168.0.50 (192.168.0.50) 0.467 ms 0.471 ms 0.477 ms


    traceroute to 89.58.43.188 (89.58.43.188), 30 hops max, 60 byte packets

    1 202.61.196.2 (202.61.196.2) 0.188 ms 0.166 ms 0.159 ms

    2 v220220934316199850.luckysrv.de (89.58.43.188) 0.287 ms 0.280 ms 0.286 ms


    192.168.0.10 ist der Nginx, 192.168.0.50 (extern 89.58.43.188) ist die DB


    Abfragen auf der Mysql-Konsole des Webservers:


    a) gegen private vLan-IP des DB-Servers

    mysql -u root -p -h192.168.0.50 dbname

    SELECT * FROM wp_postmeta;

    104953 rows in set (1 min 20.49 sec)


    b) gegen öffentliche IP des DB-Servers

    mysql -u root -p -h89.58.43.188dbname

    SELECT * FROM wp_postmeta;

    104953 rows in set (3.33 sec)


    ahh.... sollte tatsächlich die Bandbreite des vLAN ein Problem sein?

    Rein rechnerisch ergibt sich etwas Passendes:

    1min 20 = 80,49 Sekunden versus 3,33 Sekunden

    ==> auf öffentlicher IP wird mit 2,5GB gesendet, im privaten vLAN mit 100MB --> Faktor 25

    80,49 / 25 = 3,2... das passt verblüffend genau...


    Limitiert hier wohl tatsächlich die Bandbreite des vLAN?

    Ich werde das vLAN jetzt mal testweise auf 2,5GB upgraden und schauen was passiert


    Viele Grüße


    Stephan

  • Ohne jetzt wirklich ein Netzwerkexperte zu sein würde ich vermuten, das das Routing zwischen den beiden Servern gleich ist, egal ob VLAN oder öffentliche IP. Kann mir nicht vorstellen, dass die öffentliche IP über Frankfurt geroutet wird, wenn es auch eine interne Leitung gibt ;) . Kostet ja sonst auch mehr für netcup. Bliebe als Unterschied fast nur noch die Geschwindigkeit der jeweiligen Anbindung, die ist jedenfalls zugunsten der öffentlichen IP. Ob es dann auch noch eine Priorisierung gibt weiss ich nicht. Falls ja, wird sie wohl kaum zugunsten des kostenlosen VLAN sein, zumal ja in der Produktbeschreibung wohlweislich "Maximale Bandbreite im VLAN: 100 MBit/s" drinsteht. Gut, da sind über die öffentliche IP auch keine 2,5 GBit/s garantiert, aber mehr als 100 MBit/s wird da wohl schon allemal drübergehen.

  • Ja, seh ich ähnlich. Glaube kaum dass Daten für die öffentliche IP auch wirklich das Rechenzentrum verlassen.

    Also bringt das vLAN eigentlich keinen wirklichen Vorteil, außer dass man halt ein bisschen anders konfigurieren kann.

    Wenn du aber über die öffentliche IP gehst und in der Firewall des DB-Servers dafür sorgst dass nur die IPs deiner Website drankommen solltest du ziemlich genauso sicher sein wie mit vLAN.

  • Moin,


    betreibe ebenfalls ein MySQL cluster im gratis VLAN (allerdings via Percona XtraDB und nicht MariaDB, allerdings mit sehr geringer Nutzung (drei Oster-RS, irgendwas musste ich damit ja anfangen). Interessant wäre es mal ohne Load Balancer zu versuchen. Weiters, wenn etwas extra Geld nicht das Problem ist, und ihr "viele" gleichzeitige Abfragen habt, würde ich empfehlen das MySQL Backend (den Cluster Traffic) auf ein separates VLAN (empfohlen ist mindestens 1Gb/s) zu legen als den Frontend Traffic (zum Load Balancer und weiter).

  • so - um die Geschichte abzuschließen: That was it!

    Es war tatsächlich die blöde vLAN-Bandbreite, die den Remote-Server so ausgebremst hat.

    Nach Hochbuchung auf 2,5GB lieferte die Abfrage gegen vLAN-IP per Konsole 104953 rows in set (3.25 sec) - zuvor: 1min 20s


    Habe den Load-Balancer / GaleraCluster reaktiviert und erhalte hier nun Auslieferungszeiten der Seite von ca. 2,8s - absolut vergleichbar mit den Zeiten des localhost.


    Bedeutet:

    Das Galera Cluster / Load Balancer liefert im Bezug auf den Einzelzugriff im Testbetrieb gegenüber dem lokalen Hosting keinen fühlbaren Vorteil (was mich etwas überrascht, da die WP-Seite aus einer Vielzahl gleichzeitiger ajax-Requests besteht, die per LB eigentlich unterschiedlich geroutet werden müssten, der LB steht auf round-robin). Der Vorteil wird sich aber mutmaßlich offenbaren, wenn mehrere User gleichzeitig zugreifen - Verteilung der Last - und die Ausfallsicherheit der ganzen Geschichte ist auf jeden Fall ein Pfund.


    Danke an alle für die Unterstützung!

  • Hay,


    ach, ich grinse gerade. Freut mich, dass es sich jetzt so verhält wie man es erwartet....


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.