Loadbalancer Technikwürze 160

Technikwürze 160. Ich sage herzlich willkommen und, neben mir sitzt Sebastian Heinisch das erste Mal in der Technikwürze. Hallo Sebastian.

Hallo David.

Wir reden heute über Load Balancer, und zwar genau über Server. Server haben wir ja alle, grade bei Technikwürze haben wir so 'n, schönen Server, über den du wahrscheinlich heute lachen wirst.

Ja, das ist halt 'n süßer kleiner Shared Hosting Server irgendwo bei irgend'nem großen Hoster und ja.

Genau, aber, wir reden heute über Server und, wie man das Ganze skalieren kann und mit 'nem Load Balancer versehen kann. Erklär uns doch mal ganz kurz, wer du bist und was du machst.

Genau, ich bin Sebastian Heinisch. Ich betreibe eine relativ große Webseite, das ist ein Browser Game, das ist unter www.feuerwache.net erreichbar. Das Ganze hat angefangen so als: Ich kauf mir mal 'n Server irgendwo und stell den mal irgendwo hin, genauso wie die Technikwürze läuft.

Ist dann aber relativ schnell da rausgewachsen aus diesem, ich hab irgendwo 'nen kleinen Server und, ja, deswegen hab ich mich heute mal angeboten, dass wir mal 'n bisschen über Server reden, wie man die verteilen kann, was man da beachten muss, dass man da 'ne schöne skalierende Lösung hinbekommt, dass man auch auf Dauer Spaß mit seiner Webseite hat.

Dann erklär uns doch mal, was ist denn feuerwache.net? Was find ich auf der Webseite?

Feuerwache.net ist 'nen Browser Game, das heißt, man spielt da, 'nen Spiel und dabei ist wichtig, der Spieler besucht praktisch nur die Webseite, muss keinen Client installieren, hat dafür dann, ja, kann praktisch auch im Büro, dieses Spiel spielen. -

Ist ja praktisch für alle Büroangestellten.

Genau, das Spiel selber ist 'nen Managerspiel, das heißt man managt verschiedene Feuerwachen, muss dann, die in 'ner virtuellen Stadt bauen, sieht ähnlich aus wie bei SimCity, und kann dann verschiedene Feuerwehrautos zu verschiedenen Feuern hinschicken und muss das möglichst effizient abarbeiten.

Klingt eigentlich ziemlich spannend. Andererseits mag die Webseite, wenn man sich die das erste Mal anschaut, nicht so groß wirken, aber da ist relativ was los, ne. Was hast du so für Gru... Zugriffszahlen oder zumindest Kennzahlen? Du hast ja so 'ne, so 'n, so 'n Überblick, wie viel User gleichzeitig auf der Webseite rumtoben. Was hast du heute Abend festgestellt?

Genau, also heute Abend waren zum Beispiel, 2.500 Leute online gleichzeitig. Das Schöne ist bei mir, beziehungsweise auch das Schlimme eigentlich für meine Server ist, jeder User macht spätestens nach 20 Sekunden einem, einen Request auf der Webseite per Ajax, was die Server ganz schön zum Schwitzen bringt.

Genau, denn, ihr könnt das ja hochmultiplizieren, da wird schon ganz schön was los auf der Kiste sein beziehungsweise auf den Kisten, das ist ja 'ne Mehrzahl.

Genau, angefangen hat das Ganze einfach mit 'nem LAMP-System, wie das üblich ist, Linux, Apache, MySQL, PHP, auf 'nem ganz normalen OpenSUSE, auf 'nem ganz normalen Standardrechner, den ich dann irgendwann mal ins Rechenzentrum geschickt habe.

Also das, was wir derzeit so für Technikwürze im Einsatz haben.

Genau, eigentlich das, was man überall so standardmäßig findet. Ist halt günstig, ist halt schnell zu installieren, funktioniert erst mal. Das Problem ist, wenn die Webseite dann erfolgreicher wird, beziehungsweise viele Anfragen darauf laufen, dann funktioniert's irgendwann nicht mehr und, diesen Punkt hab ich halt irgendwann erreicht.

Das heißt, wie hat sich das bemerkbar gemacht? Ist die Maschine in die Knie gegangen? Du musstest es ständig neu starten oder, welche Anzeichen hast du gemerkt, dass es, hoppla, hier funktioniert was nicht mehr?

Genau, also das fing erst mal ganz normal an mit den, MySQL Max Connect..., Max Connections wurde erreicht, was bestimmt jeder schon mal gesehen hat irgendwo. Als man das dann endlich behoben hat und mehr Connections zugelassen hat, ging's dann natürlich weiter über, ja, der Webserver, der Apache hat dann gestreikt, die Load ging ewig hoch. Das Ding lief einfach nicht mehr. Es war super langsam dann die Kiste und, es war vorbei.

Und vor allen Dingen das Schlimme daran ist, wenn der eine Server nicht erreichbar ist und du hast wirklich kein Ersatzsystem, dann kommen die User nicht auf dein, Spiel drauf und können es nicht benutzen. Die User wandern ab und das ist, nicht gut, ja fürs Business sozusagen, ne.

Genau, das ist auf gar keinen Fall gut. Und was dann ja auch als Administrator des Systems schrecklich ist, sag ich mal einfach, zumindest aus meiner Sicht damals, ich hatte keinerlei Erfahrung, Wa-, W..., Erfahrung, was ich machen kann. Also ich saß dann da, hab mir gedacht so: „Ja gut, mein Linux Apache MySQL PHP-Gedöns ist jetzt irgendwie langsam. Verdammt, was mache ich nun?" Ich saß dann da wirklich und dachte mir: „Ja, gibt's jetzt irgendwelche Hausmittel?

Was liest man denn immer so im Web? David, hast du da irgendwann mal was gelesen, was man da so machen kann?"

Ja, vielleicht das Erste, MySQL-Server auslagern, E-Mails auslagern und vielleicht so drei Server hinstellen, irgendwie so was.

Genau, also E-Mail ist bei mir nicht so das Thema. Ich verschick praktisch keine E-Mails, aber das MySQL-Server auslagern, genau das hab ich gemacht, weil das liest man überall im Web, dass das die Performance bringen soll, die man braucht und dann soll alles gut sein.

Das heißt, du hast dir im ersten Schritt wirklich 'ne, 'ne zweite Kiste hingestellt und hast, darüber MySQL laufen lassen. Aber das, das an sich ist ja auch schon 'n ziemlicher Balanceakt. Oder könntest du einfach sagen, benutze den Port so und so auf der Maschine mit der IP so und das wird schon laufen, oder?

Genau, das ist sehr, sehr einfach von der Umstellung. Ich hab dann einfach in PHP gesagt: „Verbinde dich nicht mehr zu Localhost, sondern zu irgendeiner anderen IP, die halt im lokalen Netzwerk ist." Das heißt, ich hab im Internet, dann, also ich hab bei den Kisten zwei Netzwerkkarten jeweils, einmal ins interne Netz und einmal ins externe, das heißt das Internet. Im internen Netz können die frei kommunizieren, da geht nichts von nach außen.

Was ja bei so 'ner MySQL-Verbindung immer sehr wichtig ist, weil die ist ja nicht verschlüsselt standardmäßig. Brauch ja auch bei mir nicht, weil mein internes Netz, da kommt keiner rein, außer ich. Von daher, ich vertraue mir selbst, und da dürfen meine Server auch ungeschützt kommunizieren.

Nur das Problem kam ziemlich schnell, ne. Das brachte nämlich keine Besserung irgendwie.

Nee, das hat halt so zwei Tage 'n bisschen Besserung gebracht, aber das war schrecklich. Also ich saß dann da wirklich und hatte dann gemerkt so: Oh verdammt, das ist nicht mein Problem. Also das hat 'n bisschen was gebracht, aber irgendeine Kiste von den beiden hat dann immer, war, ist immer ausgestiegen und dann ja, jetzt, dann hatte man wirklich 'n Problem, weil dann gab's keine Patentlösung mehr, die man so im Web gefunden hat.

Das heißt, du warst auch ziemlich schnell ratlos, zumal du jetzt 'ne zweite Kiste hingestellt hast und dachtest eigentlich, es müsste jetzt laufen, ne.

Genau, weil so 'ne zweite Kiste ist ja auch nicht günstig. Ich muss dazu sagen, ich hab mich dazu entschieden, meine Maschinen zu kaufen.

Das heißt, ich hab da richtig Geld in die Hand genommen und wenn man dann grade richtig Geld in die Hand genommen hat und gedacht hat: So, jetzt hier läuft das und ich brauche nie wieder was machen und für immer alle Zeiten alles toll, dann ist das ziemlich deprimierend, wenn man dann irgendwie so zwei Tage später feststellt: Ja, es ist schön, dass du da Geld in die Hand genommen hast, aber das, ja, hätte man auch, da muss man noch mehr Geld in die Hand nehmen wahrscheinlich.

Was sind denn so grundsätzlich die, die Probleme dabei?

Ja, also ich hab mir dann gedacht, ich muss mehr aufteilen. Also ich brauche 'nen zweiten Webserver zum Beispiel. Und so 'n zweiter Webserver, das hört sich erst mal toll-

Also ganz, ganz kurz, du wusstest zu diesem Zeitpunkt noch nicht, was zu tun ist. Also du, du hast dich immer noch vorangetastet. Oder wusstest du schon, dass die Datenbank, das Problem ist oder das Filesystem? Oder w-wusstest du schon zu diesem Zeitpunkt, wo das Problem liegt?

Ja, ich, das kann man dann ja relativ schnell lokalisieren. Als sich dann immer mehr Probleme auf dem Webserver abgespielt haben, das heißt auf dem, der die PHP-Seiten generiert, hab ich mir dann gedacht: Ja gut, da musst du dran arbeiten. Der MySQL-Server, das ging eigentlich. Also der hat nicht so viele Probleme bereitet wie dann die eigentlichen Webserver, weil die waren dann oder der eigentliche Webserver, weil der war dann ziemlich voll und ausgelastet und da lief dann nicht mehr so viel.

