In Vorbereitung auf Das Boot 3.0

[Emploi]

Darade habe ich gedacht, den Faden könnteste lesen, dann ging er auf und jetzt habe ich erst geklickt.

 

[Supi]

Ja, wir sind schon umgezogen
http://www.planet3dnow.de/vbulletin...Planet-3DNow!-Server-Alle-Infos-und-Puls-LIVE!

Der "Puls" spricht noch von MySQL, aber laut Übersicht seit ihr doch auf MariaDB umgezogen? (Kleinigkeiten...)

 

[Nero24]

Der "Puls" spricht noch von MySQL, aber laut Übersicht seit ihr doch auf MariaDB umgezogen? (Kleinigkeiten...)

MariaDB ist ja ein MySQL-Fork; also im Grunde dasselbe in Grün. Daher wird da kein Unterschied gemacht.

 

[LordNord]

Die Temps scheinen alle ein wenig niedriger zu sein als beim alten Boot, dass ist doch schon mal klasse.

 

[Blutengel]

wie sehen die Temperaturen aus

 

[LordNord]

na hier unter Temps pro Tag kann man es gut vergleichen...

 

[Blutengel]

na hier unter Temps pro Tag kann man es gut vergleichen...

hat sich einiges getan

 

[Nero24]

hat sich einiges getan

Wobei das, was man da sieht, nicht Boot 2 vs. Boot 3 ist, sondern Boot 3 @home vs. Boot 3 @RZ. Die Diagramme für das alte Boot sind live nicht mehr einsehbar.

 

[MagicEye04]

Kann man dieses Munin auch als Anfänger leicht einrichten? Sowas wie eine Überwachung der Temperaturen etc. fehlt mir in Ubuntu noch. In Windows hatte ich immer Webtemp, was leider nicht mehr weiterentwickelt wird und in Linux schon gar nicht verfügbar ist.

 

[tomturbo]

Kann man dieses Munin auch als Anfänger leicht einrichten? Sowas wie eine Überwachung der Temperaturen etc. fehlt mir in Ubuntu noch. In Windows hatte ich immer Webtemp, was leider nicht mehr weiterentwickelt wird und in Linux schon gar nicht verfügbar ist.

Leicht ist relativ. Ein wenig muss man sich damit beschäftigen, es gibt aber viele Anleitungen dazu.
In Ubuntu braucht man es nur installieren und einige Dinge, die er bei der Installation findet, baut der Installationsprozess gleich ein.
Den Rest an sog. plugins muss man selbst nur aktivieren indem man von /etc/munin/plugins auf das jeweilige gewollte plugin in /usr/share/munin/plugins/ verlinkt.

Jedes Plugin kann man ausprobieren und sehen welche Werte es zurückliefert.
Oder ob man die Konfiguration anpassen muss, wenn man z.B. nur bestimmte Festplatten oder Temperaturen anzeigen möchte oder einen bestimmten Benutzer zum Abfragen braucht etc.

 

[MagicEye04]

Danke, dann schau ich mir das mal an.

 

[TAL9000]

Sehe ich richtig das die CPU Frequenz fest auf 2,4GHz seit heute Mittag steht?
https://www.planet3dnow.de/munin/im.meer/dasboot3.im.meer/cpuspeed-day.png

Die CMS Ladezeit ist ja dadurch etwas besser geworden, aber so richtig viel hat es ja nicht gebracht.
https://www.planet3dnow.de/munin/im.meer/dasboot3.im.meer/http_loadtime-day.png

Was mittlerweile Munin alles zum Boot3.0 zeigt ist schon interessant anzuschauen (12GB aus /data um 09:00 gelöscht)

Kommt vielleicht noch ein Artikel oder Blogbeitrag in der Richtung "Wir bauen/konfigurieren einen neuen Forumsserver: Von der Theorie (Ideen/Konzept/Planung) zur Realität (Beschaffung/Zusammenbau/Konfiguration)", natürlich erst wenn soweit alles läuft und dicht ist

Würde mich als 0815 User schon interessieren was da sich ein Admin für Gedanken macht...

 

[Nero24]

Sehe ich richtig das die CPU Frequenz fest auf 2,4GHz seit heute Mittag steht?
https://www.planet3dnow.de/munin/im.meer/dasboot3.im.meer/cpuspeed-day.png

Ja, wir wollten ausprobieren, ob es einen Einfluss auf die Ladezeit hat wenn die CPU nicht erst hochtakten muss. Im Grunde das, was der Ryzen Energiesparplan unter Windows auch macht. Hat ein bißchen was gebracht.

Die CMS Ladezeit ist ja dadurch etwas besser geworden, aber so richtig viel hat es ja nicht gebracht.
https://www.planet3dnow.de/munin/im.meer/dasboot3.im.meer/http_loadtime-day.png

