Nein, da muss der Host oder die IP des Datenbankservers rein.
Die DB liegt nicht auf dem gleichen Server, wie das Hosting selbst.
Die Daten findest du im CCP
Beiträge von aRaphael
-
-
Als Output erscheint allerdings, wie du sagst, nur error. Dazu müsste man nun in den Webserver-Logs nachschauen was ihm da nicht schmeckt.
Bei joomla erscheint dieses nichtssagende "error" meist dann, wenn die Zugangsdaten in der configuration.php nicht stimmen.
Beliebter Fehler: Bei $host ist noch "localhost" eingetragen. Das funktioniert auf dem Webhosting nicht mehr.
-
Wenn schon dann 1.21gigawatt.energy
Aber 9€ pro Monat isses mir dann doch nicht wert.
-
Ja, aber da kann man die subdomain 1.21gigawatt nicht einrichten.
-
"Deine Wunschdomain ist leider belegt" 21gigawatt.de
-
Interessant. Ich hab von meinem G8 und G9 Server einen Test gegen den iperf3 Server von WilhelmTel gemacht. Der kann beide Server auslasten. Der kann beide Server auslasten. Es gibt zwar ein paar Retransmissions, aber die sind locker um Faktor 20 kleiner, als in der direkten Verbindung der beiden RS.
Muss ich auch mal testen.
EDIT: Ja, kann ich so bestätigen. In beide Richtungen keine nennenswerten Retrs (Hmm. Was ist da anders?)
iperf versucht im TCP Modus natürlich, die Leitung möglichst auszureizen. Das heißt eben, die Leitung wird geflutet, bis es zu Paketverlusten kommt und die TCP Congestion Control Algorithmen zuschlagen.
Ja, was man auch daran sieht, dass im gleichen Maße, wie die Retransmissions (retr) ansteigen, das Congestion Window (cwnd) kleiner wird.
Wenn man dann die Transferrate mit -b limitiert, sind die wieder größer.
(Aber irgendwie hätte ich trotzdem erwartet, dass es die Engpässen in Richtung vom Sever mit der besser Anbindung zu dem mit der geringeren gibt und nicht umgekehrt)
-
Ist wie beim Versandhandel, wenn ein Paket wegen Überlastung des Zustellers oder aufgrund Unzustellbarkeit zurück zum Absender geht oder ganz verloren.
In diesem Fall (Performancetest mit iperf3) ist es aber wohl eher kein Problem, sondern zeigt nur an, dass die Grenze ausgereizt wurde. (So meine Vermutung)
Erst wenn hier die Retransmissions auch bei geringeren Übertragungsraten auftreten würden, müsste man sich wohl Sorgen machen.
Mich hatte hier im Wesentlichen interessiert, wie ich diese Ausgaben von iperf3 zu interpretieren habe.
-
Hab das Ganze jetzt mal ausprobiert zwischen Netcup G9 root zu einem Server, den ich bei einem anderen Provider habe und der mehr als die 2.5 GBit/s kann. (Nennen wir ihn mal "HC"
)Da zeigt sich der gleiche Effekt.
HC -> RS G9 - Keine Retr.
RS G9 -> HC - Viele Retr.
Wenn ich die Transferrate dann aber mit -b runterschraube, sind die Retransmissions bei ca. 2.25 Mbit/s weg
-
Erster Verdacht: Es betrifft den Upload des G8 Servers, da der am Limit ist.
Ja, sowas in der Art vermute ich auch.
iperf3 läuft ja an beiden Enden und kann somit leicht feststellen, wie schnell der Empfänger die Daten annehmen kann.
Dann wird halt versucht soviel wie möglich rauszuhauen und das Limit auszureizen.
...oder so ähnlich
-
Glaube nicht. Nur wenn man noch die Option -u hinzufügt.
Es nur so, dass iperf3 die Bitrate für UDP schon per Default auf 1 MBit/s beschränkt, für TCP ist sie unbeschränkt
Code... -u, --udp use UDP rather than TCP ... -b, --bitrate target bitrate in bits/sec (0 for unlimited) (default 1 Mbit/sec for UDP, unlimited for TCP) -
Aha.
Wenn ich die Bitrate auf knapp unter das Maximum dessen setze, was die VPS können, verschwinden die Retransmissions:
Ohne Beschränkung:
Code[ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 122 MBytes 1.02 Gbits/sec 6353 19.8 KBytes [ 5] 1.00-2.00 sec 117 MBytes 985 Mbits/sec 5771 19.8 KBytes [ 5] 2.00-3.00 sec 117 MBytes 984 Mbits/sec 6724 21.2 KBytes [ 5] 3.00-4.00 sec 116 MBytes 977 Mbits/sec 5305 28.3 KBytes ...Mit -b 950MB:
Code[ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 113 MBytes 950 Mbits/sec 1 130 KBytes [ 5] 1.00-2.00 sec 113 MBytes 950 Mbits/sec 1 144 KBytes [ 5] 2.00-3.00 sec 113 MBytes 950 Mbits/sec 0 144 KBytes [ 5] 3.00-4.00 sec 113 MBytes 950 Mbits/sec 0 144 KBytes ...Zwischen den beiden VPS gab es keine Probleme, weil beide eh nur maximal 1 Gbit/s schaffen.
Der RS könnte aber 2,5 Gbit/s.
Ohne Beschränkung testet iperf3 halt aus, was geht.
Allerdings hätte ich den Stau eher in die umgekehrte Richtung erwartet. (Vom RS zum VPS)
-
Hier ist ja das Thema Retransmissions und Bandbreitenverlust durch einen Tunnel angesprochen worden:
https://forum.netcup.de/admini…em-was-ist-hier-passiert/
Ich will den Thread von mainziman nicht kapern, denn mir geht es nur um die Retransmissions, die iperf3 ausgibt.
Ich habe das mit drei meiner Server getestet und festgestellt, dass sich das nur in eine Richtung und zu einem Server zeigt (egal ob iperf3 als Server oder Client agiert)
Nur zum Rootserver hin werden mir sehr viele Retransmissions angezeigt:
Code[ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 120 MBytes 1.01 Gbits/sec 6087 25.5 KBytes [ 5] 1.00-2.00 sec 115 MBytes 966 Mbits/sec 5446 15.6 KBytes [ 5] 2.00-3.00 sec 117 MBytes 981 Mbits/sec 5209 15.6 KBytes [ 5] 3.00-4.00 sec 117 MBytes 981 Mbits/sec 6838 28.3 KBytes ...Vom Rootserver weg und zwischen den beiden anderen Servern ist es OK
Bandbreitenverluste habe ich dabei allerdings keine, wie man sieht. Und die Netzwerkanbindung des RS läuft ansonsten auch völlig problemlos
Nun stellen sich mir die Fragen:
- Was könnte die Ursache sein? (Wie könnte man das rausfinden?)
- Sollte ich mir darüber überhaupt Gedanken machen, oder es komplett ignorieren? (Weil kein Verlust)
- Wie lautet die Antwort auf die Frage aller Fragen, nach dem Leben, dem Universum und dem ganzen Rest?
(Verbindung zu Servern anderer Provider habe ich noch nicht getestet)
-
OK. Ist bei mir ähnlich, wobei Serverseitig dann sowieso nur eine abschließende Zeile angezeigt wird. Wahrscheinlich eine etwas andere iperf3-Version
Dabei habe ich festgestellt:
Client -> Server: So gut wie keine Retransmissions
Server -> Client (-R): Haufenweise!
Dann habe ich die Rollen getauscht und, siehe da es war umgekehrt, lag also nicht an -R, sondern an den Servern.
Server A (RS G9) -> Server B (VPS G8): Perfekt
Server B -> Server A: Sehr viele Retransmissions
(Firewall war auf beiden Servern ausgeschaltet.
Kein Unterschied zwischen ipv4 und ipv6)
Gefällt mir zwar nicht, allerdings bleibt die Bandbreite davon weitgehend unberührt hoch. (Bisserl sinkt sie aber schon)
Insofern schließe ich mich da an:
Ich fürchte bei den Retransmissions suchen wir an der falschen Stelle. Bei den Tunnelversuchen weiter oben treten sie nicht in signifikanter Anzahl auf, und bei den direkten vServer Verbindnungen schränken sie die Bandbreite nicht dramatisch ein.
Ich sag's ja immer: Zu viel Monitoring und Benchmark ist ungesund.
Man sieht dann Dinge, die man sonst nie bemerkt und über die man sich nie Gedanken gemacht hätte.
-
Ich habe hier jeweils die Ausgabe auf der iperf3-Serverseite ausgegeben; am Client zeigt er mir z.B. sowas an:
Code[ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 592 MBytes 496 Mbits/sec 1883 sender [ 4] 0.00-10.00 sec 591 MBytes 496 Mbits/sec receiverAh. OK. Ich habe mir das immer auf Clientseite angesehen. Evtl. sieht das bei mir ja auf Serverseite genauso aus wie bei dir und es ist normal.
-
Das ist schon klar. Aber iperf3 gibt ja normalerweise in der letzten Zeile auch an, wie viel angekommen ist. (Bei beiden Richtungen)
Wenn du das mit den Ausgaben von frank_m und mir vergleichst, sieht man den Unterschied.
Oder täusche ich mich da? (Kann gut sein. Bin kein iperf3-Experte)
-
Hmmm....
Deinen Screenshots zufolge kommt da doch eigentlich überhaupt nix an. (Letzte Zeile 'receiver')
-
Und die Netcup-Variante;
-
ich hatte soeben einen 6in4-Tunnel zwischen 2 vServern hier gemacht...
... da werd ich aber kaum was ändern können - das war zwischen 2 vServern
Ist das denn ohne den Tunnel tatsächlich genauso schlecht?
-
Hab eben auch mal interesshalber iperf3 zwischen zwei meiner netcup-Server laufen lassen (ohne Tunnel!).
Praktisch keine retransmissions (weder bei ip4 noch ip6)
Code
Alles anzeigen[ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 117 MBytes 980 Mbits/sec 3 372 KBytes [ 5] 1.00-2.00 sec 115 MBytes 966 Mbits/sec 1 556 KBytes [ 5] 2.00-3.00 sec 115 MBytes 966 Mbits/sec 0 696 KBytes [ 5] 3.00-4.00 sec 114 MBytes 954 Mbits/sec 0 814 KBytes [ 5] 4.00-5.00 sec 114 MBytes 954 Mbits/sec 0 916 KBytes [ 5] 5.00-6.00 sec 114 MBytes 954 Mbits/sec 0 1007 KBytes [ 5] 6.00-7.00 sec 114 MBytes 954 Mbits/sec 0 1.07 MBytes [ 5] 7.00-8.00 sec 115 MBytes 965 Mbits/sec 0 1.14 MBytes [ 5] 8.00-9.00 sec 114 MBytes 954 Mbits/sec 0 1.21 MBytes [ 5] 9.00-10.00 sec 114 MBytes 954 Mbits/sec 0 1.28 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.12 GBytes 960 Mbits/sec 4 sender [ 5] 0.00-10.00 sec 1.11 GBytes 958 Mbits/sec receiverNicht dass dir das was nützen würde
ist ja kein 6in4, aber es zeigt zumindest, dass retries in diesem Ausmaße nicht vorkommen sollten. -
...das Imperiale Maß - sprich die einzelnen Stifte sind 2,54mm von einander entfernt.
Ist aber eigentlich inkonsequent, wenn die das so machen.
Ein Inch/Zoll sind ja 2,54 cm. und ein Fuß 12 Inch.
Da müsste man dann ja 2,54 cm / 12 nehmen und nicht 2,54 cm / 10
Es gibt wohl also "echt imperiale" Hohlstecker (2,1) und angebiederte. (2.5)