Und dann, ja gut, hab ich mir überlegt, wenn man das jetzt aufteilen möchte, das heißt zwei Webserver dahinstellen, dann, dann kommen ganz komische Probleme auf einmal auf einen zu. Weil so zwei Webserver hinstellen, das hört sich für so 'n Blog hört sich das noch relativ einfach an oder für so 'ne normale Webseite, die man halt irgendwie so hat. Zwei Webserver hinstellen, auf beiden die gleichen Dateien hochladen, alles toll.

Das Problem ist, in so 'nem Spiel, da hat man ja noch andere verschiedene Sachen, die verteilt werden müssen. Das heißt zum Beispiel, wenn jem, wenn 'n Spieler 'nen Profilbild hochlädt, dann muss das auf beiden Servern ankommen.

Genau, denn wenn er nämlich dann auf 'nen anderen Server zugreift und, den User gibt es da nicht, dann gibt es natürlich Probleme. Das heißt, die Server müssen absolut zur gleichen Zeit synchron sein.

Genau. Und dann noch 'nen Riesenproblem: Die PHP-Sessions müssen auch auf beiden Systemen immer vorhanden sein. Also das heißt, wenn der Spieler beim ersten Aufruf auf Server A kommt und beim zweiten Aufruf auf Server B kommt, was durchaus sein kann, dann muss ja seine PHP-Session auch irgendwie da mit hinwandern.

Mhm. Und das, das Problem ist, wer schon mal versucht hat, von einer HTTP-Umgebung die Session des Users mitzunehmen auf eine HTTPS-Umgebung, grade in Onlineshops, der weiß, was alleine das auf einem Server schon für 'n Problem ist.

Genau, und das multipliziert sich dann noch, wenn man das dann versucht, auf mehreren Webservern mitzunehmen. Also das ist dann schon nicht ganz so einfach, wie ich dann-- Oder vor diesen Problemen stand ich erst mal. Dann gab's natürlich noch irgendwelche Caches, die da erstellt worden sind im Spiel und die müssen natürlich auch global gelöscht werden.

Das heißt, die müssen auf beiden Servern gelöscht werden und nicht nur der Server, der PHP-Server, oder der Webserver, der jetzt ausführt, das Löschen, muss das löschen, sondern auch der andere muss das auch mitkriegen und da müssen die ebenfalls gelöscht werden.

Noch mal: Also was genau war jetzt das Problem? Also konntest du's lokalisieren? Waren's die PHP-Skripte, die zu lange sind gelaufen sind? Oder war's, die grundsätzliche Umgebung mit Apache? Oder, oder war eigentlich schlussendlich alles langsam?

Na ja, schlussendlich hab ich festgestellt, dass das ein Zusammenspiel von mehreren Problemen ist. Das heißt, der Apache ist nicht wirklich für so 'n Spiel ausgelegt. Der Apache ist für so Massenhosting ausgelegt. Dafür ist der super, weil der kann Virtual Host, der kann, PHP sicher laufen lassen. Der kann alle möglichen tollen Sachen, die ich aber gar nicht brauche. Weil ich habe eine Webseite, auf me-- die möcht ich halt auf eigentlich einem Server laufen lassen nach Möglichkeit.

Also wie gesagt, eine Webseite. Das Ding kann intern relativ unsicher sein, weil, da ist nur eine Webseite drauf. Diese eine Webseite wird nicht andere Webseiten hacken, wie's prinzipiell bei 'nem Shared Hosting sein kann. Diese Probleme hab ich alle nicht. Also wenn bei mir das System unsicher ist, dann ist die Webseite unsicher und das darf nicht sein. Aber das ist 'ne Sache von meiner Programmierung und da kann mir der Apache leider dann auch nicht bei helfen.

Das heißt, zur Laufzeit, schleppt der Apache diese ganzen Sachen, die du nicht brauchst, trotzdem mit und die sind teilweise im Speicher. Und das sind halt Sachen, die nehmen an sich schon Performance von der Kiste, die du eigentlich bräuchtest. Also die Performance und nicht die Tools, die Apache noch im Rucksack hinten drin hat.

Genau, das ist halt das Problem. Also man muss dann, relativ schnell merkt man dann, ja, dass das System langsam ist, dass, ja, man kommt einfach nicht da, dazu, das so zu benutzen, wie man's benutzen will. Und deswegen hab ich mir dann überlegt: Okay, ich kauf mir jetzt noch 'n dritten Server dazu, dann hab ich zwei Webserver.

Und ein Datenbankserver hatte dann diese ganzen eben beschriebenen Probleme mit den Synchronisieren und Sessions übernehmen und bla blubb und, ja, da bin ich dann irgendwann auf 'ne Lösung gekommen.

Die da lautet?

Also, erst mal hab ich mich von meinem schönen Apache getrennt. Wie gesagt, ist ein super System. Wenn man mehrere, wenn man mehrere Webseiten hostet, ist das alles super toll und super praktisch. Keine Frage.

Aber wenn man nur eine Webseite hostet, und die, ja, diese schnell sein soll, dann kommt man irgendwann, ja, steht man vor dem Problem und sagt sich: „Okay, der Apache, der kann das alles, aber ich will was anderes, ich will was Schlankeres und was kann man da denn einsetzen?" Dann hab ich mich umgeschaut: Was setzen denn so die Großen ein? Was setzt denn MySpace ein? YouTube? Ja, wenn man dann sich da mal umschaut, was die so einsetzen, die benutzen Lighttpd.

Das ist halt 'n besonders schneller und sehr, sehr schlanker Server. Und der hat noch eine Besonderheit. Der hat nämlich 'ne FastCGI PHP-Schnittstelle. Ist erst mal, hört sich erst mal komisch an, ist aber sehr, sehr praktisch. Bei mir auf meinen Webservern, läuft der Lighttpd als Dienstdämon, nimmt die Anfragen an, wenn er entscheidet, es ist eine PHP-Sache, die da, benutzt wird, greift er auf diese FastCGI-Schnittstelle zu und da sind dauerhaft lebende PHP-Instanzen drin.

Das heißt, wenn bei mir PHP benutzt wird, dann wird eine schon laufende PHP-Instanz genutzt und es wird nicht eine neu erstellt, wie es bei dem Apache üblich ist.

Das heißt, sonst ist es ja so, dass sobald du 'ne neue Seite aufrufst oder sobald du jetzt 'n Ajax, Request startest, wird jedes Mal eine neue Instanz gestartet.

Genau, also man hat jedes Mal eine neue PHP-Instanz, die praktisch komplett neu erstellt werden muss im Kernel und hin und her und das dauert erst mal, bis die da ist. Bei mir lebt die einfach schon, diese PHP-Instanz, und wird benutzt von irgendnem Webserver dann und, wird dann hinterher praktisch die Verbindung wieder geschlossen, aber die PHP-Instanz bleibt am Leben. Ja, das hat schon mal sehr viel gebracht.

Wie gesagt, dann einfach, durch, durch die, durch den schnelleren Webserver, das hat 'ne ganze Menge gebracht. Dann kam man irgendwann dazu, dass man sagt: „Okay, so 'ne MySQL-Datenbank wird jetzt auch nicht schneller, wenn ich sie mehr benutze.", also ich kann das ja mal aus heutiger Sicht sagen: Aus heutiger Sicht prasseln auf die Datenbank circa sechstausend Anfragen pro Sekunde ein.

Die sind alle weitgehend optimiert, aber ja, man kann's nicht immer so zu hundert Prozent der Datenbank gerecht machen. Also man hat auch mal schwierige Queries- -die man abfeuern muss, grade bei so 'nem Computerspiel. Das ist, kommt dann auch noch mal dazu. Und dann versucht man zu cachen. Cache ist bei so 'nem, bei so 'ner Webseite extreeem wichtig.

Genau. Also cachen heißt, dass, wenn ich mir so 'ne Seite rendere und da ist jetzt, ich geh mal von einer ganz normalen Webseite aus, da ist rechts der News-Bereich und vorne, sind so 'n paar Kommentare und da fließt höchstens einmal am Tag irgendwie 'ne Änderung auf diese Seite ein, dann kann ich für diesen Tag, das alles cachen in einer statischen Datei. Das wird vom ersten User gemacht.

Wenn der zweite User da draufgeht, der greift auf den Cache zu und dadurch, dass das nicht mehr gerendert werden muss, keine Datenbankanfrage mehr gemacht werden muss, ist die sofort da. Das ist das Prinzip des Cachings, ist bei dir aber 'n Problem, oder?

Genau. Also auf so einer normalen Webseite klappt das natürlich sehr, sehr gut, weil da kann die komplette Webseite praktisch gecacht werden und nur wenn sich was ändert, muss dieser Cache erneuert werden. Bei mir ist das Problem: Jeder Spieler sieht ja irgendwas anderes. Kein Spieler hat die Stadt genauso aufgebaut wie 'n anderer Spieler. Deswegen nutze ich Xcache. Xcache ist, eine PHP-Erweiterung. Die wird praktisch in PHP einkompiliert.

Das Ganze bringt 'ne deutliche Performancesteigerung, und sorgt praktisch dafür, dass ich Funktionen cachen kann.

Das heißt, wenn ich 'ne Funktion in, mit PHP aufrufe, kann ich einfach im Hintergrund sagen: „Diese Funktion, das Ergebnis davon möchte ich gecacht haben." Ich kann irgendwann sagen: „Okay, dieser Cache von dieser, dieser Funktionsaufruf ist jetzt ungültig, aber so lange ist der erst mal gültig." Das heißt, wenn ich diese gleiche Funktion noch mal mit den gleichen Parametern aufrufe, wird sie nicht erneut berechnet, sondern die Daten kommen einfach aus dem Cache.

Und alle Daten, die im Cache liegen, sind natürlich 'ne deutliche Entlastung, weil dann muss nicht extra 'ne, MySQL-Verbindung aufgebaut werden. Da muss nicht extra was berechnet werden, sondern es kommt einfach aus dem Cache, es ist einfach sofort da und, ist für mich einfach direkt nutzbar. Das Ganze kann man, wie gesagt, wir haben jetzt, ich hab jetzt zwei Webserver, die erst mal so nichts voneinander wissen, und bei Xcache ist es auch so, da wissen sie auch nicht, was da gecacht wird.