Wir wissen warum die Ladezeiten des CMS gegenüber dem Forum so schlecht sind. Es liegt an drei Plugins, wie TiKu rausgefunden hat. Wenn wir die deaktivieren, sinkt die Latenz auf 1/3 Es gilt jetzt eine Lösung zu finden, dass die Plugins nicht bei jedem Ladevorgang ausgeführt werden. Der Basteldrang ist geweckt

 

[BoMbY]

Aber ehrlich: Da muss eigentlich noch deutlich mehr gehen. Normalerweise sollten die Antwortzeiten von so einer PHP-Seite auf dem Server unter 100ms liegen, ansonsten ist da irgendwas zu langsam ...

 

[Riddler82]

Diese pauschale Aussage mit 100ms halte ich absolut für nicht haltbar.

 

[BoMbY]

Ja, eigentlich müssten es weniger als 50ms sein. Ernsthaft, ich bin sicher das man das hinbekommen kann mit <100ms - dafür gibt es aber 1000 Dinge die man prüfen und ggfls. optimieren muss.

Das fängt damit an wirklich sicher zu stellen, dass der Apache2 keine Reverse-DNS-Abfragen macht, und das da keine Mods irgendwelchen Ärger machen, dann sicher gehen dass z.B. ein PHP OPCache ordentlich läuft und die Verbindung mit Apache2 ordentlich geht. Weiter beim SQL-Server die Cache-Statistiken auswerten und da ggfls. anpassen, dann SQL-Statements profilen und sehen das alle ordentliche Indizes nutzen, eventuell auch von TCP/IP auf Unix Socket Verbindung zwischen PHP und SQL wechseln. Dann vielleicht noch sehen den Apache durch nginx Reverse-Proxy zu entlasten (kann man auch erstmal testen mit vertauschten Ports, dann stört es den Live-Betrieb nicht), und dann mal schauen wo man raus kommt.

Edit: Ebenso sicher stellen dass SSL/TLS AES-NI nutzt nach Möglichkeit.

Edit2: Ebenso WordPress Super Cache, oder vergleichbares, zur Erzeugung von statischen HTML-Seiten nutzen

 

[TiKu]

Das ganze muss auch wartbar bleiben. Mit Custom Indizes in einer Standardwebanwendung habe ich z.B. schon ein paar Bauchschmerzen, da ich beruflich die Erfahrung gemacht habe, dass das bei Updates zu Problemen führen kann.
Einige Gründe für suboptimale Performance sind uns bekannt, die nötigen Änderungen entstehen aber nicht von selbst.

 

[tomturbo]

Bomby:
- HostnameLookups sind natürlich off
- der opcache läuft und tut natürlich funktionieren, wir haben immer schon php caching gehabt von eaccelerator über apc bis jetzt opcache
- die SQL-Verbindungen verwenden connection pooling und werden dadurch nicht dauernd ab- und aufgebaut
- daher ist praktisch kein Unterschied zwischen Socket und TCP/IP bei SQL-Verbindungen
- Reverseproxy ist eine Möglichkeit kommt aber sicher ganz am Schluß aller Möglichkeiten, denn er bringt nur bei statischem Inhalt wirklich etwas, der nicht allzu groß hier ist
- WP SuperCache ist denkbar muss man sich anschauen

 

[BoMbY]

Unix Socket vs. TCP/IP über Loopback Device spart auf jeden Fall etwas an TCP/IP overhead und wird IMHO empfohlen, auch wenn es vielleicht bei der effektiven Leistung nichts messbares bringt.

Was die statischen Inhalte angeht hatte ich ja früher schon angemerkt, dass es vermutlich mehr bringen würde die Cache-Verweildauer zu erhöhen um die Zugriffe insgesamt zu reduzieren. Im Moment gibt es ja für all die 1000 Bilder/Icons im Forum z.B. alle 5 Minuten pro Benutzer eine volle Ladung.

 

[tomturbo]

Unix Socket vs. TCP/IP über Loopback Device spart auf jeden Fall etwas an TCP/IP overhead und wird IMHO empfohlen, auch wenn es vielleicht bei der effektiven Leistung nichts messbares bringt.

Wenns nichts messbares bringt wozu soll es dann was bringen auf Socket-Verbindungen zu gehen?

Was die statischen Inhalte angeht hatte ich ja früher schon angemerkt, dass es vermutlich mehr bringen würde die Cache-Verweildauer zu erhöhen um die Zugriffe insgesamt zu reduzieren. Im Moment gibt es ja für all die 1000 Bilder/Icons im Forum z.B. alle 5 Minuten pro Benutzer eine volle Ladung.

