Kenne das seit Classic, als Vanilla noch Retail war. Also von daher inhaltlich korrekt was du schreibst, nur anders als du es meintest. Es war damals nur nicht so groß wie heute.
LG
Flauschkugel
2 Likes
Ja, freilich - im besonderen RP’ler (was ich ned bin) können mit der Entscheidung zwischen Pest und Cholera leben.
Ich wäre dann bei dir, wenn die Prämissen, welche zu einer Entscheidung führen selbstbestimmt „falsch“ sein können.
Ich stimme dir dahingehend vollkommen zu, dass es suboptimal ist auf einen Mega-Server freiwillig zu transen.
Leidtragende sind aber alle auf dem Realm.
1 Like
So gesehen ist es das ja auch.
Den mal nüchtern betrachtet hätte man das anhand der Trans-Ziele merken können auf was es hinausläuft. Und wenn man sich dann anschaut wie die Trans-Ziele ausgelastet sind sollte es dann eigentlich klar sein was passieren wird.
Was aber auch nicht bedeutet das nur eine Seite die Schuld trägt. Blizzard hätte in dem Moment wo der Server die kritische Menge überschreitet einfach den Trans sperren können. Hätte am Ende aber auch nur wenig geändert weil nur diejenigen betroffen gewesen wären die nach der Trans-Sperrung dort noch hätten hin wollen. Alle die aktiv im Transfer befindlichen Chars wären dann trotzdem auf dem Server angekommen.
Ändert nichts daran, daß es zu wenig PvE Server in Deutschland gibt.
Zb ein Fresh Realm für DACH wäre top gewesen.
Aber nö wenn interessiert in US schon ein Markt für 30 Millionen von 12 bis 42.
Oder überhaupt EU
1 Like
Es gab vor einer Weile einen Bluepost dazu, in dem grob erklärt wurde, worin die Limitierung besteht. Das Problem liegt gar nicht mal an der Leistungsfähigkeit der Hardware, sondern hauptsächlich an der Datenbank, die zu jedem Realm gehört. Die hat schlicht softwareseitig ein Limit, wie viele Anfragen diese noch in „Echtzeit“ abarbeiten kann. Und vollen Server erreichen mittlerweile dieses Limit.
Und jede Software hat, egal wie gut sie programmiert ist, irgendwelche Limits, die man auch nicht mit mehr Rechenleistung umgehen kann. Beispielweise kann auch jeder Webserver nur eine bestimmte Anzahl an Seitenaufrufen verzögerungsfrei stemmen, egal auf welcher Hardware der läuft.
Damit das Limit der Datenbank also nicht überschritten wird, lässt man nur so viele Spieler gleichzeitig auf den Server, wie die Datenbank noch verkraftet und alle weiteren Spieler werden in die Warteschlange geschoben.
Theoretisch könnte man auch die Warteschlangen abschalten und alle Spieler drauflassen, die drauf wollen. Das würde aber eben dazu führen, dass eben die Abfragen in einer internen Warteschlange der Datenbank landen würden, was sich dann als (größere) Lags im Spiel bemerkbar macht. Man würde also nur eine sichtbare Warteschlange gegen Lags tauschen.
2 Likes
Ich muss mir keine Kugel geben, da ich bereits eine BIN 
aber danke, dass du den Post wieder gelöscht hast- solltest vorsichtig sein, wem du sowas sagst. Doof nur, dass die Moderation sehen kann, was da vorher stand. Zu deinem Glück sind die grad anderweitig überfordert
LG
Flauschkugel
5 Likes
joa bei denen darfst du dann in 6 Monaten wahrscheinlich kostenpflichtig transen, das ist doch das Problem warum sich niemand darauf einlässt, die Leute kennen es aus BC.
1 Like
Dafür gibt es Lösungen, wie zum beispiel geclonte Datenbanken, ist eine ausgelastet, wird die 2. benutzt usw, was eine Limitierung der Lesevorgänge eigentlich unmöglich macht. Sollten die Schreibvorgänge das Problem sein, ist es aus meiner Sicht tatsächlich ein Problem, hier würden nur Caches Abhilfe schaffen. Da fehlt mir bissel die Erfahrung wie man es genau löst aber Facebook und Co bekommt es ja auch hin und da gibt es ein vielfaches der Abrufe.
Ich denke nicht dass dieses richtig ist, ich bin zwar kein Administrator aber genau an deinem Punkt setzt eine DDOS Attacke an und der begegnet man mit mehr Leistung.
Wie so oft 
Fleißig am Ratschläge geben aber dann doch kein plan. Ah Bruder einfach clonen gg
1 Like
ja Bruder genauso machen wir es, wir haben 2 Datenbanken , ist eine ausgelastet oder fällt aus nehmen wir die 2. dazu. Zusätzlich haben wir viele Caches. Mir fehlt bei zu vielen Schreibvorgängen der Plan weil ich vor dem Problem noch nie stand es hier aber durchaus sein kann, wenn einer seine 1 Million Stoffe einzeln einstellt und das alle 10 Minuten x etliche Spieler, lastest du die DB mit zu vielen Schreibvorgängen aus. Und das Problem kannst du nicht mit mehr Dbs lösen, wohl aber könntest du Caches nehmen um die Leistung massiv zu erhöhen und es zeitverzögert in die DB schreiben.
Da fällt mir auf wieso bist du nicht auf Igno ? Ach ja weil bei Blizz letztens mein Profil zerschossen wurde und sich meine Ignoliste in Luft aufgelöst hat. Das werde ich jetzt aber fix ändern :D.
Verdammt wieso kommen da die ganzen renommierten Programmierer nicht drauf?
Da müssen erst die genies von der VHS Marzahn kommen
Meld das doch mal weiter wie leicht das geht
2 Likes
Sorry machs gut mein Freund und bleib sauber ;D.
1 Like
Stichwort Echtzeit.
Facebook und Co arbeiten nicht mit Echtzeit-Datenbanken wie es ein MMO macht. Bei denen ist es egal ob ein Schreib- / Lesevorgang 1s oder 1min dauert.
Bei einem MMO sieht das wieder anders aus. Da kann man auch nicht mit einem Cache oder einem Klon arbeiten. Ersteres hat das Problem das es nicht in Echtzeit Events auswerten kann und zweiteres muss immer in Sync mit dem Master gehalten werden was einen entsprechenden Overhead produziert der einem bei einer entsprechenden User- oder Transaktionsmenge auf die Füße fällt, Mal abgesehen von der zusätzlichen Technik die man dafür braucht.
Nicht ganz… GFN AG in Alt-Moabit 
Kannst deinen Post löschen wie du willst.
Blzzard hat den Post vorher schon eh komplett zu Gesicht bekommen. 
pp
Kommt auf die Art des DDOS an, ob und welche Gegenmaßnahmen da helfen. Versucht der DDOS einfach deine Rechenleistung voll auszulasten, schaltest nach Möglichkeit mehr Server dazu mit nem Loadbalancer davor, der die Last auf die Server verteilt.
Versucht der DDOS aber dein Netzwerk oder gar die Außenanbindung vom Rechenzentrum mit einer entsprechend hohen Datenmenge zu überlasten, hilft es auch nichts, da hinten dran mehr Server hinzustellen. Dadurch wird aus der 10 Gbit Leitung ja keine 100 Gbit Leitung. Da hilft dann nur, die Datenpackete möglichst früh zu verwerfen. Im schlimmsten Fall musst du dann sogar den Traffic von deinem Transit-Provider (und der wiederum von seinem Transit-Provider) blocken lassen, so dass es am Ende quasi internetweit geblockt wird.
1 Like
Dunning-Kruger ist mittlerweile eine Volkskrankheit.
Jedes Kommentar muss zeitnah da sein, es ist nicht egal ob das ne Minute dauert. So ist es beim Ah ebenfalls. Ebenfalls ist der Zeitfaktor bei Facebook auch bei den Lesevorgängen sehr wichtig. Erst mal um von Google nicht abgewertet zu werden im Ranking und niemand will ne Minute auf seine Seite warten.
Warum kann das nicht in Echtzeit einen Lesevorgang anfordern ? Mit den Schreibvorgängen ist es ja klar das du durch den Sync Overheads produzierst und ?? Warum sollte dir das auf die Füße fallen ? Warum kann man nicht mit einem Cache arbeiten ? Deine Aussagen sind sehr allgemein, bis auf die Mehrbelastung duch die doppelten Schreibvorgänge bist du doch sehr wage geblieben. Ich denke das die Schreibvorgänge egal sind dabei ist es tatsächlich egal ob die Auktion erst nach 2 oder 3 Sekunden auftaucht, ich würde deutlich der Optimierung der Lesevorgänge den Vorzug geben. Den Cache könnte man so regeln, das alles aus dem Cache in einer Backgroundqueue in die DB geschrieben wird, diese Queue sollte auf einem anderen Server laufen, damit im Falle des Falles die Daten aus dem Cache nicht verloren gehen. Ich sehe da kein technisches Problem aber ja es wäre aufwendig.
Das ist richtig, trotzdem arbeitet Facebook nicht mit Echtzeitdatenbank. Man kann auch ohne sehr zeitnah Kommentare auftauchen lassen und hat nicht mal ein Downranking bei Google. Letzteres ist bei solchen Geschossen wie Facebook und Co eh irrelevant weil die schon an der Spitze des Rankings stehen.
Du sieht halt nur das AH in WoW und ganz ehrlich? Das AH ist in der Hinsicht mal vollkommen egal. WoW braucht wegen ganz anderer Sachen schon die Echtzeitdatenbank.
Alleine Charakterpositionen, Events, Kampfabläufe, Buffs, Debuffs usw werden alle in teilweise temporär oder dauerhaft in den Datenbanken der Server gespeichert. Alleine schon die temporäre Speicherung braucht hier eine Echtzeitdatenbank um die Verläufe akkurat wiederzugeben. Ganz platt gesagt bringt es nichts wenn man in einem Kampf steckt und aufgrund von einer gecachten DB oder mehreren Klonen der DB der Kampfverlauf verzögert dargestellt wird weil die Aktualisierung der DB ewig brauchen. Da hilft dann auch der schnellste Cache oder RAM-DB nichts weil dann wieder der limitierende Faktor der Hardware dazukommt.
Da bleibste aber nicht wenn die Leistung deiner Webseite nicht stimmt, du wirst dann abgewertet.
klar es ging auch nur ums Ah darauf habe ich geantwortet.
Denke ich auch nicht, für die Echtzeit ist ein Cache wesentlich besser geeignet als eine Datenbank. Eine Datenbank ist mehr für dauerhaftigkeit als für Geschwindigkeit. Denn gegenüber einem Cache ist eine Datenbank enorm langsam.
Den Punkt möchte ich anzweifeln, natürlich limitiert irgendwo die Hardware nur wo das ist kann niemand von uns beiden genau bestimmen.
Ich persönlich würde es auch so regeln, das jeder Client seinen Char selber verwaltet. Was wohl zu einer relativ geringen Serverauslastung führen dürfte. Ich denke auch nicht dass das meiste zeitkritisch geschrieben werden muss, zumindest nicht in DB, warum sollte ein Cache dafür nicht ausreichen. Ebenfalls ist eine Db auch von Hardware abhängig, denn die Zugriffe fressen ebenfalls Leistung, also könnte man anbringen das bei der Db der limitierende Faktor ebenfalls die Hardware ist .
Zeitkritische Sachen in einer Db zu verwalten halte ich für nicht sinnvoll. Weil einfach viel zu langsam, mehr Ram für den Cache geht fast immer.
Aber selbst wenn!
Instanzserver sind so groß dass die Hardware nicht der limitierende Faktor wird. Macht ja auch irgendwie Sinn. Gleiches gilt Für die Server mit den Spielern.
Man merkt du hast noch nie mit Echtzeitendatenbanken gearbeitet. Da das Thema an sich zu umfangreich ist für das Forum und so eh nicht zu dem Thema gehört, lass ich dir einfach mal einen entsprechenden Link da, welcher das sehr gut erklärt.
https://wiki.edu.vn/wiki14/2020/11/27/echtzeitdatenbank-wikipedia/Der Punkt läßt sich sehr einfach bestimmen und liegt dort wo das maximal mögliche an zeitgleichen Zugriffe auf die Daten ist. Bei einer Cache basierten Datenbank ist der limitierende Faktor das Speichermedium auf dem der Cache liegt und Enterprise-Grade-SSDs mit entsprechenden Speicherumfang und Schreib-/Lesegeschwindigkeit sind auch nicht an jeder Ecke erhältlich. Derzeit ist Kyoxia der Hersteller der in der Hinsicht optimierte Datenträger anbietet.
Nutzt man dahingehend eine RAM-DB ist es der RAM und die Schnittstelle zum RAM die limitiert, aber eher der RAM weil er dem, salopp gesagt, irgendwann die Puste ausgeht. Spätestens tritt das ein wenn die zulässigen Max-Geschwindigkeiten nach JEDEC überschritten werden.
Welcome to Cheating-Heaven.
Das würde dem Cheating Tür und Tor öffnen, da dann findige Spieler einen Weg suchen und diesen zu 100% finden werden wie man etwaige Sicherheitsmaßnahmen umgehen kann welche die Chardaten schützen sollen um das zu vermeiden.
Was du für sinnvoll hälst oder nicht ist hier nicht relevant, da das Produkt und dessen Anwendung die Richtlinien vorgibt wie man etwas konfiguriert und betreibt. In einem MMO liegt es halt nunmal in der Natur der Sache das viele Daten in Echtzeit verarbeitet werden müssen. Und man kann auch nicht unendlich mehr RAM zur Verfügung stellen wenn man das will, irgendwann macht das System auch einfach dicht und man wird auch hier durch die Hardware limitiert, alleine schon weil es nur bestimmte Größen an RAM-Modulen gibt.
Nicht klein denken wie im Rahmen für einen P-Server der nur wenige Spieler hat, hier muss man deutlich größer denken. Sieht man doch an LK Classic, da können bis zu 30k Spieler auf einem Server sein und Blizzard nutzt schon State of the Art Hardware von HP und Dell und trotzdem bekommen sie die Queues nicht gestemmt weil die Limitierungen der Software und Hardware greifen.
Wenn man sich mit sowas beschäftigt darf nicht im kleinen Maßstab von ein paar Hundert oder Tausend denken …