Also das heißt, jeder Webserver cached für sich alleine. Das kann man zum Beispiel für so Funktionen machen wie: Ich hab so was, bei mir gibt's User-IDs intern und, die haben natürlich jeweils immer 'n Usernamen. Wenn ich jetzt diese Abfrage mache, ich hab die User-ID fünf, welcher Name gehört dazu? Das render ich immer lokal auf den Rechnern.

Wie war hinterher, es gibt auch noch globale, Caches, da komm ich später zu, aber so was kann man immer sehr gut lokal machen, weil das kann jeder, jeder Webserver für sich selber berechnen Einmalig und, hat es dann und deswegen kann man so was schön per x-cash machen, da wird das Netzwerk nicht belastet, und ist super.

Das Problem ist jetzt immer nur, wie gesagt, du hast zwei unterschiedliche Server, die wissen noch nicht großartig was voneinander, aber darum geht's ja jetzt eigentlich. Also kommt jetzt eigentlich so Step zwei, ne, bei der, Performance Optimierung.

Genau. Ja, ich hatte dann irgendwann meine zwei Server da stehen, meine zwei Webserver plus den Datenbankserver und hab mir dann gedacht: „Ja, wie mach ich das denn jetzt, wenn 'n User auf die Seite kommt? Wie soll der überhaupt...“ Also normalerweise gibt man ja per DNS, den Namen www.feuerwache.net weist man eine IP zu und diese IP, da läuft 'n Webserver drauf und der macht dann irgendwas mit dieser Anfrage.

Ja, ich hab jetzt aber zwei Webserver und wie entscheidet denn jetzt der User, auf welchen Webserver er geht und wie soll er das, ja, wie soll 'n das gehen? Da hab ich mir angeguckt, da muss es irgendwie Load Balancing Software für geben oder so was. Und gibt es auch. Auch da hab ich mir wieder angeguckt: Was nutzen die Großen? Was nutzen die großen Webseiten? Und ich bin dann irgendwann auf Pound gestoßen, wie die Währung. Und das ist halt wirklich super.

Das ist ein kleiner Mini-Webserver, der nicht selbst Webseiten ausliefert, sondern der wartet praktisch auf eine Verbindung von einem User, der verbindet sich zu diesem Pound. Der Pound guckt sich an, welche Webserver sind wie ausgelastet aktuell und weist den User an den am wenigst ausgelasteten Webserver zu.

Der beantwortet die Anfrage, schickt seine Antwort allerdings nicht an den User zurück, wie es üblich wäre, sondern an den Pound-Webserver und dieser Pound schickt die Antwort dann wieder weiter an den User. Das hat den Vorteil, dass wenn mir jetzt ein Webserver ausfällt, im besten Fall merkt das der Spieler gar nicht, weil der geht WW-- auf www.feuerwache.net, kommt an den Pound und der Pound merkt: „Oh, ein Webserver ist weg. Da kann ich jetzt keinen User drauf zuweisen.

Dann nehm ich einfach den anderen Server und dann wird der Spieler an den anderen Server weitergeleitet.

Und Pound ist jetzt 'ne Software, die auf beiden installiert wird oder ist es 'ne Hardware? Oder wie, wie kann, wie kann der Hörer sich das vorstellen?

Nein, Pound ist eine Software, die auf einen dieser beiden Webserver dann installiert wurde, und praktisch davor geschaltet wurde. Das ist dann auch praktisch der Webserver, der läuft, wo sich der Spieler hinconnected, wenn er auf www.feuerwache.net-

Das heißt, die IP eigentlich, die in DNS eingetragen ist. Mhm.

Ja, Pound hat halt verschiedene Modi, in dem man den Pound arbeiten lassen kann. Da gibt's zwei Stück und da musste ich mich auch entscheiden, welche, welche Arbeitsmodi ich nehme. Zum einen gibt's den Modus, dass ein User immer an den gleichen Webserver geleitet wird. Das heißt, David, wenn du jetzt auf www.feuerwache.net gehst, dann wird erstmalig geschaut, auf welchen, welcher Webserver hat am wenigsten Last. Nehmen wir Webserver A, dann wirst du immer zu Webserver A geleitet.

Also nicht nur heute bei meinem Spiel, sondern grundsätzlich immer.

Genau, grundsätzlich. Natürlich, hat das den Pro-- hat das das Problem, wenn der Server dann mal ausfällt, dann hast du 'n Problem, auf diese W-Webseite zuzugreifen.

Während alle anderen, die umgeleitet wurden auf Server B, sich freuen.

Genau. Ist natürlich keine schöne Lösung, aber der Vorteil ist: Da du ja immer zu Server A kommst, hab ich keinerlei Probleme mit Übernahme der Session-Daten auf den anderen Server. Weil du ja eh immer zu Server A kommst, brauche ich mir darum keine Gedanken machen.

Mhm. Nachteil heißt aber auch: Wenn dieser Server weg ist, hast du grade angesprochen, ist der Benutzer weg.

Genau. Also der hat dann erst mal keine Möglichkeit mehr, auf seinen, auf seinen Webserver zuzu-- auf das Spiel zuzugreifen. Der steht dann erst mal im, vorm Trockenen.

Wie sieht denn die zweite Möglichkeit aus bei Pound?

Die zweite Möglichkeit ist, der User greift zufällig auf irgendeinen Server zu. Das heißt, entweder du, David, gibst www.feuerwache.net ein, du kommst auf Server A, dann klickst du irgendeinen Link an, kommst dann zufällig auf Server B, klickst wieder irgendeinen Link an und kannst, wie gesagt, zwischen den Servern hin- und herswitchen.

Ach, das heißt nicht nur pro Session, sondern auch je nachdem. Das wird also quasi laufend geprüft-

Genau, also-

... wo die Last ist.

Genau, es wird laufend geprüft und es wird die möglichst effizienteste Verteilung gewählt. Also du kommst eigentlich immer bei jedem Aufruf und wenn du nur 'n Bild nachlädst auf der Webseite, kann es wieder sein, dass du an den anderen Server kommst.

Genau. Aber, diese Prüfung, wo ist jetzt, die Last? Nimmt das nicht auch wieder Performance und Zeit in Anspruch? Oder?

Ja, das nimmt Performance und Zeit in Anspruch, wird aber natürlich nicht bei jedem einzelnen Aufruf gemacht, sondern Pound, misst einfach die Zeit, die das Webs--, die einer der Webserver beim vorherigen Aufruf mal gebraucht hat und kann dann daraus errechnen für den nächsten Aufruf, für den darauf folgenden, welcher Webserver im Moment am wenigst belasteten ist. Also das nimmt nicht wirklich viel Last weg. Also das, das kann man durchaus investieren. Da gibt's natürlich riesige Vorteile durch.

Wenn du zufällig immer auf einen Server kommst, da hat man eine super effiziente Verteilung. Man kann nachts, und das hört sich jetzt doof an eigentlich, man kann nachts Webserver runterfahren. Weil wenn man sich mal so 'ne Lastverlauf bei so 'nem Webserver anguckt, der hat immer so von zwanzig Uhr an bis, was weiß ich, zweiundzwanzig Uhr richtig was zu tun, die Webserver. Da ackern die richtig viel. Aber nachts um drei greifen dann doch deutlich weniger User zu.

Bei mir wären's dann so um die vierhundert Leute, die dann gleichzeitig online sind. Das ist schon deutlich weniger, wenn man so da in den Abendstunden zweitausendfünfhundert Leute online hat.

Das heißt, die Idee, wenn du nachts einen dieser Server runterfährst, sparst du Stromkosten.

Genau. Ich spar ohne Ende viel Stromkosten, weil leider ist das Teuerste, was man hinterher hat an so Serverkosten, der Strom. Das ist auch, wo man keine Rabatte raushandeln kann. Bei allem anderen kann man super Rabatte raushandeln, wenn man irgendwie mehr abnimmt, aber bei Strom ist es leider so, umso mehr man abnimmt, umso teurer wird's. Und da kriegt man auch nichts,, kriegt man auch nichts wieder.

Tja, die wissen schon, wie sie Geld verdienen.

Genau und deswegen ist es nachts Server ausschalten, ist das Beste, was man machen kann. Geht halt aber auch nur, wenn man, wenn der User zufällig auf irgend 'nen Server zugreift, weil dann stellt Pound einfach fest, dieser Server ist jetzt nicht mehr da. Klar, der wurde runtergefahren und leitet den User an den anderen Server weiter.

Gibt's denn da jetzt noch Probleme oder das hört sich jetzt eigentlich alles nach super duper an?

Ja, das hört sich super duper an. Das Problem ist damit, die User-Session. Das heißt, der User kommt auf, Server A, ihm wird da eine PHP-Session erstellt, kommt auf Server B, ihm wird eigentlich wieder eine PHP-Session erstellt. Die weiß allerdings nicht, was der User auf Server A gemacht hat. Ja, und dann hätte der User eigentlich zwei PHP-Sessions. Manchmal ist er eingeloggt, manchmal nicht. Manchmal weiß der Server irgendwas über ihn, manchmal nicht. Das ist, total problematisch.

Das ist ein richtig großes Problem.

Also warst du wieder so an der Stelle, wo du überlegen musstest, wie geht's jetzt weiter? Aber auch dafür hast du 'ne Lösung gefunden.

Ja, auch dafür hab ich 'ne Lösung gefunden für dieses Problem. Die Lösung nennt sich Memcache und ist genial.

Das will man.

Ein Fan.

Ja, da-das, das ist das, was man will. Das ist total genial.

Was macht Memcache?

Memcache ist im Prinzip eine super simple Software. Der kann man sagen, der kann man 'nen Key und 'nen Value geben und diese Daten werden im, einfach im Arbeitsspeicher gespeichert. Das hört sich simpel an, das ist auch super simpel und es ist super genial, weil diese Software kann nichts. Also die kann wirklich diesen Key und Value nehmen, kann den in den Arbeitsspeicher packen.

