Server Umzug


#1

Aktuell bereiten wir den Umzug auf einen neuen Server vor damit das Forum in Zukunft besser, schneller und stabiler läuft.
Es sollte dabei eigentlich zu keinen Störungen kommen, aber jeder weiß wie es so abläuft, das ist eigentlich nie wie man es plant :wink:

Das Forum wird als letztes Umziehen um die Probleme so gering wie möglich zu halten, aber wenn es soweit ist werden wir dies noch einmal ankündigen.


#2

Heute Abend kann es zu Ausfällen des Forums kommen, da der Umzug ansteht.


#3

Ahoi,

@EagleEye

um den Timeout durch die DNS-Aktualisierung totzuschlagen - folgendes für alten Server:

ssh -g -L 443:eportal.reinhausen.com:443 localhost

wirkt “Wunder”

anpassen nicht vergessen, mogel


#4

hehe ok :smiley:

*** Edit ***

so der Umzug ist durch, ich hoffe dass alles noch so läuft wie gehabt

*** Edit ***

ok gab noch kleine Bugs, aber jetzt geht auch der Login wieder


#5

Im Zuge des Umzugs habe ich jetzt große Teile (hoffentlich bald alles) auf HTTPS umgestellt, solltet ihr damit Probleme haben
Meldet euch


#6

Es wird anscheinend noch verszcht Javascripte über HTTP zu laden, dadurch funktioniert bei mir Chrome z.b. das zitieren aktuell nicht.


#7

@Lumaraf ja so ist es auch mit dem Editor, ich bin dabei mich durch den Code zu wühlen und das zu beheben

*** Edit ***

so zitieren und Editor gehen wieder :slight_smile:

wenn euch noch was auffällt sagt bescheid


#8

[QUOTE=EagleEye]@Lumaraf ja so ist es auch mit dem Editor, ich bin dabei mich durch den Code zu wühlen und das zu beheben

*** Edit ***

so zitieren und Editor gehen wieder :slight_smile:

wenn euch noch was auffällt sagt bescheid[/QUOTE]

Gute Arbeit. Ich kann aktuell keine weiteren Fehler feststellen.


#9

Hmm, trotz Server-Umzug ist leider immer noch eine recht hohe Latenz, gerade beim ersten Laden der Seite je Session, spürbar. Ob der allgemeine Load sich durch SSL verschlimmert hat oder einfach andere Ursachen vorhanden sind (scheint mir fast so, vielleicht ist es einfach die Foren-Software + spezifische PHP-Impl + Datenbank) wird sich zeigen.


#10

Wie ist es mit der Performance, ist es schlechter geworden oder gleich?
Ist es eine Zeitabhängige Sache?

Bei mir läuft es eigentlich immer gut oder ich weiß dass es ein lokales Problem bei mir ist.


#11

gibt es im Jahr 2016 nicht (kostenlose, problemlose, einfache) Tools für Server,
die sowas eindeutig für alle Request aller User zu allen Uhrzeiten genau klären könnten, Statisiken, Ausreißer, Zeitverhalten? :wink:
mögliches ohne Einbindung Server großer amerikanischer Firmen…


#12

naja Slater dazu muss man es erst einmal eingrenzen wo man sucht und glaub mir einfach geht keins von denen :wink:

Wenn du aufm Server bist weiß ich fast alles, aber damit weiß ich nicht ob es besser oder schlechter geworden ist.


#13

die Kontrolle des Ablaufs auf dem Server, etwa Zeitmessung je Request vom Anfang ‘ich weiß da will was wer’
bis zum Ende ‘Post abgeschichkt und ich geh nun wieder in Ruhezustand’ wäre ein wichtiger Schritt,
vielleicht der einzige automatisch prüfbare,
viel einzugrenzen/ auszuwählen sehe ich da nicht mit unbedarften Blick von außen

wenn du für dich selber Zeiten von x ms hast und das als ok im Browser siehts und bei anderen meist dieselben Zeiten,
dann wäre das eine gewonnene Erkenntnis statt im Moment vielleicht kein genaueres Wissen darüber?


