Neuorganisation der Itemverwaltung

[Prinegon]

Da die Itemflut eine so grosse Rolle spielt bei der Serverlast, wäre ich dafür, die Itemverwaltung der Items im Bankschliessfach anders zu gestalten. Bisher scheint es so zu sein, daß jedes Item eine ID bekommt und diese nicht verliert, egal was mit dem Item passiert. Das heißt, sollte jemand 50 ZK in der Bank liegen haben, so werden 50 Einzelitems gespeichert mit 50 verscchiedenen ID\s. Die Frage, die sich mir dabei stellt, ist ob das unbedingt nötig ist?
Als Test dafür, daß das auch wirklich so ist, hab ich übrigens gleichartige Items aus dem Schliessfach genommen, mit ihre ID aufgeschrieben, sie ins Schließfach zurückgelegt, erneut herausgenommen und die ID\s erneut aufgeschrieben.
Hier also die Idee: Anstatt jedes Item für sich abzuspeichern, wird pro Item nur ein Exemplar abgespeichert und dazu die Anzahl der Items, die man davon besitzt. Die eigentlichen Instanzen der Items werden also beim Einlagern zerstört, es wird halt zu jedem Item nur noch eine Instanz gespeichert und die Anzahl der Instanzen. Beim Herausholen der Items aus dem Schliessfach werden die Items neu erschaffen und dann dem Inventar zugefügt, die Anzahl der Items, die im Schliessfach vorhanden sind, wird um den dementsprechenden Wert verringert.

Mein Schliessfach ist mit 500 Items ziemlich überfüllt, zugegeben, doch wenn man gleichartige Items zusammenfassen würde, so könnte man bei mir um die 280 Itemspeicherungen einsparen. Und ich denke, so wir mir wird es auch bei einigen anderen sein.

Es mag sein, daß es sich nicht lohnen würde, für jede Art Items diese Umsetzung zu machen, man sollte sie aber definitiv für bestimmte Items machen, wie z.B. Stierhoden, Kuhköpfe, Gepresste Zauberkugeln, Diebstahlzauber, Zauberpollen, Silberschnee, Goldstaub, Ölfässer, Baru-Getreide, Sumpfgas, Mondscheindiamanten, Rubine, ect. halt alles Dinge, die sich ansammeln könnten, jedoch als Einzelitem kaum gebraucht werden und somit auch nicht alzu häufig aus dem Schliessfach genommen werden. Items, die häufiger gebraucht werden, wie Edelstein des Lichts, könnten ihre ID behalten.

-----------------------------------------------
Anmerkungen zur Umsetzung:

Dieser Teil ist zur Bewertung der Idee nicht sonderlich wichtig, er ist eigentlich auch nicht wirklich für Sotrax gedacht, denn dieser wird selbst besser wissen, worauf man achten muß und was man machen kann (er kennt den Code, ich nicht!). Ich habe ihn eher für Interessierte geschrieben und für die Leute, die eine Idee grundsätzlich ablehnen mit der Begründung: DAs ist nicht möglich, oder das ist zu aufwendig, ohne überhaupt über die Vorgänge bescheid zu wissen oder die Probleme, die auftreten könnten. Natürlich ist dieses nur eine generelle Überlegung dazu und ich muß gestehen, ich hab persönlich mit MySQL nicht gearbetet, jedoch ähneln sich Programmiersprachen ja gründsätzlich.
--------------------------------
Aufpassen muss man darauf. daß Items mit Diebstahlschutz/Todesschutz gesondert abgespeichert werden, ebenso Unique-Items mit dem Namen eines Standarditems, aber einer anderen Beschreibung (ich kenne einen Fall, wo das bei einem Wok so ist) [was sich als das größte Problem herausstellen könnte] und Items mit Haltbarkeit. Auch muß darauf geachtet werden, daß nicht unterschiedliche Versionen des gleichen Items vermischt werden (sprich nicht alte und neue KU vermischt, sondern als getrennte Items behandelt). Mit anderen Worten: Es müßte wohl eine relativ aufwendige Funktion gemacht werden, welche ein einzulagerndes Item mit den bereits vorhandenen abgleicht.
Teile dieser Funktion müssen bereits vorhanden sein, da ansonsten das Zusammenfassen der Items bei der Anzeige nicht funktionieren würde. Was diese Funktion noch nicht leistet, ist das Unterscheiden, ob ein Item diebstahl-/Todgeschützt ist, oder nicht. Ich könnte mir auch vorstellen, daß der Sonderfall des Unique-Items Messingwok mit eigener Beschreibung auch mit einem Standard.Messingwok zusammengefasst würde. Aber in den Grundzügen gibt es schon die Routine, die Items in Gruppen einsortieren kann.
Das Sortieren des Bankschliessfaches ist kein Userabhängiger Vorgang, sondern kann nebenläufig passieren. Sorich: Sollte ein User Items einlagern wollen, so könnten diese immer noch wie üblich eingelagert werden, jedoch in eine temporäre Liste. Diese werd dann abgearbeitet und die Items einsortiert (und dabei zerstört), sobald der Server Luft hat. Andere Alternative, um die Sortierungsvorgänge zu begrenzen, wäre das Zwischenspeichern der Items in deiner FiFO-Hashtabelle, in der die Zeit gespeichert wird, zu der die Items in die Bank gelegt wurden. Frühestens nach einer gewissen Zeitspanne (z.B. 1h, oder aber nach dem Ausloggen des Spielers) werden die Items "richtig" einsortiert.
Sollten dermaßen "gepackte" Items wieder aus der Bank geholt werden. so müssten die Items neu erschaffen werden. Dabei muß darauf geachtet werden, diesen Prozess absturzsicher zu machen. am leichtesten geschieht das, indem die Items, die geholt werden, zunächst nicht ins Inventar des Charakters erschaffen werden, sondern in das Bankinventar. Das ist eine rein Serverseitige Sache, die wahrscheinlich relativ sicher läuft. Dann muß natürlich darauf geachtet werden, daß, bevor das erste Items aus der Bank übertragen werden darf, zunächst alle Additions-/Subtraktionsoberationen auf die Anzahl der befindlichen Items in der Bank abgeschlossen werden müssen (das dient dafür, daß man bei einem Serverlagg nicht in der Lage sein darf, Items zu verdoppeln). Hier ist es also vonnöten, mit Sperrmechanismen (Semaphoren) zu arbeiten.
Ansonsten sollte bei dem Prozess nicht alzuviel schiefgehen können, das eigentliche Übertragen der Items aus der Bank ist wie gehabt.