Wenn ich das später mal auslesen will, dann geb ich ihr den Key und dann sagt er mir, gibt, Memcache mir den Value zurück. Das ist es. Das ist, kein bisschen sicher, diese Software. Das heißt, die kennt überhaupt nicht so was wie 'ne, also Memcache ist 'nen Serverdienst und normalerweise haben Serverdienste immer so was wie 'n Benutzernamen, Passwort, um sich da einzuloggen. Kennt jeder, der schon mal 'nen MySQL Server administriert hat, kennt Memcache nicht.

Memcache ist die unsicherste Software, die man irgendwie benutzen kann, aber wird halt wie gesagt nur auf meinem, in meinem internen Netz gesprochen und von daher ist es wieder egal, weil in meinem internen Netz darf wie gesagt alles unsicher sein, weil da kommt eh keiner rein, außer ich und ich vertraue mir selbst.

Memcache ist halt 'nen Serverdienst und da kann ich jetzt sagen: „Auf diesem Memcache-Server speicher mir doch da meine PHP-Sessions.“ Das heißt, jedes Mal bei jedem Aufruf wird, die Anfrage von dem Pound, von dem Load Balancer entgegengenommen, an einen zufälligen Webserver weitergeleitet.

Dieser Webserver connectet sich zu dem Memcache-Server, der hält wiederum die PHP-Session bereit, gibt die PHP-Session an den, Webserver zurück und der Webserver kann mit dieser PHP-Session arbeiten, gibt die Daten wieder an den Pound zurück, also an den Load Balancer und die, der wiederum die Daten an den User.

Das hört sich verlockend an.

Das ist total genial.

Und,, wie sieht das jetzt aus? Also ist das denn pro, pro Server oder, findet das Ganze wieder global statt?

Nein, Memcache ist wieder ein globaler Server, wo sich dann wiederum halt alle Webserver drauf hin connecten.

Mhm. Okay.

Memcache hat natürlich noch weitere Funktionen und wird auch,, wird auch von mir ganz groß eingesetzt. Auch da kann man wieder dieses Funktionscaching machen, was ich eben schon beim Xcache erklärt habe. Das heißt, ich hab eine Funktion, geb der zwei Werte mit, krieg daraus irgend 'n Ergebnis zurück. Wenn noch mal diese Anfrage kommt, wird das nicht neu berechnet, sondern kommt einfach vom Memcache. Und das kann man sehr gut bei so globalen Sachen machen.

Ich hab ja eben erzählt, dass es Sachen gibt, die kann jeder Webserver für sich eigentlich selber ausrechnen und er kommt immer zu demselben Ergebnis. Dann nutze ich Xcache, weil dann muss nicht diese, diese, Datenübertragung übers Netzwerk gemacht werden zu dem Memcache jeweils hin. Aber es gibt auch Funktionen, die man ausführt, die müssen immer das Gleiche, ja, ist jetzt schwer, wenn man das Spiel nicht kennt. Zum Beispiel, ja, ich kann ich ja einfach mal so erklären.

Gern.

Es gibt Gebäude bei mir, wie gesagt, diese Feuerwachen.

Genau, das ist ja wie gesagt eine Stadt von oben, die ich mir vorstellen kann und du hast da, Gebäude, wo Brände sind und deine Feuerwache und, die Aufgabe ist dann halt, zum Beispiel jetzt Feuerwehrlöschwagen hinzuschicken zu dem brennenden Gebäude.

Genau, und ich hab diese Gebäude, diese Feuerwachen. Und wenn ich jetzt so 'ne, so 'n Feuerwachen-Objekt, das Spiel ist komplett objektorientiert programmiert, wenn ich jetzt so 'n Feuerwachen-Objekt auslesen möchte, dann kann, dann muss das global gecacht werden, weil, der Spieler kann ja diese Feuerwache ändern. Das heißt, er kann sie ausbauen, er kann ihr 'nen anderen Namen geben.

Wenn ich jetzt da Xcache einsetzen würde, würde dieses, würde dieser Cache für dieses Feuerwachen-Objekt nur auf diesem einem Xca-, nur auf diesem einen PHP, Server das mitkriegen und könnte den anderen das gar nicht mitteilen. Wenn ich jetzt dieses Feuerwachen-Objekt global speichere mit Memcache, und da dann was ändere, dann ist das natürlich wieder auf allen anderen Servern ebenfalls erreichbar, weil die eben auch ihre Daten von dem Memcache-Server holen. So weit verständlich? Das ist super.

Memcache wird von richtig vielen und auch wieder großen Seiten eingesetzt. Also das kriegt man bei total vielen dieser Serverkomponenten mit, die ich jetzt hier so aufzähle-, dass das von richtig großen Seiten eingesetzt wird.

Facebook zum Beispiel.

Richtig, Facebook setzt Memcache ein. Ja, und dann hatte ich noch von 'nem weiteren Problem ganz am Anfang gesprochen:, wenn 'n Spieler Dateien hochlädt, 'n Bilder upload.

Also sein Avatar zum Beispiel oder was auch immer.

Dann muss das natürlich auch auf allen Webservern verfügbar sein, weil ich weiß halt wie gesagt nicht, auf welchen Webserver der User kommt, wenn er dieses Bild runterladen möchte. Und dann gibt es ganz große Verfechter, also dann gibt es eigentlich Dateifreigaben, könnte man dafür nehmen. Da gibt es NFS, Samba und es gibt noch 'n paar mehr Protokolle. Eigentlich in jedem Lehrbuch steht, NFS ist die Dateifreigabeart, die man auf Servern sprechen möchte, die dafür super ist. Bei mir nicht.

Bei mir hat das nicht, war das unperformant. Ich weiß nicht warum. Ich weiß nicht, was ich falsch gemacht hat. Vielleicht kann mich da ja auch jemand in den Kommentaren irgendwie, korrigieren oder so, aber mein NFS-Server war super langsam, zumindest gefühlt. Und deswegen hab ich mich für 'nen Samba-Server entschieden.

Das heißt, die klassische Windows-Dateifreigabe, auf 'nem Mac Server, auf 'nem, Linux-Server hab ich, eingerichtet und jeder Webserver mountet praktisch diesen, dieses Samba Share, und kann dann darüber die Dateien, die Bilder austauschen und die werden dann einfach da drauf gespeichert. Ist eigentlich 'ne super simple Sache. Sollte eigentlich nicht performanter sein als NFS, ist es aber bei mir.

Und da hast du dich klar natürlich für das Performantere entschieden.

Genau, also jedes Lehrbuch gibt mir da, wird da sagen, das ist totaler Schwachsinn, was du da machst, aber bei mir war es besser und, deswegen setz ich das jetzt ein und bin da sehr zufrieden mit. Läuft super.

Wie gesagt, wenn der eine oder andere, Tipps in diese Richtung hat, warum NFF, NFS, es ist schon späte Stunde,, besser funktionieren sollte, dann, schreibt in den Kommentaren.

Genau. Ja, und dann hatte ich natürlich, das lief dann irgendwann, dann hatte ich meine Webserver so weit aufgeteilt, die Webseite lief und dann irgendwann kommt man dann dazu und denkt sich: „Oh, jetzt noch so 'n dritten Webserver, dann läuft das ja alles noch besser und noch toller und alles super." Ja, stimmt auch. Läuft dann auch alles noch besser und noch besser und, alles super. Das Problem ist dann irgendwann, irgendwann fängt dann die MySQL-Datenbank an, dann doch langsam zu werden.

Und dann steht man wieder vor dem Problem: Jetzt muss ich meine MySQL-Datenbank auch noch aufteilen auf mehrere Rechner. Hab ich nicht gemacht. Weil das ist ein massiver Aufwand und, ja, ich hab dann verzweifelt nach Lösungen gesucht. Ich hab dann auch eine gefunden und die ist echt genial. Die kann ich jedem nur empfehlen, auch bei kleineren Webseiten, weil, das bringt echt 'ne Menge Vorteile mit.

Und zwar hab ich einfach die MySQL-Datenbank-Engine von MyISAM, was der Standardwert ist, auf InnoDB geändert und, damit praktisch die Storage Engine von MySQL angepasst. Und InnoDB hat nämlich ganz, ganz tolle Features, die man eigentlich immer haben will. Und ja, deswegen braucht man das. Zum Beispiel kann InnoDB, ist InnoDB transaktionssicher. Das heißt, man kann eine, Transaktion starten, wenn man 'ne MySQL-Verbindung macht.

Man kann verschiedene Abfragen, man kann verschiedene Updates fahren zum Beispiel und kann die hinterher bestätigen. Ein Beispiel: Ein User, baut ein Gebäude. Dafür müssen verschiedene Abfragen gemacht werden. Es muss zum Beispiel erst mal, das Geld von dem Spieler abgezogen werden. Das heißt, es muss ein Update auf die User-Daten irgendwie passieren. Dann muss das Gebäude erstellt werden. Das heißt, da passiert noch ein Insert.

Wenn jetzt aber zwischen dem Update und dem Insert irgendwie die My-- der MySQL-Server stirbt oder was auch immer passiert, also die, die, der zweite Part nicht passieren kann aus irgendeinem Grund, dann würde dem User Geld abgezogen werden.

Für eine Leistung, die er nicht erhalten hat.

Genau, aber er würde kein Gebäude bekommen.

Das heißt, diese Transaktion, die aus mehreren Aktionen besteht, sozusagen, wäre ungültig und du hättest 'n, ja, 'n Problem mit dem User.

Genau, der User würde sich bei mir zu Recht beschweren. Und damit das nicht vorkommt, kann man praktisch sagen: Ich starte jetzt eine Transaktion. Dann wird erst mal nichts ausgeführt. Der, das Update wird nur an den W..., an den MySQL-Server übermittelt und das Insert wird auch an den MySQL-Server übermittelt. Dann sendet man da den Befehl Commit und erst dann werden beide Befehle ausgeführt und dann ist auch von MySQL sichergestellt, dass beide Befehle ausgeführt werden.