wieviel KB werden eigentlich versendet, etwa mit den ganzen JavaScript doch sicher ne ganze Menge,
bei jedem Request oder nur beim ersten je Session und deshalb langsamer, danach lokaler Cache?
alles immer gleich vorhersagbar oder Frage ob Cache je User funktioniert/ aktiviert ist und dann auch nachzumessen was aktuell passiert?


wenn von früher keine Statistiken, dann Vergleich schlecht möglich, ja, nach deiner Steilvorlage zu dieser bösen Bemerkung :wink:
kann man nun nix bei machen,
evtl. mit/ ohne SSL testen

und bei mir im Browser sehe ich teils schon die Seite und noch Lade-Animation, irgendwas wird vielleicht noch vom Server nachgeladen, Bilder usw.,
sind das mehrere einzelne Requests zum Server,
können Tools diese gemeinsam erfassen und vielleicht die Zeit von Auslieferung des HTML bis zum Nachladen der Bilder & Co. vom Browser auch auswerten?

Disclaimer: alles nur objektive Anmerkungen zur evtl. Anregung,
nie irgendwo Kritik, Aufforderung zur Arbeit und wer weiß was alles herauslesen… :wink:


#14

Alle(?) aktuellen Browser stellen btw unter window.performance.timing eine ganze Reihe von Messwerten zu Ladezeit und Rendering bereit. Anhand von den Zahlen kann man leicht automatisiert auswerten wo es bei den meisten Besuchern hängt.

Nach einem kurzen Blick in die Chrome-Devtools würde ich spontan vermuten das die meiste Zeit bei der Verarbeitung in PHP/MySQL verloren geht.


#15

Moin,

subjektiv ist es bei mir besser geworden. Ich weiß aber auch nicht wo bei einem PHP Forum das Optimum liegt. Jetzt gerade sieht es so aus (kein Cache, neue Verbindung):

Durch https wird der Seitenaufbau auch schneller, da dadurch erst http/2 ermöglicht wird. Byte-Welt unterstützt http/2 (danke dafür!). Siehe: https://www.httpvshttps.com/
Aber nicht alle Webbrowser können das Ausnutzen. (Edge imho nicht.)

Gruß
Fancy


#16

[QUOTE=Lumaraf]Alle(?) aktuellen Browser stellen btw unter window.performance.timing eine ganze Reihe von Messwerten zu Ladezeit und Rendering bereit. Anhand von den Zahlen kann man leicht automatisiert auswerten wo es bei den meisten Besuchern hängt.

Nach einem kurzen Blick in die Chrome-Devtools würde ich spontan vermuten das die meiste Zeit bei der Verarbeitung in PHP/MySQL verloren geht.[/QUOTE]

Ja hier ists bisschen komplizierter, wir hatten auf dem alten Server einige Probleme. Ich hoffe dass wir sie nicht mit umgezogen haben haben.
Aber es gibt auch andere, so ist z.B. bekannt dass Hetzner das Peering mit Telekom nicht soooo schön hat, wodurch es gerade in den Abendstunden zu langsameren Geschwindigkeiten kommen kann.
Daher auch erst einmal die Frage obs im Vergleich zu früher besser oder schlechter geworden ist. Weil wenn wir jetzt doch in das Problem mit dem Peering laufen müssen wir wohl das andere Paket noch buchen.

*** Edit ***

Achja, nicht dass ihr denkt ich weiche den Aussagen zur Überwachung aus :wink:
in den letzten 24h hat die längste Anfrage 158ms gedauert und wir hatten 28 Requests die länger als 30ms gebraucht haben, rein von der Verarbeitung im Server


#17

Hmm, ok, wenn das request-processing auf dem Server im ms-Bereich mit peak bei 150ms liegt - dann haut bei mir wohl was auf dem Weg nicht hin. Oder es ist einfach mein IE11 der die Ursavhe ist.
Ich konnte bisher noch keinen guten Vergleich zwischen Handy über LTE und PC machen da mein IE11 ganz anders eingestellt ist als der Chrome auf meinem Z5. Müsste mal Laufzeitanalysen mit Wireshark probieren.


#18

naja du musst bedenken dass hier kein Verbindungsaufbau/-abbau beeinhaltet ist, das nimmt teilweise auch viel Zeit in Anspruch. Das ist halt nur die reine Zeit im Server


