Beiträge von seaac

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!

bring mir bitte welche mit ;-))) sorry

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

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

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

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