Es kann nicht passieren, dass nur ein Pa..., Befehl ausgeführt wird. Das ist natürlich, sehr schön, weil dadurch erspart man sich sehr viele, Beschwerden und Probleme mit den Spielern, weil da man einfach sicherstellen kann, dass so was nicht vorkommt.

Könntest du so 'ne Transaktion dann auch wieder rückgängig machen?

Richtig. Also wenn ich jetzt meine beiden Befehle gesendet hätte, könnte ich 'n Rollback senden. Dadurch wird die Transaktion praktisch zurückgerufen. Ist aber jetzt so im normalen Umfeld passiert das nicht, weil ich programmiere das ja alles im Vorhinein und, wenn's dann einmal programmiert ist, dann soll das auch laufen und dann soll ich nicht irgendwann, das zurückrollen wollen, aber prinzipiell ist das möglich.

Noch ein Riesenvorteil von InnoDB gegenüber zu MyISAM ist, InnoDB kann einzelne Zeilen sperren, anstatt die komplette Tabelle zu sperren.

Genau, jetzt, jetzt müssen wir das ganz kurz erklären. Tabelle sperren, korrigier mich, wenn ich, wenn ich das falsch erkläre. Grundsätzlich ist es ja so, also wir reden ja immer davon, dass mehrere Benutzer die Webseite gleichzeitig benutzen. Wenn ich mir jetzt 'ne Tabelle angucke, das könnte zum Beispiel, der User-Profil sein, zum Beispiel.

Wenn jetzt ein User ein Update macht an dieser Stelle, und ein zweiter macht an derselben Stelle vielleicht auch ein Update, dann könnten die Daten sich gegebenenfalls überschreiben. Deswegen setzt man eigentlich eine Tabelle in Ruhepause sozusagen für den Zeitpunkt. Das heißt, ein Benutzer sagt jetzt, ich möchte irgendwas ändern. Die Tabelle wird in 'ne, in 'ne Sperre geschickt. Nur dieser Benutzer kann was ändern und der andere müsste quasi so lange warten.

Nach dieser Aktion wird sie wieder freigegeben und der andere User könnte was machen. Also das verhindert im Prinzip, dass die Daten quasi überschrieben werden von mehreren Benutzern gleichzeitig. Nur das ist ja auch 'n Problem, wenn die gesamte Tabelle, zum Beispiel Profildaten jetzt gesperrt würde, ne.

Genau, weil wenn du dein Profil bei Feuerwache ändern möchtest und ich mein Profil, also unsere Profile haben ja gar nichts miteinander zu tun. Ich mein Profil auch ändern möchte zur gleichen Zeit, dann kommt halt die Zeilensperre zu tragen. Das ist wiederum, so: Du sperrst einfach deine Zeile, daran kannst nur du was ändern.

Ich sperre meine Zeile, daran kann nur ich was ändern, aber wir können trotzdem gleichzeitig unsere Daten ändern, weil halt nicht die komplette Tabelle gesperrt wird, sondern nur die Zeile.

Das heißt jetzt die Zeile, wo meine User-ID drin ist und für einen anderen User die andere User-ID. Und es ist jetzt grade beim Profil, also beim Profil ist vielleicht grade ein schlechtes Beispiel, weil nur ich mein Profil ändern könnte, aber es könnte ja sein, dass du als Administrator auch in dieses Profil grade reingehst, weil du was Administratives machen willst und dann wäre gewährleistet, dass wirklich das Ding auch gesperrt wird zur Sicherheit.

Und das klappt auch so sehr super. Dann kann noch InnoDB echte Fremdschlüssel. Man kennt das, man hat zum Beispiel, 'ne User-Tabelle und 'ne User-Profil-Tabelle. Wenn man jetzt, die, diese Verbinden, diese, Tabellen sind verbunden. Das heißt, in der User-Profil-Tabelle steht auch eine User-ID drin.

Das heißt, damit mach ich die Verknüpfung. Das heißt, die eine Tabelle, zum Beispiel die User-Tabelle, hat, hat eine Spalte, das ist die ID und das wird als Key genommen, damit du beide verbinden kannst.

Genau. Und dann hat InnoDB echte Fremdschlüssel, also InnoDB, also bei MyISAM ist es so, der Programmierer, der das mal eingerichtet hat, der weiß das. Aber die Software MySQL hat davon eigentlich keine Ahnung, dass da irgend 'ne Verbindung zu besteht. InnoDB stellt einen das sicher. Also InnoDB kann man sagen, hier besteht eine Verbindung zwischen den beiden Keys und wenn der eine Key gelöscht wird, dann lösche auch den anderen.

Das heißt, wenn aus der User-Tabelle ein User gelöscht wird, werden alle da dran hängenden Tabellen, die sich auf diese User-ID beziehen, mit gelöscht, wenn man das möchte.

Das ist natürlich super praktisch. Also im, in diesem Fall, wenn wir jetzt genau von dem User, von der User-Tabelle reden und wir, reden von der Profil-Tabelle und dann gibt es vielleicht noch eine mit irgendwelchen Setups oder so was, dann müsste ich als Programmierer jetzt, wenn ich das normal programmiere, erst, eine Tabelle löschen, gleichzeitig die andere und dann wieder die dritte, was wiederum zu Profil, Pro..., zu Problemen führen können. Also das ist 'n Problem.

Aber ich muss es wie gesagt händisch machen, dass ich jede einzelne lösche und immer als Programmierer weiß, ja, da hab ich in dieser Stelle jetzt auch was hinterlegt, deswegen muss ich das da auch löschen. Aber mit InnoDB kannst du das Ganze umgehen.

Genau, InnoDB macht das Ganze für mich automatisiert. Das heißt, ich brauche nur noch in der User-Tabelle den einen Eintrag löschen und in allen anderen Tabellen wird das automatisch mitgelöscht.

Klingt ja richtig nach 'm Traum.

Das ist sehr, sehr schön. Also da wird man als Programmierer auch echt faul, weil man verlässt sich da natürlich auch drauf und man kann sich darauf auch verlassen. Also es funktioniert sehr, sehr gut.

Mhm. Und deswegen auch deine Empfehlung, das grundsätzlich auch für kleine Webseiten zu machen.

Genau, weil wenn der Programmierer faul werden kann, ist alles super, weil auf sich auf andere zu verlassen, wenn sie die Arbeit gut machen, ist ja das Beste, was einem passieren kann. Das Ganze, diese ganze Umstellung, vor allen Dingen dieses mit den Zeilen und Tabellen sperren, hat wahnsinnig s-s-Speed gebracht. Weil auf einmal sehr, sehr viel mehr auf der Datenbank passieren kann.

Wie gesagt, meine Datenbank, eine Maschine macht im Moment 6.000 Abfragen in der Sekunde und der merkt man das gar nicht an. Die idelt so vor sich hin. Das ist, zwar auch schon eine gute Maschine, aber, trotzdem ist genial.

Also wir haben jetzt verschiedene Lösungen angesprochen, die grundsätzlich dein Performance-Problem gelöst haben, nämlich LightHTTP, dann hatten wir Pound, den Load Balancer, quasi Memcache, Samba und MySQL. Und grundsätzlich ist das 'n, 'n schönes Paket, was dazu gesorgt hat, dass deine Webseite performant lief. Ja, aber grundsätzlich, ja, also du hast 'ne saubere Basis, die läuft und die ist auch echt schnieke. Nur du musst es ja quasi überwachen.

Also du musst 'n Auge drauf haben, ist jetzt irgendwie, es kann ja immer noch sein, dass 'ne Festplatte abraucht oder der Arbeitsspeicher raucht ab. Das heißt, du musst gewährleisten können, dass das stabil, dass das System stabil läuft. Das heißt, du musst es beobachten, also Monitoring nennt man das Ganze. Wie hast du dich diesem, diesem Thema genähert?

Genau, also das Problem ist jetzt, wenn man jetzt einen Webserver hat, wie du David für Technikwürze, dann kriegt man das mit, wenn da irgendwas nicht in Ordnung ist..

Genau, entweder Webseite läuft oder sie läuft nicht. Also da gibt es nichts dazwischen, ja.

Genau. Und bei mir, man hat das jetzt ja schon gehört, das werden auf einmal ganz viele Dienste, die da laufen, also, also Server, Serverdienste und auch physikalische Kisten werden das auch immer mehr.

Genau, haben wir ja angesprochen, durch die Lösung sind natürlich 'n paar mehr Sachen dazugekommen, die auch überwacht werden müssten.

Genau und, dann schaut man sich um: Okay, ich hab ganz viele Sachen, die überwacht werden müssen. Zum Beispiel der Arbeitsspeicher, ist der voll? Ist der, funktioniert der? Ist der kaputt? Ist der physikalisch kaputt? Die CPU läuft, die, die Laufzeiten. Laufen die Webserver vernünftig? Geben die vernünftige Antworten, die ich erwarte?

Das heißt, diese HTTP-Antworten, die bei jedem Request, bei jedem Bild, bei jeder Java-Script-Datei anfallen.

Genau. Haben die Server eigentlich noch Internet? Also, hört sich doof an, aber, jeder Webserver von mir muss ja prinzipiell auch zurück ins Internet kommen und auch das muss überwacht werden, weil das ist auch nicht immer gegeben. Also es gibt einfach-

Genau, macht ja keinen Sinn, wenn im, wenn im, im, im Serverraum, sozusagen im Rechenzentrum das Ding, rausläuft, aber das Kabel hinten hat 'n einer durchgeschnitten. Das bringt nicht viel.

Es gibt einfach tausende Sachen, wie zum Beispiel auch die Uhrzeit. Ist auch jeder Webserver oder jeder Server von mir muss exakt die gleiche Uhrzeit haben, sonst funktioniert das das ganze System irgendwann nicht mehr. Und es gibt tausende Dinge, die man überwachen muss. Und jetzt könnte man sich hinsetzen und einmal am Tag alles durchgehen, alle Server prüfen. Ist auf allen noch die gleiche Uhrzeit? Ist auf allen der Rahmen in Ordnung? Ist auf allen die CPU in Ordnung?

