Bronies.de

(18.08.2013)Daron schrieb: [ -> ]MiuKisu der Umzug war schon längst...und du musst dich nicht neu anmelden du bist schön längst auf dem neuen Server also keine Panik

Uii^^ Okay, vielen Dank, ich dachte schon, wir müssten alles komplett erneuern. Aber da bin ich echt erleichtert

Kompliment, es läuft super und schnell, hatte immer gegen 18-19 Uhr probleme und jetzt nichts mehr
saubere arbeit Desert

ein fehler der mir gerade Aufgefallen ist

Schau mal links auf mein Registrierdatum. Die Software scheint Probleme mit dem Wort März zu haben.

Uff das Problem kenn ich, hatte das auch mal mit einer anderen Forensoftware, ich denke, das die Datenbank mit dem Registrierdatum auf UTF-8 ist, ich musste es einfach auf ISO-9001 (wars glaub) umstellen.

Oh.... interessant, was sich für Fehler einschleichen. Das muss heute Nacht beim Update auf MyBB 1.6.10 reingerutscht sein.

Hab's schon gefixt. Danke für die Info ^^

Kannst du eigentlich schon abschätzen, wie lange es dauern wird, bis Ponycraft wieder online geht? Ich krieg schon wieder Entzugserscheinungen

Nun, da Bronies.de wieder auf seinem eigenen Server läuft, werde ich meinen eigenen Server erstmal neu aufsetzen. Ich würd gern anders partitionieren und dabei dann auch gleich auf Debian 7.0 wechseln.

Ein paar andere Foren, FileServer, MailServer, WebSpaces und auch Ponycraft sind hier betroffen. Ich schau, dass es nicht zu lange dauert aber n bisschen wird es sich schon noch hinziehen, da erstmal ziemlich viele Daten rumgeschaufelt werden müssen. Aber keine Sorge, Ponycraft kommt wieder!

@DesertFOX: Mal 'ne Frage: Ihr nutzt doch sicher Apache 2, oder?
Habt ihr schonmal in Erwägung gezogen auf z.B. Nginx umzusteigen? Bin selber leider noch nicht zum Testen gekommen, jedoch soll es viel Resourcen-Sparender sein, als Apache sein.
Wurde mir schon von vielen empfohlen.

Deadend

Nginx ist auch um längen Ressourcenschonender.
Und solange man bestimmte Features von Apache nicht braucht würde ich auch bei HA Seiten Nginx empfehlen.

Und noch was: anscheinend gibt es noch Probleme mit den E-Tags. Response ist bspw.

und Request ist

für http://www.bronies.de/images/socialicons/twitter_small.png

