Userdaten

Ich wollte mal rumfragen wie Ihr die "Verwaltung" der Userdaten im BG-Script handelt. Hierbei meine kein Administrationsprogramm sondern wie Ihr die Daten abfragt.
1. Methode: Bei jedem Seitenaufruf komplett aus der DB auslesen
2. Benötigte Daten entsprechend abrufen (ggfl. auch 2. pro Seitenaufruf)
3. Beim Einloggen einmal komplett abfragen und dann in der Session speichern.
4. Mix aus 3 und 2. Stammdaten speichern, seltenere Werte abfragen.
5. was ganz anderes.
Würde mich einmal interessieren wie Ihr das handelt und wo ihr die Vorteile eurer Methode seht.

4!
also sowas wie Straße und Telefonnummer muss nicht in der Session stehen.

Version 3, ggf. ist noch nicht mal das Notwendig, weil der User als Element der Welt schon im Speicher ist.

1., verbraucht nicht viel mehr Zeit, verlasse mich halt auf den Cache von mysql

ID, Name, Hilfe an/aus, Wikirechte ja/nein, Admin ja/nein, Guestaccount?, Grafikpackurl, x- und y-Koordinate - also alles, was im Grunde auf jeder einzelnen Seite noetig ist - in der Session, alles weitere bei Bedarf.

4...
UserID, Nick, Koordinate des Planeten, Allianzinfos (Alli-ID, Rang), Freundesliste
Rohstoffe, Gebäude, Forschungen etc aus der DB
und bei manchen Aktionen Sessiondaten aktualisieren (Allianz verlassen)

1.
Mal kurze Frage macht das soviel unterschied ob komplett in Session oder jedes mal Abfragen? Auf Sessions muss ja auch zugegriffen werden!
Wieviel macht das aus an Serverlast z.b.

Original von Mudder
Ich wollte mal rumfragen wie Ihr die "Verwaltung" der Userdaten im BG-Script handelt. Hierbei meine kein Administrationsprogramm sondern wie Ihr die Daten abfragt.
1. Methode: Bei jedem Seitenaufruf komplett aus der DB auslesen
2. Benötigte Daten entsprechend abrufen (ggfl. auch 2. pro Seitenaufruf)
3. Beim Einloggen einmal komplett abfragen und dann in der Session speichern.
4. Mix aus 3 und 2. Stammdaten speichern, seltenere Werte abfragen.
5. was ganz anderes.
Würde mich einmal interessieren wie Ihr das handelt und wo ihr die Vorteile eurer Methode seht.

Methode 1: Total uneffektiv, mit "*" der Overkill.
Methode 2: Besser, aber redudant. Auch nicht so berauschend.
Methode 3: Datenbanktechnisch erstmal genial effektiv - nur leider hat das die Performance runter, wenn man a) viele aktive Sessions hat und/oder b) einen alternativen Sessionhandler baut (der z.B. wieder eine DB ntuzt ). Also, auch nicht gut.
Methode 4: Rundumschlag und bei strukturierter Handhabung aus meiner Sicht die beste Lösung. Selbst hier kann aber theoretisch M3 eintreten, das muss dann abgewogen werden.
*Stammdaten wären für mich aber nur sowas wie Id, SessionId und ggf Sessionrelevante Dinge wie PremiumAccount, Style-Wahl usw.. keine Mailadresse, kein Ingamename (es sei denn, der wird auf jeder Seite angezeigt).

Daten die ich jedesmal brauche in die Session, sprich user_id, name, aktuelle Insel auf der der Spieler sich befindet.
Rest aus der DB holen. Alleine weil sich die Daten recht fix verändern können, rentiert es sich nicht, Planeteninfos in die Session zu schreiben.

Kann man pauschal sowieso nie auf alle Spielmechaniken festlegen. Bei uns ändern sich ausser dem Benutzernamen eh fast alle relevanten Daten ständig (auch durch einwirken dritter), so das es keinen sinn macht dies in der session zu speichern.
Andererseits weis ich auch soweiso nicht wo der overkill sein soll, wenn man eine spalte abfragt (limit 1) aus einer DB die mit Sicherheit im cache liegt. Letztens wurde sogar irgendwo Hier angezweifelt das ein explode schneller arbeitet als ein mysql- Select.
hat denn schon mal wer das getestet, gebenchmarkt oder kennt glaubwürdige Aussagen ?
Denn an sich zieht sich die Frage, wann man auf Datenbankzugriffe zugunsten alternativlösungen verzichten sollte, doch wie ein roter faden druch einige Themen hier.
Ich geh da oftmals auch mehr nach dem Bauchgefühl und wäre froh wenn man da etwas konkretere Angaben hätte.

Ich habs getestet, Sessions sind bei 1000 Sessions mit bis zu ca. 500 Zeichen "Nutzdaten" schneller als MySQL. Dürfte aber auch von der Umgebung abhängen, also bitte nur als Richtwert nehmen.

Ich mache mir es ziemlich einfach und schreibe alles in die Session und die Session wird dann in die Datenbank geschrieben. In einer Sekunde schafft mein kleiner Server (1 GHz P3) 200x Session aus Datenbank holen, deserialisieren, neu serialisieren und wieder in die Datenbank schreiben. Mein Athlon 64 3000+ hier zuhause schafft knapp 1000x den Vorgang. Die Session ist übrigens auch nicht gerade klein, serialisiert sinds ca. 4k Daten. Insofern mache ich mir da über die Performance also auch keine großen Gedanken, bis ich mal 1000 User habe, die gleichzeitig auf meiner Maschine rumturnen, wird noch etwas Zeit vergehen