Aber spätestens nach 'm zweiten Tag vergisst man die Hälfte und nach 'm dritten Tag lässt man's sein, weil man da keinen Bock mehr drauf hat.

Ja, ich wollt grad sagen, ja.

Und es gibt so diesen, diesen Leitsatz: Alles, was irgendwann zu Fehlern führen könnte, wird auch zu Fehlern führen. Das ist einfach so. Und wenn, also eigentlich kann es mir nicht passieren, dass meine Festplatten volllaufen, eigentlich. Also da ist eigentlich für gesorgt so, für gesorgt softwaremäßig, aber wenn ich das nicht monitoren würde, also wenn ich das nicht überwachen würde, würden mir meine Festplatten volllaufen. Ich weiß nicht warum, aber sie würden es tun.

Einfach um mich zu ärgern..

Was gibt's da für Lösungen?

Ja, dann, hat man sich umgeschaut wieder: Was benutzen die Großen? Was ist so üblich? Und dann kommt man relativ schnell auf Nagios. Nagios ist auch wieder 'n Serverdienst, den man am besten auf 'nem Server in 'nem anderen Rechenzentrum weit, weit weg stellt, auch physikalisch weit, weit weg.

Einfach damit man auf jeden Fall das monitoren kann, auch wenn in dem, in der einen Stadt 'ne Atombombe einschlägt, dann kriegt man das direkt mit, weil der Monitoring-Server, der ja weit, weit wegsteht, hat hoffentlich noch Internet und kann einen dann Bescheid sagen. Nagios hat 'ne, 'ne GUI, ist praktisch, liefert 'nen Webserver mit praktisch und auf dem kann man sich dann, das anschauen. Das Tolle ist, Nagios kann man erweitern. Nagios, da gibt's 'nen iPhone Client für, für mich ganz wichtig.

Das Ding kann SMS rausschicken, das kann E-Mails, E-Mail-Warnungen rausschicken, sobald irgendwas mit den Webservern ist oder mit allgemein irgend 'nem Server ist. Man kann da tausende Sachen monitoren. Also genau das, was ich gerade eben gesagt hab: Ist 'ne Festplatte voll? Sind noch alle Uhrzeiten korrekt? All diese Sachen, die irgendwann mal zu so 'nem Fehler führen könnten, werden da überprüft und man wird praktisch, informiert.

Man kann verschiedene Gruppen einrichten, die informiert werden. Also bei mir ist es so, ich arbeite ja so 'n bisschen allein, an Feuerwache.net und das ist ja auch 'n Hobby und ja, deswegen, ich bin da alleine.

Genau, weil es gibt ja den Fall, es gibt die Administratoren, die sich um den Inhalt kümmern. Die müssen jetzt nicht nachts um drei Uhr rausgeklingelt werden, wenn der Webserver stirbt, weil sie können nicht viel machen. Also deswegen könntest du 'ne Gruppe einrichten für die Hardcore-Administratoren, die dürfen dann auch nachts geweckt werden.

Genau, und da kann man verschiedenen Leuten verschiedenen Gruppen zuordnen, die dann zu verschiedenen Uhrzeiten geweckt werden.

Arme Administratoren.

Ja, irgendwer muss halt leiden, wenn so 'n Server ausfällt. Deswegen, ja, einfach da Nagios verwenden. Das ist das Nonplusultra. Das möchte man haben. Und das empfehl ich auch, wie gesagt, bei kleineren Webseiten, weil auch da kann es passieren, dass 'ne Festplatte vollläuft und man kriegt es nicht direkt mit. Und dann führt das zu komischen Ergebnissen auf der Webseite.

Man muss erst auch raussuchen, was jetzt das Problem ist, wenn man das einfach monitort und das Ding sagt einem dann schon Bescheid. Das ist das Schönste eigentlich.

Aber Navi, Nagios bedeutet, Kosten einerseits brauche ich wiederum einen neuen Server, wo das Ding drauf läuft und kostet Nagios selbst auch noch was?

Nagios selbst ist wie alle bisher erwähnte Software komplett umsonst. Kann man einfach so benutzen und man muss für Nagios keinen kompletten Server einsetzen. Da reicht auch 'n günstiger V-Server für irgendwie fünf, sechs Euro im Monat. Der reicht da locker für aus.

Ab hackt's beziehungsweise irgendwo bei, bei Freunden oder bei Bekannten mit auf die Kiste 'n virtuellen Host einrichten und ab dafür.

Genau, das funktioniert auch ganz gut.

Das sollte sich einrichten lassen.

Genau. Wenn man dann sein Programm, sein, sein Spiel oder wenn, als ich mein Spiel so weit fertig hatte, fertig ist immer relativ bei so 'nem Spiel, das wird ja immer weiterentwickelt.

Das ist 'ne never ending Story.

Ja, aber wenn man dann an so 'nem Punkt ist, wo man sagt, okay, jetzt läuft erst mal alles so grundsätzlich und ich trau mir ja auch zu, optimal zu programmieren und bei mir ist immer alles toll, denke ich. Ist leider nicht so. Und, das ist leider bei allen Entwicklern so. Also kein Programmierer programmiert auf Anhieb alles perfekt.

Ein ehrlicher Programmierer sitzt neben mir. Ich bin begeistert.

Ja, auch wenn das schwerfällt, so was zu sagen. Nein, und dann, gibt es für die MySQL-Abfragen, die ja in der Regel die meiste Last machen, gibt es das Programm Jetprofiler, das wir auch, wie alle anderen Sachen auch verlinken werden auf Technikwürze. - Jet Profiler ist eine super teure Anwendung, kann aber super viel Kosten einsparen. Und zwar sorgt, zeigt die die Queries an, die am meisten Last auf dem System verursachen.

Das heißt, ich starte Jet Profiler, es verbindet sich zu meiner Datenbank. Man wartet ungefähr 'ne Stunde oder so und dann sieht man genau alle Queries, die viel Last verursachen. Das heißt, wenn man jetzt anfangen möchte zu optimieren, fängt man natürlich bei den Queries an, die die meiste Last verursachen.

Und das zeigt Jet Profiler halt sehr schön an, und ist meines Wissens auch da so die einzige Software, die das in dem Bereich so richtig gut macht und, deswegen kann ich nur Jet Profiler empfehlen.

Genau, also oben läuft so 'n Graph, du hast mir vorhin mal gezeigt. Unten hast du denn 'ne Reihe von Queries, die jetzt grade live in diesem Moment auf dem Server laufen und, wir haben uns das hier am MacBook, jetzt angeschaut. Und ganz oben war halt die, die am meisten Last erzeugt hat. Da war auch so 'n kleines Rankingprogramm, das dir gezeigt hat: „Ja, ist okay, aber, hm, könnte optimiert werden“, so nach dem Motto.

Und, das könntest du dir rausnehmen und gucken: Ja, was wird denn da, wie gesagt, mit welcher Tabelle verknüpft und könntest genau dann da quasi ansetzen, weil du weißt: „Aha, an dieser Stelle, müsste ich vielleicht noch mal 'n Index setzen“, oder was auch immer denn da passiert.

Genau. Dann haben wir jetzt eigentlich erst mal so 'n schönes Setup fertig. Die Webseite läuft. -

Eine Frage noch: Jet Profiler kostet?

Weiß ich so aus dem Kopf nicht, aber ist nicht günstig. Ich glaub ungefähr fünfhundert Euro im Jahr. Aber wer das, wer schon viel Geld in Serverhardware gesteckt hat, und dann eigentlich noch mehr Geld ausgeben müsste, für den kann es günstiger sein, sich einfach den Jet Profiler zu kaufen, und dann zu gucken, wo kann ich denn eigentlich meine Programme optimieren.

Genau, zumindest noch einmal investieren, dann sind die anderen Investitionen nicht für die Katz, wenn da irgendwas abraucht, sondern du hast es dann eben im Überblick und kannst gezielt quasi, Probleme bei MySQL lösen.

Ganz am Anfang stand ja bei mir auch die Frage: Kauf ich mir jetzt irgend 'n System oder miete ich mir irgendwas?

Mhm. Also mieten ist ja so sozusagen der Standard. Also, Webhosting ist klar, Webhosting ganz normal. Da steht 'n großer Server und da kommen viele hunderte Kunden drauf, die sich die Performance dieses einen Servers, teilen. Dann gibt es V-Server, da sind vielleicht 'n paar Dutzend auf so 'nem Server und dann kannst du dir natürlich 'ne eigene, Maschine, mieten, aber das ist dann nicht deine eigene Hardware. Also, w-was sind denn jetzt die Vorteile vom Mieten jetzt mal zusammengezählt?

Ja, mieten machst du ja auch. Das ist sehr günstig. Also man kommt nirgendswo so günstig an geile Maschinen mit viel Rechenpower, da kommt man nirgendswo so günstig dran. Wenn man da irgendwie 'nen großen Massenhoster nimmt, 1&1, Strato, Hetzner und wie sie alle heißen, da kommt man an echt geile Maschinen relativ günstig dran, die dann einfach in irgend'nem Rechenzentrum stehen und auch einfach arbeiten.

Dat Problem ist, wenn so 'ne Maschine ausfällt, dann ist man auf den Support des Hosters angewiesen und ich möchte jetzt keinen Hoster schlecht machen, aber, ich für mich habe festgestellt, dass ich schneller reagiere als irgend'n Hoster. Das heißt, wenn bei mir 'ne Maschine ausfällt, ich habe mich für eigene Hardware entschieden, die ich in irgend'nem Rechenzentrum stehen habe, -

Praktischerweise bei dir relativ in der Nähe, relativ.

Genau, relativ. Ich komme aus Bielefeld und die Rechner stehen in Hannover. Das ist ungefähr 'ne Fahrtstunde, also eine Stunde entfernt. Da kann man noch mal relativ schnell hinfahren und der Vorteil ist halt, ich bin auf mich hier selbst angewiesen.