Wie viel oder wenig diese Einsparungen bringen, was die Sortierroutine von der Ersparnis des geringeren Itemaufkommens wieder an Performance schluckt, kann ich nicht sagen, ich kann mir aber vorstellen, daß eine deutlich spürbare Verbesserung herauskommt. Im Allgemeinen heißt es, wo auch immer die DB sinnvoll verkleinert werden kann, sollte man es machen. Und Sinn macht es, die DB an den Stellen zu komprimieren, die eh einen seltenen Zugriff haben.

[Teodin]

ich habe ehrlichgesagt nur den oberen Teil deiner idee durchgelesen.
Also: Ich denke man könnte den server so wirklich ziemlich entlasten. gepresste zks machen sicher mindesten 25% aller items in den Fächern aus, da bin ich mir fast sicher. Ob das Technisch möglich ist vermag sicher nur sotrax zu sagen...

[DeNito]

ich stimme dem voll und ganz zu von teodin.
(hab mir auch nur den oberen teil durchgelesen)
also ich weiss ja nich, ist Sotrax da vil schon von alleinie draufgekommen und konnte das nich machen aus irgendwelchen gründen? oder ist er nicht drauf gekommen?
ist ihm aber nicht zu verübeln....
kann nur sotrax was zu sagen, ob das geht

[sgr011566]

Ich hab etwas weitergelesen und auch den Teil, wo es um die verschiedenen alten und neuen Versionen von Items ging.

Ich denke, das Problem mit dem vermischen würde sich nicht stellen, da alte Versionen von Items nicht zu häufig sein sollten und wie jene Items, die du angesprochen hast (Edelstein des Lichts usw) ihre ID behalten könnten.

Folglich sollte das kein Problem darstellen.

Ist mal meine bescheidene Einschätzung als Laie


Voll und ganz für diese Idee

[kaot]

Idee gut, von programmieren verstehe ich 1/x mehr als 0 .
Falls sich das so amchen lässt, bin ich kdafür. ich bin für alles was den Server entlastet

[LTD]

das ist ne super idee ich hab mir nur den ersten teil durchgelesen (es ist 4 uhr morgens) gört sich toll an

[Kyo Mibu]

so alles gelesen
aber viel helfen kann ich nicht da ich erst angefangen habe mit progscripts und so^^


waere auch besser
jedoch sollte man aufpassen dass die gzk nicht immer wieder vollwaere^^

[huwar]

Ich bin da ein bischen skeptisch.... Prinzipiell sehe ich folgendes Problem an dem Vorschlag:
Insbesondere zur Prime-Time, wenn wirklich ständig und in höheren Stückzahlen Items ein- und ausgelagert werden, würde die Idee eine erhebliche zusätzliche Last für die DB bedeuten. Neben dem Update der Anzahl im 'Itemkatalog' des Spielers müssen eben auch die einzelnen Item-Datensätze (die es ja bereits gibt) wieder gelöscht werden.
Holt der Koch seine 2000 Kuhköpfe wieder aus dem Fach, müssen kurz zwischendurch wieder 2000 Item-Datensätze erzeugt werden....

Ob das wirklich Last spart (und zwar zur Prime-Time!) stelle ich in Frage.


Aber um den Vorschlag abschließend beurteilen zu können, müsste man erstmal wissen, wo genau das Performanceproblem mit Bankitems liegt.
Kennt jemand eine genaue Erklärung von Sotrax? Ich hab nur einige Aussagen gefunden, die das Thema zwar ansprechen aber eben nicht genau erklären.

[Prinegon]

