Das Hauptproblem war, dass die Berechnung der Offline-Simulationen bei größeren Accounts, teilweise bis zu 30 Sekunden Rechenzeit auf dem Server in Anspruch genommen haben. In dieser Zeit, sind die Datensätze in der Datenbank, die diesen Account betreffen, vollständig blockiert. Das hat in der Folge dazu geführt, dass bis zu 30 Sekunden lang, alle weiteren Server-Anfragen nur Fehler produziert haben, die Bestände nicht mehr gestimmt haben, die Produktionsstätten mit falschen Daten gefüllt wurden und das ihr dann Fehlermeldungen erhalten habt oder sogar vollständig ausgeloggt wurdet.
Ok dann schaun wir mal etwas genauer auf diese Aussage :
- Zeiten auf Datenbanken werden normalerweise in
msec gemessen, falls eine Aussage schon mit Sekunden beginnt ist etwas falsch eingestellt / optimiert
1. Optimiert den Server
Nach ein paar Tagen Spielzeit mit mehreren Timeouts hat sich mir schon vor den gestrigen Patch der Verdacht aufgedrängt das der eingesetzte Server definitv zu "klein" ist um die anfallende Datenmenge zu verarbeiten.
Es gibt natürlich hier ne menge Optionen um ein + an Geschwindigkeit zu erzielen (CPU, +RAM, schnellere HDD´s) falls alles andere fehlschlägt.
Wenn jetzt schon Massnahmen notwendig sind mit einer relativ "geringen" Spieleranzahl wird das in Zukunft nicht besser werden.
2. Optimiert die Clients
Der UM - Client läuft ständig unter Flash auf max CPU Last, selbst bei kleineren Dungeons schon.
Hier muss auf jeden Fall noch Perfomancetuning passieren.
Geschätzte 50 % aller timeouts welche ich beobachten konnte entstehen nach dem Besuch eines Freundesdungeon.
Der Client wird zusätzlich mit dem kompletten Layout eines weiteren Dungeons im Speicher belastet.
Flash & verschiedene Browser setzen hier mehrere Limits was die Speicherverwaltung und die CPU Last betrifft.
Wird der besuchte Dungeon umgehend aus dem Speicher entfernt ? Oder drauf gewartet das dieses vom OS übernommen wird (meistens sowieso nicht der Fall) ?
Dadurch kann ein Memleak entstehen was dazu führt das noch mehr CPU Zeit vom Client darauf verwendet wird um den Prozess am Leben zu halten ...
Quote Flash mit Firefox & UM : "Das Flashplugin reagiert nicht mehr - wollen Sie den Process beenden oder abwarten ?" (Quadcore, 8 GB RAM, keine weiteren Prozesse aktiv)
Wieder ein eindeutiges Zeichen daß das Spiel für die Clientseite nicht richtig optimiert wurde.
3. Optimiert die Datenbank
Abfragen welche über 30 sek auf einer DB laufen sind *hust* grottenschlecht um das mal ganz vorsichtig zu sagen.
Da kanns natürlich ne Menge Gründe dafür geben :
Fehlende Indizies auf der DB
Indizies teilausgelagert auf HDD´s welche eigentlich komplett im RAM gehalten werden sollten (hängt von der Indexgrösse und dem HDD - Speed ab)
Abfrage verfehlt den Index komplett (FTS - full table scan) oder nur ein Teilhit.
Zu grosse SQL Abfragen - generell ist es besser (nicht immer aber meistens ^^) eine grosse Abfrage in mehrere kleine aufzusplitten welche dann direkt über den Index laufen.
Zu viele SQL Abfragen - natürlich hat auch dieses Aufsplitten seine Grenzen, und da wurde ja gestern etwas nachgeholfen
Hier wäre auf jeden Fall ein SQL-Trace notwendig um zu sehen welchen Weg die DB nimmt, wie die SQL Abfrage aussieht und welche Optimierung am sinnvollsten ist.
sind die Datensätze in der Datenbank, die diesen Account betreffen, vollständig blockiert
Das allein schon deutet auf fehlende Indizies hin - aktuelle DB´s sind in der Lage mehrfach Abfragen auf gleiche Tabellen zu handhaben ohne komplett alles zu sperren ...
Und noch eine
4. Querdenkerlösung
Lasst die Clients die Offlineberechnung beim Login selbst durchführen und vergleicht das mit einer errechneten Prüfsumme auf dem Server.
Die Prüfsumme würde eine minimal Last für den Server darstellen, sollten hier Fehler auftreten kann immer noch eine komplette Berechnung für den Client durchgeführt werden.
Diese Berechnung wird dann aber wesentlich seltener durchgeführt (geschätzte 1 %) was im Endeffekt ein massiver Geschwindigkeitszuwachs wäre.
PS: Kann ich das überhaupt beurteilen ? Denke schon - Beruf : Zert. SAP Basis Admin (DB2, Oracle, Informix, SAP-DB, MAX-DB, MySQL)