#19

Ich habe auch Probleme - allerdings liegt es da an den Telekomikern. Seiten werden nicht nur von Byte Welt langsam aufgebaut. Aber auch nicht immer, meistens Abends.


#20

Für mich persönlich ist es schnell genug, deshalb das bitte nicht als Beschwerde auffassen. Mich würde nur schon interessieren wo die Zeit liegenbleibt. Vergleiche ich z.B. (jeweils nur die Zeiten für die HTML Datei):

https://www.mikrocontroller.net/forum/mikrocontroller-elektronik

traceroute to www.mikrocontroller.net (188.40.52.210), 30 hops max, 60 byte packets
 1  router.home (10.0.0.1)  21.702 ms  21.828 ms  21.823 ms
 2  dslb-blub.pools.vodafone-ip.de (blub)  39.437 ms  49.071 ms  50.948 ms
 3  * * *
 4  188.111.171.216 (188.111.171.216)  51.773 ms 188.111.171.220 (188.111.171.220)  60.109 ms  61.107 ms
 5  92.79.212.193 (92.79.212.193)  62.505 ms 92.79.212.201 (92.79.212.201)  63.905 ms 92.79.212.193 (92.79.212.193)  69.872 ms
 6  92.79.213.170 (92.79.213.170)  70.809 ms 188.111.129.26 (188.111.129.26)  51.230 ms  52.180 ms
 7  amsix-gw.hetzner.de (80.249.209.55)  53.544 ms  40.671 ms decix2-gw.hetzner.de (80.81.193.164)  39.653 ms
 8  core22.hetzner.de (213.239.245.17)  41.165 ms  48.102 ms core1.hetzner.de (213.239.203.157)  40.802 ms
 9  juniper1.rz10.hetzner.de (213.239.245.42)  41.239 ms  41.196 ms juniper2.rz10.hetzner.de (213.239.245.46)  46.284 ms
10  juniper2.rz10.hetzner.de (213.239.245.46)  42.602 ms hos-tr1.ex3k3.rz10.hetzner.de (213.239.227.132)  40.320 ms hos-tr3.ex3k3.rz10.hetzner.de (213.239.227.196)  40.211 ms

mit: https://forum.byte-welt.net/java-forum/allgemeine-themen/

traceroute to forum.byte-welt.net (138.201.7.220), 30 hops max, 60 byte packets
 1  router.home (10.0.0.1)  21.779 ms  21.925 ms  21.918 ms
 2  dslb-blub.pools.vodafone-ip.de (blub)  39.521 ms  49.401 ms  51.366 ms
 3  * * *
 4  * 188.111.171.216 (188.111.171.216)  59.822 ms  60.843 ms
 5  92.79.212.201 (92.79.212.201)  62.205 ms 92.79.212.193 (92.79.212.193)  63.634 ms  69.994 ms
 6  188.111.129.26 (188.111.129.26)  72.408 ms  45.508 ms  51.354 ms
 7  decix2-gw.hetzner.de (80.81.193.164)  42.692 ms amsix-gw.hetzner.de (80.249.209.55)  39.835 ms decix2-gw.hetzner.de (80.81.193.164)  38.856 ms
 8  core24.hetzner.de (213.239.203.150)  40.116 ms core1.hetzner.de (213.239.203.157)  39.646 ms core24.hetzner.de (213.239.203.150)  39.612 ms
 9  core23.hetzner.de (213.239.203.154)  48.281 ms ex9k1.rz17.hetzner.de (213.239.203.234)  45.815 ms core23.hetzner.de (213.239.203.154)  41.869 ms
10  ex9k1.rz17.hetzner.de (213.239.203.230)  48.299 ms * *

Beide Seiten sind bei Hetzner und beide verwenden SSL.

Wenn die Verarbeitungszeit hier nur ~150ms dauert, was passiert dann in den >500ms (680 - 150) in denen der Browser einfach nur wartet? Und warum tritt das in dem anderen Forum so nicht auf?

Aber wie bereits geschrieben, reines Interesse, keine Beschwerde.

Gruß
Fancy