In der Tat wäre es zum Problemlösen von Interesse, wo die Probleme beim Umgang mit den Datensätzen liegt, ob es z.B. das Suchen eines Datums ist, das Auslesen oder aber das Erstellen neuer Datensätze und verteilen freier Indizes (letzteres würde diesen Vorschlag sehr kontraproduktiv machen).
Ich denke, da die Daten Indizesortiert sind, kann es kaum das Ansprechen/ Suchen eines Datums sein.
Ebenso wäre interessant, welche Struktur die Daten haben, ob sie in einer reinen Tabelle abgespeichert sind (entspräche ja einem Array oder ner Hashtable), oder aber als Liste (flach oder in Baumstruktur), welche Referenzlisten es auf die Daten gibt, usw. Vielleicht könnte bei der Speicherung eine Baumstruktur von Tabellen sinnvoll sein, um nicht ständig Operationen auf einer riesigen Tabelle vornehmen zu müssen, sondern auf kleineren Tabellen arbeiten zu können.

[Sir Seppelot]

so ich habe mich dann mal bei 3. anlauf doch dazu durchgerungen wenigstens den ersten absatz zu lesen.

von der idee her nicht schlecht und bestimmt gut nachgedacht. den was für den server gut ist befürworte ich immer. doch ich weiss leider nicht ob es umsatzbar ist. deswegen sollte sich vielleicht sorax hiermal melden. doch ich glaube ich habe mal gelesen das das nicht machbar ist. mal gucken was sotrax sagt

ps: Prinegon, schreib doch bitte mal einer idee die du selber für gut hälst etwas weniger. ich habe dir selber schon mal gesagt warum ich immer so drauf anspringe. es gibt bestimmt leute die sehen die idee und dann den text und gehen gleich wieder raus. so gehen vielleicht wichtige und hilfreiche sachen auch verloren. nicht mal die ersten beiden haben alles gelesen

[AnubisII]

Ich bin FÜR diese idee , da Serverentlastung meiner Meinung nach sehr wichtig ist.

[DeNito]

jetzts chreibt doch nich alle, ich bin dafür, weil es die server entlastet.
lasst unsern FW-Gott erstmal sprechen, ob der möglich ist. ich denk mal, von dem programmieren ham wir alle keine ahnung(so ziemlich)

[Prinegon]

Wohlbemerkt ist gar nicht sicher, ob es den Server entlastet. Wenn genau die Itemerstellung das Performanceraubende ist, so mag das sehr kontraproduktiv sein, denn Items zusammenfassen kann man machen, sowie man Luft hat. Wenn sie aber angefordert werden, dann muß man sofort die Zusammenfassung rückgängig machen.
Auch sollte man bedenken, daß das nicht ganz trivial (einfach) umsetzbar ist, denn man muß (insbesondere weil es eine verteilte Geschichte ist) immer noch die Konsistenz der Items gewährleisten. Ist ja keinem damit geholfen, wenns wunderbar die Items zusammenfasst, damit 1/3 aller Items einspart, aber alle 2 Wochen mal einige Items verliert durch z.B. Lags.

[FinalFrontier]

Die Umsetzung wäre sicherlich vorteilhaft, aber ich denke es ist so nicht möglich.

Beispiel: Waffen

Die haben eine Prozentangabe zur Haltbarkeit, die man natürlich auch speichern muss. Sonst könnte man die in das Schließfach bringen und das System weiß nicht mehr, mit wie viel Prozent die da reingelegt wurden. Also bei 0 - 100% sind das 100 ID\s.

Zauberkugeln:

Sind mehrfach Verwendbar, also müsste auch hier die Anzahl der Anwendungen gespeichert werden (1-13 Anwendungen glaub ich). Macht also auch 13 unterschiedliche ID\s.

Da gibt es meiner Ansicht nach Probleme. Allerdings bleibt ein Wakrudpilz ein Wakrudpilz. Da müsste es funktionieren.

[Prinegon]

Zauberkugeln mit verbrauchten Anwendungen könnten schlecht zusammengefasst werden, ebenso Waffen, die nicht 100% Haltbarkeit haben. Brauchen sie aber auch nicht, denn:

Normalerweise haben die Leute, wenn sie 20 ZK rumliegen haben, eine oder auch mal 2, wo sie schon Anwendungen verbraucht haben, der Rest ist voll. Die vollen 18 kann man problemlos zu einem Item zusammenfassen. Somit hat man dann noch 3 Items zu speichern, 2 ZKs mit verbrauchten Anwendungen und eine ZK mit vollen Anwendungen, in der ausserdem steht, wie viele es noch gibt.

Bei Waffen verhält es sich (zumindest bei den NPC-Jägern) meißtens so, daß die Waffen 100% haben, da sie ja nur gedroppt wurden von NPC, aber nie genutzt. Somit kann man diese auch wunderbar zusammenfassen. Bei PK sieht das schon anders aus, da diese ja bereits benutzte Waffen abgreifen.

Das Argument: Bei 100% wären das 100 ID\s zieht auf jeden Fall nicht, denn ohne Zusammenfassen kommen die ID\s ja auch zustande.