Wir haben weder ein Bandbreitenproblem noch einen Apache Engpass und Nero24 hat das schon erklärt warum die Verweildauer so ist wie sie ist.
Die durchschnittliche Bandbreite beim Ausliefern liegt bei weniger als 2mbit.....

 

[TiKu]

Was die statischen Inhalte angeht hatte ich ja früher schon angemerkt, dass es vermutlich mehr bringen würde die Cache-Verweildauer zu erhöhen um die Zugriffe insgesamt zu reduzieren. Im Moment gibt es ja für all die 1000 Bilder/Icons im Forum z.B. alle 5 Minuten pro Benutzer eine volle Ladung.

Wir haben allerlei dynamische Inhalte. Der beste Cache bringt nichts, wenn die dynamischen Inhalte damit nicht mehr gescheit funktionieren.
WP Supercache ist grad aktiv. Es ist schnell, ja. Aber es macht auch verschiedene Probleme, weshalb ich im Moment nicht sagen kann, ob das Plugin dauerhaft aktiv bleiben wird.

 

[BoMbY]

Es kommt bei den Sockets natürlich immer auf die Anwendung und das genaue System an, aber im großen und ganzen sind die eigentlich immer schneller:

When the server and client benchmark programs run on the same box, both the TCP/IP loopback and unix domain sockets can be used. Depending on the platform, unix domain sockets can achieve around 50% more throughput than the TCP/IP loopback (on Linux for instance).

https://redis.io/topics/benchmarks

Notice the server-timed duration is 0.318, but with network overhead it is 0.435, an increase of 36% in total duration. Of course, this is a simple query, but it does show that network overhead is not trivial.

http://momjian.us/main/blogs/pgblog/2012.html#June_6_2012

The results shown here are fairly predicable. The Unix domain sockets are always more efficient and the efficiency benefit is in the 2-3x range. [...] I’m not exactly sure why the efficiency of Unix domain sockets varies as it does compared to TCP sockets, but it is always better.

https://nicisdigital.wordpress.com/2014/03/03/unix-domain-sockets-vs-loopback-tcp-sockets/

However, in the past we also observed a pretty significant difference in QPS results when IP port was used comparing to UNIX socket (communications via UNIX socket were going near 15% faster).

http://dimitrik.free.fr/blog/posts/mysql-performance-80-ga-ip-port-vs-unix-socket-impact.html

--- Update ---

Wir haben allerlei dynamische Inhalte.

Was genau für dynamische Inhalte machen denn Probleme? Eigentlich sollte das was WP generiert doch immer gleich sein, außer eventuell wie viele Kommentare es gibt? Aber dafür kann man bestimmt ein Refresh alle X Minuten einstellen, oder sowas? Hab es schon länger nicht mehr genutzt.

 

[TiKu]

Was genau für dynamische Inhalte machen denn Probleme? Eigentlich sollte das was WP generiert doch immer gleich sein, außer eventuell wie viele Kommentare es gibt? Aber dafür kann man bestimmt ein Refresh alle X Minuten einstellen, oder sowas? Hab es schon länger nicht mehr genutzt.

Die Usernews, die Kästen mit den neuesten Blogeinträgen, den neuesten Threads, den neuesten News auf PCGH... Das sind alles Inhalte die aus Sicht von Wordpress von extern kommen und dynamisch eingeflochten werden. WP Supercache hat dafür zwar prinzipiell eine Lösung, allerdings muss ich dafür erstmal etwas programmieren und für die Kästen (Widgets) am rechten Rand ist das auch nicht trivial.
Ich könnte solche Inhalte natürlich komplett über AJAX laden, aber das erscheint mir auch etwas unsinnig.

Im Wordpress-Backend sorgt Supercache zudem dafür, dass die Editoren nicht mehr sauber funktionieren. Das ist aber vermutlich ein Config-Problem.

 

[BoMbY]

Hmm, okay. Bei den Editoren sollte das natürlich nicht passieren. Wobei prinzipiell müsste es für die Sidebars, etc., doch auch reichen die Super Cache Lebenszeit auf z.B. 5 Minuten zu ändern, dann müsste alle 5 Minuten einmal jede aufgerufene Seite generiert werden. Ich glaube damit könnte jeder leben, und es würde immer noch was sparen. Oder sonst muss man eventuell anders herum ran gehen und den Cache bei Änderungen von Außen invalidieren.

 

[Mogul]

Warum fährt von euch Admins keiner nen e39?Das Forum dort geht seit dem Update der Forensoftware komplett unter und die Jungs schaffen es nicht weil Wissen fehlt (sagen sie ja selbst, ist also keine Böswilligkeit)

sehr sehr geil was Ihr hier so weg schafft. Klasse