Gibt dementsprechend immer einen 200 OK statt einem 304 Not modified. Daneben wendet er auch kein GZIP an um den Traffic zu verringern (zumindest bei Bildern. Bei dem eigentlichen PHP Script scheint das Forum auf GZIP zurück zu greifen.

Noch einen weiteren Caching Vorschlag: alles in einem Thread (showthread.php), was vor der neusten Seite (also bei dem Thread bspw. auf Seite 10) ist, mit einem entsprechenden Caching Header versehen und von einem HTML Cache (wie den von Nginx) für einen Tag oder so cachen lassen. Sollte Lastprobleme auf der DB erheblich minimieren.
Daneben noch die DB über eine RAM Disk laufen lassen (verringert den IO) und auf Redis umstellen und den Cache von Informationen wie Post Bit hochschrauben.

Also im Bereich Caching kann man hier noch ordentlich schrauben um Lastspitzen zu vermeiden. Vorallem bei 32GB RAM kann man die DB so schön entlasten.

(Bevor jetzt kommt das es doch so gut läuft atm: ich hatte heute schon mehrmals längere Ladezeiten - und an der Verbindung kanns net liegen - ich bin über 10GBit Glasfaser am DE-CIX)

---

(19.08.2013)Lazy Dream schrieb: [ -> ]Apache ist aber auch ein Enterprise-Produkt, das eben sehr viele Features hat, deswegen wird es auf großen Webseiten genauso eingesetzt.
Man muss halt abwägen, welche Module man sonst noch braucht. SVN geht mit Lighttpd z.B. nicht und und und.

Apache wird sehr häufig als Backend Webserver verwendet, mit einem Leichtgewicht wie Nginx vorgeschaltet, welcher sich auch um Caching kümmert.
Bei auto-motor-und-sport.de sieht die Requeststrecke wie folgt aus:

Nginx (Caching der Bilder und Loadbalancing) => Varnish (Cache der kompletten Seite über ESI) => Apache 2 (auf den einzelnen Webservern zur Erzeugung der Webseite).

Auf mittelgroßen Seiten fällt dann der Varnish weg (sehr großer Aufwand, da man die ESI Snippets gescheit einbauen muss) und bei kleineren Kunden läuft alles eig. nur über den Nginx (weil wir keine Apache2 Features benötigen).

Selbst die Imageserver laufen nur über Nginx und FastCGI statt über Apache und mod_perl (was wesentlich weniger Fehleranfällig aber auch zigmal langsamer ist).

(19.08.2013)Lazy Dream schrieb: [ -> ]Man muss halt nur schauen, dass die Daten regelmäßig und sicher aus dem RAM gezogen werden. Ich bezweifle, dass es jemanden umbringen wird, wenn im Falle des Falles {5,10,30,60} Minuten Posts verloren gehen.

MySQL lässt sich soweit mir bekannt entsprechend so einstellen, dass Bin Logs ständig auf die Platte geschrieben werden. Dadurch wäre das Backup sozusagen vorhanden. Man muss nur zusehen, dass man dennoch immer in der Nacht einen Dump fährt, weil sonst die Platte mit zu vielen Bin Logs vollläuft (es werden halt sämtliche schreibenden Statements gespeichert).

(18.08.2013)GearTight schrieb: [ -> ]

(18.08.2013)DesertFOX schrieb: [ -> ]Der Umzug erfolgte heute Nacht in der Zeit von 3:20 - 3:40 Uhr. Freut mich, dass es diesmal so reibungslos geklappt hat, dass es kaum jemand überhaupt gemerkt hat .

Da war was? Hab ich gar nicht bemerkt.
Gute Arbeit.

Macht dir nix draus, ich hab auch nix bemerkt (weil ich geschlafen hab, höhö)

Good Job, Desert. Weitermachen!

Falls es gerade nicht mit vollem Speed läuft, könnte das auch daran liegen, dass wir derzeit mehrere Backups auf dem Server umkopieren. Sollte nicht allzu lange dauern...

Vielen Dank aber auch für eure Vorschläge! Wir werden sie gerne mal im TechTeam durchsprechen.

Grad mal mit unserem Datenbankspezialisten gesprochen.

Ergebnisse: so eine DB wie die fürs Forum in den RAM auszulagern bringt nichts. Die Gefahr von Datenverlust ist zu hoch und Schreibzugriffe sollten eh weiterhin auf einem festen Speichermedium durchgeführt werden. Also besser die DB auf der Platte lassen.
Was man aber mit dem vielen RAM machen könnte, wäre eine Vergrößerung des Query Caches und eine Auslagerung von Temp Tables in den RAM. Damit kann man bei MySQL schon sehr viel erreichen. Daneben sollte man auch mal überprüfen, ob irgendwo Indizes fehlen und ob man Slow Querys hat welche man mit 2 Handgriffen optimieren kann. Besonders die Indize sind sehr gut geeignet um Lese Operationen mit GROUP BY, ORDER BY und WHERE zu optimieren, da MySQL hier schon in gewisser weise vorsortieren kann.
Außerdem sollte geprüft werden, welche Tabellen als Type Memory eingestellt werden können (bspw. Tabellen die nur temporäre Daten enthalten). Ansonsten sollten alle Tabellen als MyISAM definiert werden, da MyBB soweit mir bekannt keine Transaktionen oder FK Funktionen benötigt.

Klingt nach guten Nachrichten!
Hatte auch schon Probleme mit error 503

(19.08.2013)Andorius schrieb: [ -> ]

(18.08.2013)GearTight schrieb: [ -> ]

(18.08.2013)DesertFOX schrieb: [ -> ]Der Umzug erfolgte heute Nacht in der Zeit von 3:20 - 3:40 Uhr. Freut mich, dass es diesmal so reibungslos geklappt hat, dass es kaum jemand überhaupt gemerkt hat .

Da war was? Hab ich gar nicht bemerkt.
Gute Arbeit.

Macht dir nix draus, ich hab auch nix bemerkt (weil ich geschlafen hab, höhö)

Good Job, Desert. Weitermachen!

Ach der Umzug hat schon stattgefunden? Wer lesen kann ist klar im vorteil

@DesertFOX: Versteht ich das jetzt richtig? Bronies.de läuft jetzt vorrübergehend auf einem eigenen Server. Sobald du dann deinen wieder fertig hast, also fertig mit neu aufsetzten einrichten bist, kommt Bronies.de wieder da drauf?
Oder hab ich jetzt was falsch verstanden?

(19.08.2013)Atrox schrieb: [ -> ]@DesertFOX: Versteht ich das jetzt richtig? Bronies.de läuft jetzt vorrübergehend auf einem eigenen Server. Sobald du dann deinen wieder fertig hast, also fertig mit neu aufsetzten einrichten bist, kommt Bronies.de wieder da drauf?
Oder hab ich jetzt was falsch verstanden?

Ähhh nein, Bronies.de ist jetzt fertig angekommen auf dem Server, wo es auf Dauer alleine bleiben soll. Die letzten Monate lief es auf meinem Privatserver. Nur möchte ich jetzt, wo Bronies.de nicht mehr auf meinem Server läuft, diesen einfach mal neu aufsetzen. Das hat aber nichts mehr mit Bronies.de zu tun.

Jetzt klar :-) ?