4...
id,name,momentane insel ...
und
sachen wie ressourcen aus der DB...

Ich habe ein eigenes Sessionsystem basierend auf einer datenbank entwickelt. Klappt ganz gut!
Gruß
Moo

mir ist indessen konsistenz und aktualitaet der daten lieber als geringfügige lasteinspaarungen. selects auf eine tabelle die ehh im ram liegt sind schnell und es gibt auch im laufenden betrieb keine messbaren veränderungen wenn man mal 8 selects einspaart. eher probleme die daten dann korrekt zu halten. insofern eindeutig für ein select * from... vorteile, man hat alle daten (also nix vergessen zu holen) und sie sind aktuell (wenn andere prozesse an userdaten rummanipulieren)

Ich verwende auch
SELECT * FROM
Hab gerade nochmal getestet:
Bei ca. 35000 Einträgen und einer Zeilenlänge von ca. 128 Byte ist nur ein sehr geringer Unterschied, ob man einzelne Spalten oder * einliest.
Um Caching-Vorteile zu minimieren habe ich zufällige Datensätze ausgewählt.
Der Zeitbedarf pro SELECT * FROM liegt bei ca. 0,5 Millisekunden.

Grunddaten aus der DB, Daten für die aktuelle Seite aus der DB, ergo alles aus der DB. Aktuelle Daten sind mir sehr wichtig. Ende der Diskussion. Versucht nicht mich umzustimmen XD

Verwendete früher auch Methode 1.
Bin aber nachdem ich immer mehr Probleme mit der Datenbank bekommen habe auf Methode 4 umgestiegen.
UID, name, Grafikpfad, usw aus der Session
Restliche Daten Seitenspezifisch aus der Datenbank
oder für selten verwendete Funktionen, die viele Daten brauchen auch mal ein 2.Query zum nachladen.

Nun von mir mal eine ganz andere Technik
In der Alten Version meines Spiel habe ich alles geladen, wenn ich
es benötigt habe.
Jetzt habe ich einen Webserver geschrieben, der nur für das Spiel
ist. Dort habe ich nichts drin, was irgendwo ein Sicherheitsrisik sein
könnte. ( was sich noch zeigen wird )
Ich lade beim start des webservers alle daten wie templates oder
Userdaten und pw in den cache.
Dieser bleibt die gesammte Serverlaufzeit on.
Wenn sich ein user einloggt brauche ich die Daten nur aus den
Entsprechenden vectoren, maps ect. zu laden, wodurch ich
eigentlich garkeinen Overhead habe.
Sollte der User nun hingehen, und wichtige Daten ändern,
seien dies nun Userdaten, die Punkte oder ein Gebäudelevel,
dann schreibe ich diese eine änderung in die Datenbank und setze
den Status für dieses Element im vector auf changed.
Simultan ändere ich die Werte natürlich auch im Speicher, aber
das wäre sehr unsicher, wenn man die Werte nicht immer mitspeichert.
Ein workerthread überwacht, ob irgendwo felder auf changed stehen.
sobald dies der Fall ist werden die entsprechenden Felder
neu geladen.
Die Userkarte habe ich in einem mehrfach verlinken array liegen, was bei der Karte dazu führt, dass sie so gut wie garkeine Ladezeit hat.
So habe ich also nur die paar update und select Aufrufe in der Datenbank.
Der große Nachteil ist auf jeden Fall, dass wenn ich einen Bug behoben
habe, oder einfach was geändert habe den Server immer wieder neu
kompliert hochladen muss und dann den Webserver erst beenden, dann
wieder neu starten.
Mit Sicherheit ist das nicht der Optimale weg, aber er funktioniert
sehr gut

Die Userkarte habe ich in einem mehrfach verlinken array liegen, was bei der Karte dazu führt, dass sie so gut wie garkeine Ladezeit hat.

Was ist ein mehrfach verlinktes Array?
Ansonsten finde ich den Ansatz recht interessant.

Ich wußte nicht wie ich es sonst nennen sollte
Ich habe für alle Kartenobjekte speicheralloziert, mindestens in
10er blöcken ( 10 aneinanderliegende Blöcke im Spicher )
diese Blöcke habe ich dann durch eine matrinx von pointern verlinkt.
bedeutet im klartext, dass wenn ich position x = 74, y = 63 haben will
xPois[7][4] yPos[6][3] nehme.
Davon sieht der Programmierer aber nichts, da dieses verhalten
durch den überladenen operator[] abgedeckt wird,
man also wenn man eine Kartenposition braucht nur
_awMapHandler[xPos][yPos] machen muss.
_awMapHandler.getRegion(xFrom, xTop, yFrom, yTo);
somit erhalte ich in kürzester Zeit einn vector auf den von mir
bestellten bereich gefüllt mir pointern, die mir dann auf
die Speicherstellen Zeigen.
Ich hoffe, dass man nun versteht was ich mein

Grob gesagt Index-Arrays auf einem Datenarray, die aufeinander aufbauen

genau