Das heißt, wenn bei mir 'n Rechner kaputtgeht, abraucht und das ist 'n kritischer Rechner, der muss, da muss jetzt sofort was passieren, dann kann ich mich in mein Auto setzen und kann da hinfahren und kann was machen, kann die, was weiß ich, wenn 'ne Festplatte kaputt ist, kann die Festplatte austauschen.

Also das hört sich jetzt geekig an, aber wenn wir mal ganz ehrlich sind, also die erste Variante wär ja klar, ich hab irgend 'nen Administrator im Endeffekt dann der Dienstleister bei, bei einer Miete und ich ruf den an und sag: „Kümmere dich um das Problem und ich bin zu Hause und, kann Fernsehen gucken.“ Das klingt bequem.

Nur das Problem ist, keiner ge-gewährleistet, wann der Support wirklich reagiert, wann die mal ins Rechenzentrum rübergehen von ihrem Büroplatz beziehungsweise wann die in der Hotline mal im Rechenzentrum anrufen und sagen: „Kümmert euch mal drum.“ Beziehungsweise kann dir auch keiner 'ne Garantie geben, wenn die da 'n Problem feststellen, dass die das gleich lösen.

Das heißt im Endeffekt, auch wenn du erst mal zu Hause bist und sagst: „Ja, alles ist schick und da kümmert sich jetzt theoretisch jemand drum“, ist es vielleicht doch effektiver, wenn du dich ins Auto setzt, brauchst zwar 'ne Stunde Fahrzeit und jetzt grade in der Kälte ist es echt blöd, aber du hast die Gewährleistung, dass du in einer Stunde da bist und du kannst das Problem lösen beziehungsweise bist du dran am Problem.

Genau, ich sitz dann vor den Rechnern und kann dann wirklich was dran machen. Das ist emotional erst mal ganz wichtig, weil wenn man zu Hause sitzt und wartet, dass irgendjemand anderes was macht, das ist schrecklich. Das ist, das ist ein echt schreckliches Gefühl. Die Webseite fällt aus, man kann nichts machen außer warten und dann dauert das. Dann, dann ist vielleicht grade Samstagnachmittag und der Support arbeitet erst wieder Montagmorgen.

Genau, vielleicht erzähl ich noch mal kurz von unserem Technikwitz-Problem. Wir hatten ja Ende letzten Jahres, massive Probleme mit unserem Server. Das werdet ihr auch, gemerkt haben, dass, Technikwitz oft nicht erreichbar war. Die Folgen waren nicht erreichbar. War für uns natürlich 'ne Katastrophe, weil wir nur einen Server hatten und, wir haben dieses Mietmodell gewählt und, - Sind derzeit noch bei 1&1 verhaftet, haben da 'n Root-Server stehen.

Das Problem ist, dass die Konstellation beim Service und grade bei 1&1 so katastrophal ist, dass die sagen, : „Ja, ja, also du als Administrator bist für die Kiste selbst verantwortlich und du musst dich drum kümmern,, und analysieren, was da kaputt ist.“ Das heißt also, ich hatte dich mal konsultiert.

Das war so die, die Phase, wo wir uns quasi übers Netz kennengelernt haben und du hattest so 'n, so 'n, nachdem wir so ein, zwei Programme haben laufen lassen, irgendwie den Verdacht, es könnte der Speicher sein. Nur so 'n Speichertest physikalisch quasi mit der Software kann man nur machen, wenn der ganze Webserver runterfährt. Man fährt die Konsole hoch. In dieser Zeit ist nichts erreichbar außer die Konsole. Man loggt sie auf der Konsole ein und kann dann 'n expliziten, Test machen.

Jetzt sagt 1&1 natürlich: „Du musst mir als Kunde beweisen, dass der Defekt jetzt der Speicherriegel ist, weil wir das vermutet haben.“ Und erst wenn wir das bewiesen haben durch einen Log, was wir mitgelaufen lassen haben, dann, geht der 1&1 Support dran und sagt: „Okay, ihr habt uns das bewiesen. Wir g...

schaffen jetzt ins Rechenzentrum und tauschen die Dinger aus.“ Das ist natürlich verbunden dadurch, dass die Kommunikation, es wechseln die Mitarbeiter, die gehen ja auch irgendwann nach Hause, der muss du's 'nem anderen erklären und die warten auf dich oder du wartest auf die. Das war bei uns 'ne völlige Katastrophe mit dem Support. Also da hätt ich mich am liebsten auch irgendwo in, 'ne Stunde, ins Auto gesetzt, 'ne Stunde hingefahren und hätt den Speicherriegel selbst getauscht.

Das wär schneller gegangen.

Ja, und das ist halt das Problem. Und deswegen hab ich mich halt für eigene Hardware entschieden, weil da bin ich im Prinzip, dann selbst mein Mann und kann da hinfahren, kann da an der Maschine arbeiten. Das geht im Zweifelsfall einfach schneller, als wenn da irgend'nen Dienstleister das für mich macht., 'n zweiter Vorteil ist auch und der ist für mich ganz wichtig, ich hab ja vorhin schon erzählt, ich habe zwei Netze bei mir.

Ich habe an jedem Rechner von mir mindestens zwei Netzwerkkarten, einmal 'ne interne und einmal 'ne externe. Intern ist wie gesagt ein total sicheres Netz, da passiert nichts drüber. Also da passieren die interne Kommunikation drüber, die ist nicht verschlüsselt. Meine Server vertrauen sich, wenn sie über die interne Kommunia-kommunikation irgendwelche Daten bekommen, die vertrauen denen. Ist, ist halt mein internes Netz. Dann hab ich 'n externes Netz. Das ist das böse, böse Internet.

Darüber kommen die Tausenden von Angriffe auf die Webseite, darüber kommen MySQL-Angriffe, da, tausende Angriffe, was man sich nur vorstellen kann, was im Internet halt üblich ist, das passiert übers externe Netz.

Genau, Internet ist doof.

Genau, das wird abgehört, da passieren so viele Sachen, das will man alles nicht. Und deswegen, wenn meine Server untereinander kommunizieren, die dürfen sich vertrauen, die dürfen übers interne Netz reden. Da brauch ich mir keine Gedanken um Sicherheit zu machen. Das wäre bei dir, David, wenn du dir jetzt überlegst, ich hol mir jetzt bei 1&1 'nen zweiten Server.

Also entschuldigung, ich werd nicht mehr bei 1&1 mir 'n Server bestellen, aber nehmen wir's mal an.

Genau. Wenn du dir bei 1&1 'nen zweiten Server bestellen würdest, dann könntest du auch interne Dinge, die die Webserver untereinander aushandeln sollen, nur über das Externe, das heißt über das Internet, übertragen. Das heißt, du müsstest das noch mal extra verschlüsseln, weil darüber können ja sensible Daten übertragen werden. Die soll ja keiner mitlesen. Du hast 'n massives Problem. Also das-

Genau, also das Problem vor allen Dingen nicht nur, dass ich mich um die Sicherheit kümmern müsste, sondern ich musste auch, wie gesagt, gewährleisten, dass, 'ne Überprüfung stattfindet. Ist dieser Request jetzt autorisiert? Bla, bla, bla, bla, bla. Das heißt, da fäng..., da, da ist schon wieder 'ne Instanz drin, die Performance fressen könnte. Also bringt mich an dieser Stelle, auch nicht weiter.

Ja, genau. Also man sieht, eigene Hardware hat total viele Vorteile, wenn man 'ne größere Seite haben möchte oder wenn die Seite irgendwann mal größer wird. Wenn man jetzt sagt: „Okay, ich hab jetzt meine kleine Seite irgendwo“, dann ist es natürlich günstiger, wenn man sich irgendwo was mietet. Aber ist halt immer die Frage, was man möchte, wo man hinaus möchte.

Und deswegen, ich hab halt früh für mich gesagt: „Okay, das wird 'n ganz großes Ding, feuerwache.net“, was dann ja auch zum Glück geworden ist. Hab mich dann für eigene Hardware entschieden und bin damit immer richtig gefahren.

Also ich hatte damit nie Probleme, weil es gibt ja auch noch, hab ich vorher gar nicht, vorhin gar nicht erwähnt, den Fall: Ich hab ja meine eigene Hardware, das sind ja alles meine Rechner, aber ich kann ja trotzdem bei mir im Rechenzentrum anrufen und kann dem Mitarbeiter sagen: „Du, an der und der Kiste ist der RAM-Riegel kaputt. Geh da doch mal hin und bau da 'nen neuen ein.“ Das kann ich natürlich trotzdem machen. Im Rechenzentrum sitzt natürlich trotzdem jemand.

Ich kann denen 'nen Auftrag geben. Gut, ich muss den dann bezahlen in der Zeit, wo er das macht. Aber, klar, die Möglichkeit besteht natürlich weiterhin.

Wäre 'ne Option für deine Hochzeit. Also wenn 'ne Hochzeit läuft, dann würd ich jetzt vielleicht nicht unbedingt den Server retten wollen, sondern eher die Ehe, die anstehende.

Genau. Oder ich war Anfang des Jahres in China, - Das ist dann schwierig mit mal grade eben zum Server hinlaufen, um da mal irgendwas zu machen. Da nimmt man so was natürlich gerne in Anspruch.

Genau. Problem ist nur weiterhin, also ein riesengroßes Problem, worüber wir noch nicht großartig geredet haben, ist das Backup, also Datensicherheit.

Genau. Also für mich und für meine Spieler ist es natürlich ultimativ wichtig, dass auf gar keinen Fall irgendwie 'n Spielstand wegkommt.

Oh, oh.

Wie schlimm wäre das, wenn jetzt heute Abend da irgend'ne Festplatte von 'nem Datenbankserver kaputtgeht oder beide Festplatten, weil das ist natürlich, gemirrored auf 'm RAID-System. Wenn da zwei Festplatten heute Abend kaputtgehen würden und aus irgend'nem Grund, also die, die Festplatten gehen einfach kaputt auf meinem RAID-System und ich hätte kein Backup.