(19.08.2013)DesertFOX schrieb: [ -> ]

(19.08.2013)Atrox schrieb: [ -> ]@DesertFOX: Versteht ich das jetzt richtig? Bronies.de läuft jetzt vorrübergehend auf einem eigenen Server. Sobald du dann deinen wieder fertig hast, also fertig mit neu aufsetzten einrichten bist, kommt Bronies.de wieder da drauf?
Oder hab ich jetzt was falsch verstanden?

Ähhh nein, Bronies.de ist jetzt fertig angekommen auf dem Server, wo es auf Dauer alleine bleiben soll. Die letzten Monate lief es auf meinem Privatserver. Nur möchte ich jetzt, wo Bronies.de nicht mehr auf meinem Server läuft, diesen einfach mal neu aufsetzen. Das hat aber nichts mehr mit Bronies.de zu tun.

Jetzt klar :-) ?

Achso. Jo. Hatte sich für mich so angehört, als dass du Bronies.de einfach umziehst, damit das Forum nicht Down ist, solange du den anderen Server wieder fertig machst.

Aber echt gute Arbeit! Man hat nichts vom Umzug gemerkt, außer, dass das Forum jetzt doch etwas schneller ist.

Vom "schneller werden" hab ich Heut nix mitbekommen. Hab heut mehr Lag's als gestern... und z.t. Lags daran, dass der Server nicht geantwortet hat bzw. dass der request sich viel Zeit Ließ. Gestern ging's dafür so, dass ich an die "gefühlte" 100 Posts rausgehauen habe... und es liegt nicht alleine an der Leitung, auch wenn ich per Wdcma / Hsupa unterwegs bin.

Ist bestpony down? ;_;
Ich brauche es für meine emails .-.

(19.08.2013)Secret schrieb: [ -> ]Ist bestpony down? ;_;
Ich brauche es für meine emails .-.

Ich zitier mal:

(19.08.2013)DesertFOX schrieb: [ -> ]Nun, da Bronies.de wieder auf seinem eigenen Server läuft, werde ich meinen eigenen Server erstmal neu aufsetzen. [...]

Ein paar andere Foren, FileServer, MailServer, WebSpaces und auch Ponycraft sind hier betroffen. Ich schau, dass es nicht zu lange dauert aber n bisschen wird es sich schon noch hinziehen, da erstmal ziemlich viele Daten rumgeschaufelt werden müssen.

Nicht nur, dass einige Nebenforen so lange weg sind, ohne Merrx' Smiley-Server lädt sich hier auch so ziemlich jede Seite einen Wolf... *g*