Maßnahmen gegen Laags

[damh]

Hmm *g*

Der Vorschlag von Suspicion funktioniert an sich schon. Dafür muss man allerdings transaktionssicher vorgehen. D.h. entweder einen monolitischen Server benutzen (1 Prozess (keine Threads) macht die Arbeit des Webservers(hier Apache), der Spieleengine(Nightfire Browsergames Engine) und der Datenbank (MySQL). Sofern man nur einen Prozessor im Server hat ist dies nachweisbar die besten Variante.
Variante 2 ist, dass man die Prozesse/Threads gegenseitig synchroisiert. Diese Variante ist mit heutigen Schedulern ziemliche Zeitverschwendung. Es fängt erst an sich zu lohnen, wenn man wirklich viele Prozessoren zur Verfügung hat und fast nicht synchronisieren muss. Da diese Variante extrem viel Ahnung erfordert um effizient zu werden, kann man diese Variante getrost in den Müll werfen, da fast nie durchsetzbar.
Variante 3 ist, dass man zumind. die Datenbank monolitisch auslegt. Dazu ist es allerdings erforderlich, dass man die Transaktionen immer mit einem "Befehl" komplett abschließt, da sonst wieder selbige Sychroniationsprobleme auftreten wie oben beschrieben.
Ein Befehl(Spieler A will 50 Wakrudpilze an Spieler B geben) sieht dann inetwa so aus(Pseudobefehle ):
"1. Nehme Spieler A 50 Wakrudpilze ab; 2. Gebe Spieler B 50 Wakrudpilze"
Kann ein Teil davon nicht ausgeführt werden, wird die Transaktion ohne Änderung der Datenbank abgebrochen. Ein Beispiel wäre, wenn Spieler A z.B. keine 50 Wakrudpilze besitzt bzw. Spieler B (aus welchen Gründen auch immer) keine 50 Wakrudpilze aufnehmen kann.
Dieses Beispiel ist extrem vereinfacht (normal müssen deutlich mehr Nebenbedingungen geprüft werden wie z.B. Befinden sich beide am selben Ort, ...)

Achja, Variante 1 ist für die meisten Leute und Server die beste Wenn man sich viel Mühe gibt, kann man diese Variante auf Teilaspekte von 2 erweitern. Dies bringt aber im allgemeinen mehr Arbeit als Nutzen, da halt kaum jemand mehr als 1-2 Prozessoren hat. Wenn die Prozesssoren eben nicht unabhängig arbeiten können, stehen die Mehrzahl halt im Wartemodus und man gewinnt halt effektiv nichts außer größere Programme, teuerere Server und mehr Programmieraufwand.

Gruß damh

[Suspicion]

darüber denk ich dann jetzt erstmal nach... *nicht viel verstanden hat*

hab ich das jetzt richtig mitgekriegt, dass meine idee wohl nicht zu weniger lags führt, weil die db eher mehr beansprucht wird?

und warum beantwortet niemand, wie das mit den Goldmünzen in FW gehandhabt wird? xD

[damh]

Geld auf einem Feld, ist ein Item.
Beim Übergeben und sonst keine Ahnung.

hab ich das jetzt richtig mitgekriegt, dass meine idee wohl nicht zu weniger lags führt, weil die db eher mehr beansprucht wird?

nein, wenn man Variante 1 nimmt, gibt es anschließend keine Datenbank mehr. Man spart dadurch bei korrekter Programmierung enorm viel Zeit.
Das Spiel insgesamt sollte flüssiger laufen. Jenachdem wie man die Backups löst und worauf man dort Wert legt, kann es zu diesen Sonderzeiten schon aus Sicherheitsgründen zu Lags kommen, da man solange halt den Webserverdienst einstellt. Alternativ muss man nur ein Dump machen und die Daten sukzessive auf den Backuprechner übertragen. Dies würde den Spielern weniger auffallen, kommt es allerdings zu einem Fehler muss u.U. das vorletzte Backup herhalten.
Es gibt in dem Bereich keine allgemeine optimale Lösung. Man muss halt abwegen, ob man schnell einen "sicheren" Zustand erreichen will oder ob man lieber nach außen hin gut erreichbar ist.

Da es sich bei den Items+Userdaten+Weltdaten aber nur um sehr kleine Mengen nicht redundanter Information handelt, kann man diesen Teil recht schnell erledigen.

Von den Profilen braucht man eigentlich gar kein Backup, da die Spieler sowieso die letzte Version im eigenen Intresse privat sichern sollten.

Chat und Transaktionen sind auch eher unwichtig, sobald man einen kompletten Zwischenstand gespeichert hat. Diese können nur für Multi/Bot/AGB-Verfolgungen intressant sein bzw. allgemein wenn irgendwas nicht stimmt.

Was hast Du denn nicht verstanden?

Gruß damh

[Suspicion]

Hmm *g*
D.h. entweder einen monolitischen Server benutzen (1 Prozess (keine Threads) macht die Arbeit des Webservers(hier Apache), der Spieleengine(Nightfire Browsergames Engine) und der Datenbank (MySQL). Sofern man nur einen Prozessor im Server hat ist dies nachweisbar die besten Variante.

Bin noch nicht im klaren, was genau unter ienem Prozess zu verstehen ist und monlitisch hab ich noch nie gehört

Variante 2 ist, dass man die Prozesse/Threads gegenseitig synchroisiert. Diese Variante ist mit heutigen Schedulern ziemliche Zeitverschwendung. Es fängt erst an sich zu lohnen, wenn man wirklich viele Prozessoren zur Verfügung hat und fast nicht synchronisieren muss. Da diese Variante extrem viel Ahnung erfordert um effizient zu werden, kann man diese Variante getrost in den Müll werfen, da fast nie durchsetzbar.

Da gehts jetzt wieder um Prozesse und Threads, aber auch noch um Scheduler... Glaub ich fahr mir mal nen Buch über Prozessoren ausleihen, muss ich ja eh bald lernen...

Variante 3 ist, dass man zumind. die Datenbank monolitisch auslegt. Dazu ist es allerdings erforderlich, dass man die Transaktionen immer mit einem "Befehl" komplett abschließt, da sonst wieder selbige Sychroniationsprobleme auftreten wie oben beschrieben.
Ein Befehl(Spieler A will 50 Wakrudpilze an Spieler B geben) sieht dann inetwa so aus(Pseudobefehle ):
"1. Nehme Spieler A 50 Wakrudpilze ab; 2. Gebe Spieler B 50 Wakrudpilze"
Kann ein Teil davon nicht ausgeführt werden, wird die Transaktion ohne Änderung der Datenbank abgebrochen. Ein Beispiel wäre, wenn Spieler A z.B. keine 50 Wakrudpilze besitzt bzw. Spieler B (aus welchen Gründen auch immer) keine 50 Wakrudpilze aufnehmen kann.
Dieses Beispiel ist extrem vereinfacht (normal müssen deutlich mehr Nebenbedingungen geprüft werden wie z.B. Befinden sich beide am selben Ort, ...)

Die dritte Variante habe ich selbst schon mal programmiert, also glücklicher Weise auch verstanden

Du sagst also, man könnte bei den anderen auf ne Datenbank verzichten? Hö? Wo kommen dann deine ganzen gespeicherten Werte im Spiel her? Glaube das hängt mit meiner genannten Wissenslücke jetzt mal zusammen...

Und zu dem Gold: Das das nen Item ist, wenns irgendwo rumliegt wusste ich auch schon, aber ich denke beim Übergeben wird das genauso gehandhabt, wie es zuvor als unsicher gepredigt wurde.

Person A gibt 500gm an Person 2:
A werden 500gm abgezogen von seinen gm auf der Hand wenns geht
B werden sie dazuaddiert, wenn es geht.
Wenn Person C kurz bevor A sein Gold B gibt, 300 gold an A gibt,
dann gibt er ihm das gold auch vorher und ich denke nicht, dass es irgendwo plötzlich verschwinden kann ...

[hoha]

sooo ich habe zwar nicht verstanden aber werde trotzdem mal nen versuch starten den thread etwas normalverständlicher zu halten.

ein möglicher lösungsansatz wäre holz magisch zu machen bei 3 tage haltbarkeit. so wird verhindert, das holz langfristig eingelagert wird und die möglichkeit des verlängerns gibt trotzdem ausreichend zeit um den passenden zeitpunkt zum einwurf zu bestimmen.
nachteil wäre das bewusste auflösen lassen von holz, welche zu einer seltenderen öffnung der mine führt.

ein seelenkugelvereiniger wäre genauso interessant. es würde ne menge items aus die fächer ziehen und zusätzlich als neues luxusitem gold vernichten.
die abwertung des speeds und die nötigen mehranwendungen um das luxus interessant zu machen stehen dem natürlich gegenüber.

soweit meine spontanen und unausgereiften ideen, welche ich mal dreisterweise in den raum werfe

[vnv_nation]

Verstehe mich nicht falsch, der Gedanke des Zusammenfassens ist logisch und, mit anderen DB - Systemen ließe dieser sich sogar realisieren. Allerdings und hier kommt der Trick, diese sperren kurzzeitig die Tabelle in Gänze oder in Teilen. Dies bedeutet, dass die Laggs zwar nicht mehr durch Itemmasse, wohl aber durch das Verhindern dieser auftreten.

Hmm, das konnte ich jetzt nicht so ganz verstehen, tut mir leid, dich dafür um nähere Erläuterung bitten zu müssen...

Kurzfassung: Es ist in bestimmten DB (in mySQL meines Wissens nach nwv. nicht) möglich Tabellen bzw. Einträge in Tabellen während eines Zugriffs vollständig zu sperren. Alle übrigen Anfragen rutschen in einen Queue und werden nach Bearbeitung der ersten Anfrage nach Fifo abgearbeitet. So. Wie man unschwer erkennt ist bei 3oo schreibenden Zugriffen in 6 Sekunden (was ja normaler Bewegungszeit entspricht) Anfragezeit n * 300 die Tabelle blockiert. In 6 Sekunden macht das nix, was ist aber bei Zeiten kleiner 1 s? z.b. beim magischer Verlängerung von Items? Die Anfragen sind also ungleich höher, als nur 300 / 6 Sekunden. Ergo könnte diese Variante zu Laggs führen anstatt sie zu verhindern. weiter siehe Damh...

Nach meinem Verständnis müssten keine neuen 200 erzeugt werden, sondern nur 1 item, welches irgendwo den wert 200 mit sich trägt in der db!

Lies nochmal genau Da steht, wenn man es in der Bank macht und ausschließlich für die Bank (um ja Problem mit verschwindenden Items zu begegnen).

glaube du hast nicht ganz verstanden, wie weit ich mich mit meinen Gedanken vom ursprünglichen system der einzelnen items entfernen wollte...

Doch, doch, ich denke, ich hab dich sehr gut verstanden und deine Idee auf eine Trennung Bank / Hand (Zusammenfassen / Nicht zusammenfassen) umgebaut, eben um das Übergabeproblem zu eliminieren.

D.h. entweder einen monolitischen Server benutzen (1 Prozess (keine Threads) macht die Arbeit des Webservers(hier Apache), der Spieleengine(Nightfire Browsergames Engine) und der Datenbank (MySQL).

Gut...

nein, wenn man Variante 1 nimmt, gibt es anschließend keine Datenbank mehr.

Du hast irgendwie "übersehen" die Datenhaltung zu erklären. Denn, wohin damit, wenn es keine DB mehr gibt? Irgendwas in der Art wird man wohl schon noch brauchen, da ich vermute, dass du nicht vorschlägst die Daten in Dateien nach HD zu schreiben

Abgesehen davon, selbst wenn nur ein Prozess Apache, Engine und DB verwaltet, so hast du bei Nutzanfragen n in wirklichen Größenordnungen denn Abarbeitungszeit * n >> erträgliche Verzögerung.