Genau, das Problem ist dabei, der User, der verkraftet vielleicht mal 'n kleinen Serverausfall, wenn er nachher weiterspielen kann, aber wenn seine Spielstände weg sind oder seine Daten weg sind, dann sagt er sich: „Ich hab jetzt so viel Arbeit investiert in dieses Spiel, was echt cool ist, aber die Daten sind weg. Ich komme nie wieder.“ Und dann hast du 'n Problem als Betreiber.

Genau, weil ich möcht ja nicht, dass meine User mir weglaufen und wenn ich kein Backup hätte, wären sie weg. Und deswegen Habe ich mich dafür entschieden für 'nen, wie ich glaube, recht sicheres Backup-Konzept. Und zwar fahr ich einmal am Tag von allen meinen Daten, die irgendwie wegkommen könnten, wenn irgendwas kaputtgehen würde, Backup. Das heißt, alle von Spielern hochgeladenen Bilder werden gebackupt. Alle, die komplette MySQL-Datenbank wird einmal am Tag komplett gebackupt.

Aber das ist selektiv und nicht mach mal die ganze Platte.

Doch. Nein, natürlich. Klar, selektiv. Richtig, du hast recht. Das wird alles auf einem Server im gleichen Rechenzentrum noch mal gespeichert. Dafür steht da extra eine Maschine. Die hat noch mal 'n schönes Raid-System und da werden einfach erst mal nur Backups hingeschieben, geschoben, einmal am Tag.

Was, was innerhalb eines Rechenzentrums, in diesem Falle auch Sinn macht, denn würdest du das jetzt ins Externe schicken, würden ja wieder Traffic-Kosten entstehen, die vielleicht intern nicht entstehen würden. Ist auch 'n Kostenfaktor. Aber du hast trotzdem noch auf 'ne externe Lösung gesetzt.

Genau, ich backupe zusätzlich noch mal in eine andere Stadt. Wie gesagt, Server stehen hier in Hannover. Ich backupe zusätzlich noch mal nach Berlin, nach Strato. Einfach weil ich sicher sein möchte, dass wenn bei mir im Rechenzentrum, was sehr, sehr unwahrscheinlich ist, aber was weiß ich, da platzt 'n Rohr da drüber oder irgendwas passiert da.

Da läuft Wasser ins Rechenzentrum, da brennt's drin oder so und alle meine Server da gehen kaputt, dann ist das zwar super ärgerlich für mich, aber es wär noch viel, viel schlimmer, wenn meine Daten weg wären. Weil diese Maschinen, die Server kann ich zur Not relativ einfach neu kaufen. Kostet viel Geld, keine Frage, aber ich könnte sie neu kaufen. Aber meine Daten könnt ich nicht neu kaufen, weil die hab ja nur ich.

Richtig, mhm. Die wären unru-- Genau, mhm.

Und deswegen hab ich mich dafür entschieden, noch mal zusätzlich diese kompletten Daten, die ich jeden Tag backupe, auch noch mal in 'n externes Rechenzentrum zu schieben. Das kostet Traffic, richtig. Das kostet also im Endeffekt Geld, aber mir ist es das Geld wert, weil ich möchte nicht hinterher dastehen und habe kein Backup, wenn irgendwann mal was passiert.

Genau, weil derzeit funktioniert das Businessmodell für dich sozusagen. Aber sofern die User wegbrechen, weil die Daten weg sind, dann kannst du auch kein Geld mehr damit generieren und dann ist es für die Katz. Also das ist immer so, man muss was investieren, um es sicher zu haben, ja.

Genau, also man könnt das jetzt natürlich noch größer machen. Man könnte sagen, okay, zwei Backups reichen mir nicht, ich möchte noch ein drittes Backup dazu haben. Aber ich glaube, dass wenn in Hannover 'ne Atombombe einschlägt und in Strato, bei, in Berlin 'ne Atombombe einschlägt, dass es dann relativ uninteressant ist, das Spiel weiterzubetreiben.

Aber prinzipiell, wenn in einem dieser beiden Städte irgendwas passiert, muss ja jetzt nicht die Atombombe sein, aber wenn da irgendwas passiert, dann kann ich mit der anderen Stadt weiterarbeiten und kann prinzipiell das Spiel aufrechterhalten.

Okay, ich denke, du hast uns 'n Super Überblick gegeben, zur Entstehungsgeschichte. Wie, wie ist es dazu gekommen? Was ist auf deiner Webseite passiert und was für Lösungen es gibt. Also magst du's noch mal zusammenfassen? Was ist dein Fazit grundsätzlich oder deine Empfehlung für die Technikwitz-Hörer, die jetzt langsam merken: „Oh, oh, ich hab hier 'ne coole Anwendung und langsam geht's mit der Performance runter. Was tun?“

Genau, also wenn man merkt, man hat die große Web 2.0 Anwendung entwickelt, man hat das neue Twitter erfunden, dann sollte man sich frühzeitig Gedanken machen. Das heißt, man sollte frühzeitig auch schon bei der Programmierung eventuell dran denken: Okay, wo kann ich jetzt hier was parallelisieren? Was kann, darf parallel laufen und was darf auf gar keinen Fall parallel laufen? Dann sollte man sich immer umgucken: Was machen denn die anderen?

Also es gibt viele, die das öffentlich machen, zum Beispiel Facebook, die haben 'nen Developer Blog, da kann man sehr, sehr viel lernen. Das heißt, da einfach mal gucken, was machen denn die Großen? Wa-- Welche Techniken setzen die ein? Und soll ich die vielleicht auch für mich einsetzen?

Genau, und bei den Großen lohnt sich zu gucken, weil die haben so viel Last auf den Kistchen, die werden sich schon für das Richtige entschieden haben.

Genau, man muss das natürlich, man muss natürlich immer noch mal für sich selber gucken: Ist das auch für mich das Richtige? Aber im Regelfall, wenn die Großen das machen, dann sollte man das auch machen, weil die haben das nicht ohne Grund gemacht. Und dann kann ich auch nur sagen: hochwertige Hardware kaufen. Habe ich am Anfang auch nicht gemacht, geb ich ganz offen zu, weil ich wollte am Anfang auch sparen.

Weil man kann natürlich 'n Server kaufen, den baut man aus Desktop-Komponenten zusammen. Das heißt, man fährt im Zweifelsfall zu seinem nächsten PC-Laden um die Ecke, kauft das günstigste Mainboard für neununddreißig Euro, kauft 'ne CPU für, da gibt man ja 'n bisschen Geld für aus, gibt hundert Euro für aus, dann kauft man so 'n bisschen RAM und dann hat man irgendwann so 'ne Maschine, die kostet dann so dreihundert Euro oder wenn man viel Geld ausgibt, vielleicht auch vierhundert Euro.

Das Problem ist: Ja, das funktioniert, im Endeffekt kauft man aber doppelt. Jeder von uns hat es schon mal erlebt, dass er irgendwas gekauft hat und sich dann hinterher geärgert hat, dass er nicht gleich das gute Modell gekauft hat, weil ja, man kauft doppelt im Prinzip. Mittlerweile kaufe ich nur noch Server-Hardware, die ist schweineteuer, aber die ist auch schweinegeil. Also ich hab da mittlerweile 'nen, 'nen Produzenten, also 'nen Hersteller gefunden, dem ich da sehr vertraue.

Das ist 1heserver.com. Die stellen Server zusammen, aus professionell und guten Komponenten. Kann ich nur empfehlen, weil einfach, da ist es so, dass die Wahrscheinlichkeit, dass es kaputtgeht oder ausfällt, wesentlich geringer ist und die einzelnen Komponenten wesentlich, bessere Geschwindigkeiten bringen. Man glaubt ja immer so: Ja, die CPUs ungefähr so sind die alle gleich schnell, aber das ist nicht so. Also wenn man Server-Hardware kauft, das ist noch mal deutlich schneller.

Es ist Aufm Papier ist das nicht deutlich schneller. Also das ist gleich getaktet, das funktioniert gleich, das hat gleich viel RAM. Das ist eigentlich müsste's gehen, aber ja, geht nicht und deswegen, bin ich da immer nur froh, dass ich da mittlerweile Serverhardware kaufe, die echt gut ist und das kann ich auch nur empfehlen.

Das heißt, jeder sollte sich wirklich Gedanken machen, was für Stichpunkte gibt es? Ich denke, wir haben heute 'ne ganze Menge angesprochen von Sachen, auf die man achten sollte. Das Monitoring zum Beispiel ist nicht, unwichtig, nachdem man da tolle Hardware stehen hat. Auf jeden Fall, lesen, was machen die anderen, informieren, auch in diesem Podcast und, ja, dann wird das schon laufen, denk ich.

Ich denke auch.

Okay, dann, bedanke ich mich dafür, dass Du da warst. Fand ich sehr interessant. Sebastian Heine, dein Name, Webseite feuerwache.net. Wenn dich das interessiert und ihr seid vielleicht Feuerwehrmann, oder euch interessiert das grundsätzlich, klickt mal rein. Ansonsten bedanke ich mich dafür, dass Du da warst und, ja, vielen Dank.

Ja, ich bedanke mich auch. Und oberstes Ziel ist natürlich immer, dass man die Technik nicht, nicht merkt, die im Hintergrund läuft. Das heißt, wenn ihr jetzt feuerwache.net spielt oder euch da anmeldet, dann hoffe ich, dass ihr niemals mitkriegt, dass da im Hintergrund ein Memcache läuft, dass da vorne 'n Pound läuft, 'ne Leiter. Das braucht ihr alles gar nicht merken. Und wenn das eintrifft, wenn das kein Spieler mitkriegt, dann hab ich alles richtig gemacht.

Schönes Schlusswort. Damit wünsche ich euch viel Spaß, mit Beginn der neuen Woche. Bis dahin, bye bye. Ciao.

Mehr Qualität im Webdesign durch Webstandards. Tipps und Tricks zur Umsetzung findet ihr bei den Webkrauts auf Webkrauts.de. Für ein besseres Web. Weitere Informationen und die Links zur Sendung auf Technikwürze.de.