| neue Message hinzufügen |

kili 2015-05-18 14:39:55
Ich weiss leider nicht, wieviel Rechenzeit die Crashdetection
tatssaechlich kostet, aber das newshowmap rechnet manchmal ganz
schoen lang, und ulli wird ja auch nicht ohne Grund die maximale
Zuglaenge, fuer die die Crashdetection in der App aktiviert ist,
begrenzen.

Was das Speichern nur der nicht-crashenden Zuege angeht: wenn man
das on demand berechnen will, dann muss man wohl oder uebel beide
Faelle speichern sonst weiss man, wenn ein Zug nicht in der Datenbank
steht, ja nicht, ob es ein crashender Zug ist, oder ob der einfach
noch nie abgefragt wurde.

Man koennte aber natuerlich einen Mix fahren -- ab einer bestimmten
Zuglaenge (wenn's zu teuer wird, jedesmal zu rechnen) wird das
Ergebnis in der Datenbank abgelegt, kuerzere Zuege werden immer
berechnet.

rusty 2015-05-17 22:07:59
Hallo kili,

ich glaube ja, dass das Rendern der Seite, mit Karte und Bordfunk-Icons mehr Rechenleistung kostet als die Crash-Detection und Du an der falschen Stelle optimierst.
Davon abgesehen, warum speicherst Du nicht einfach nur die nicht-crashenden Züge? Das sind doch viel weniger, als alle denkbaren/erreichbaren Vektoren auf einer Karte.

mfG Andreas

Crash-Detection in der DB. kili 2015-05-15 01:09:03
Moin,

vor ein paar Monaten kam ja mal das Thema "Crash-Detection" auf;
Didi hat sowas in newshowmap.php eingebaut, es gab da auch einige
Anregungen von ulli (der das ja schon lange in der App hat).

Ich hatte die waghalsige Idee dass man das doch nicht jedemal teuer
per JavaScript im Browser berechnen muesse, sondern das ganze
Serverseitig erledigen und in der Datenbank speichern koenne.

Hauptbedenken war: wie gross wird das ganze? Das waere ja eine
Tabelle in der DB, in der irgendwann mal alle denkbaren Zuege fuer
alle Maps landen.

Jetzt habe ich mal mein gammeliges Karotool rechnen lassen und bin
fuer den aktuellen Bestand der Maps auf eine Obergrenze von etwa
30 Millionen moeglicher Zuege gekommen.

Um da mal den Platzbedarf zu ermitteln, habe ich (in einem MySQL bzw.
MariaDB) eine Tabelle wie folgt angelegt (Default-Engine ist InnoDB):

create table moves (map smallint unsigned, x0 smallint unsigned, y0
smallint unsigned, x1 smallint unsigned, y1 smallint unsigned, crash
bool not null, primary key (map, x0, y0, x1, y1));

Da puste ich gerade die 30 Mio. Zuege rein, im Moment sind knapp
10 Mio.  Eintraege drin. Der Platzbedarf auf der Platte liegt bis
jetzt bei etwas 800 MB, d.h. fuer alle Eintraege werden es wohl
knapp 2.5 GB werden. Didi hat auf seinem Server noch mehr als 250
GB frei, das sollte also kein Problem sein.

Dazu kommt, dass Didi vor zwei Jahren mal erwaehnt hat, dass die
Karopapier-DB gut 18 Millionen Zuege enthaelt, und da sind ja etliche
Zuege mehrfach drin (gleicher Zug von unterschiedlichen Spielern
in unterschiedlichen Spielen).

Wenn man also die Crash-Detection auf den Server auslagert und dort
einfach aus der Datenbank ausliest, und, falls noch kein Eintrag
vorhanden ist, den flugs serverseitig berechnet und in die Datenbank
wirft, duerften das deutlich weniger als die maximalen 30 Millionen
Eintraege werden (und auch deutlich weniger als die 18 Millionen
Zuege, die in der Karopapier-DB liegen).

Ciao,
Kili

| neue Message hinzufügen |
| Anfang | Vorherige | Nächste |

Brought to you by Didi

Letzter Satz im Chat:
Karaser (18:16): Lustig, im Moment schaue ich gerade das hier: https://www.youtube.com/watch?v=7CKRrFfMc2c , und dann lese ich das hier ^^