SQL MySQL automatisieren

Das mache ich bereits. Es ging mir ja lediglich um Denkanstöße.
 
  • Gefällt mir
Reaktionen: oicfar
Danke an alle für die Hilfe. Ich habe jetzt ein Script mit Gameloop am laufen. Dieses taktet alle 5 Sekunden und sollte mehr los sein, jede Sekunde. Gleichzeitig prüft ein Cronjob jede Minute ob das Script noch läuft und schmeißt es ansonsten wieder an. Ist bisher aber noch nicht vorgekommen. Transactions nutze ich nun auch. Ich habe mich damit nun mehr beschäftigt und finde es sehr einfach und gut umzusetzen. Auch die Inserts konnte ich deutlich beschleunigen.
 
  • Gefällt mir
Reaktionen: Falc410
Wo du übrigens auch Performance rausholen kannst, ist wenn du keine Datenbankabfragen generierst. Wenn du zb immer wieder die selben SELECTs hast, um die Daten des Nutzers (Username, Level, Avatar, etc) auszulesen, solltest du stattdessen das Ergebnis dieses SELECTs in eine PHP-Datei schreiben, die du nur include'st. Damit sparst du gleich Mal 99.99% aller dieser SELECTs ein, weil der User ja nur selten diese Daten ändert. Natürlich brauchst du dann noch einen Mechanismus, der die PHP-Datei löscht, sobald ein INSERT/UPDATE auf diese Daten erfolgt. Oder man lagert diese Info in Javascript Variablen aus, die nur bei Bedarf beim Spieler aktualisiert werden (komplettes Neuladen der Seite).

Wobei man gerade beim Caching noch massig umsetzen kann. Meistens macht man das erst, wenn man merkt, das bestimmte Prozesse den Server überlasten. zb könnte man auch hingehen und manche Berechnungen nach Javascript auslagern. Also zb zählt eine Ressource wie Geld beim User durch Javascript live hoch, aber der Server addiert das Geld in der Datenbank nur 1x alle 15 Minuten. Wenn der User eine Aktion macht, wie etwas kaufen, erfolgt dagegen auch außerhalb des Intervalls ein UPDATE (natürlich spielt das Javascript Ergebnis keine Rolle für den Server, ansonsten könnte der Spieler durch Manipulation des Javascript Codes mogeln).

Casino Spiele machen auch was Interessantes auf dem Smartphone: Der Spieler denkt er spielt live, aber in Wirklichkeit wurden schon x Spiele vorab vom Server berechnet und dann als Paket vom Spiel heruntergeladen. Dadurch verhindert der Anbieter, dass wirklich jeder Durchlauf einer Slotmaschine live berechnet werden muss und der Spieler kann spielen, auch wenn kurz mal das Internet abbricht. Andersherum kann sich der Anbieter sicher sein, dass der Spieler nicht wie bei einem rein offline funktionierenden Spiel, einfach die Spielergebnisse manipuliert.
 
Zuletzt bearbeitet:
@mgutt Caching macht man nicht mit Dateien. Für einfache Sachen reicht hier Memcached (http://memcached.org/). Erst den Cache abfragen. Sind die Daten nicht da, die DB Abfrage machen und dann den Datensatz in den Cache packen. Ändert der Nutzer was an seinen Daten, dann wird der Datensatz im Cache invalidiert.
 
  • Gefällt mir
Reaktionen: floq0r
Tatsächlich nutzt meine genannte Technik so gut wie keiner, da man PHP Entwicklern bereits während der Schulung vermittelt, dass Memcached nur für Daten sei und OPCache nur für Skripte. Tatsächlich leistet aber OPCache das selbe, wenn man Daten zb als Array in einem PHP-Skript ablegt und includet. Auch dann ist alles vorkompiliert im RAM.

Ich hatte das mal intensiv gebenchmarked und es war kein Unterschied messbar. Vor allem lohnt der Gedanke eigentlich nicht, weil bei einem optimalem Caching auch gleich der generierte Inhalt gecached wird. Also zb eine HTML-Website wird vollständig als zB gzip komprimierte HTML-Datei auf dem Webspace abgelegt und der PHP-Parser und das live Komprimieren fällt komplett weg. Solche Techniken nutzen ja eigentlich alle großen Websites.

Ich habe für mich auch den Vorteil entdeckt, dass die gecachten includes auch einen Neustart überleben und bei Lastverteilung verschiedener Container wiederverwendet werden können. Bei memcached hat man dann ja zb einen memchached Server, der über TCP die Daten aus seinem RAM bereitstellt. Das ist ja mal richtig Banane. Ein klarer Nachteil meiner Technik sind aber die zusätzlichen Inodes im Dateisystem. Da muss man aufpassen, dass man sich dadurch kein Bottleneck verursacht.

Also ja memcached ist natürlich auch eine Option.
 
Zu PHP kann ich wenig sagen, da ich die Sprache immer gemieden habe. ;) Ich bewege mich eher im Java Backend Umfeld. Aber die Konzepte sind am Ende oft die Gleichen.
 
mgutt schrieb:
Bei memcached hat man dann ja zb einen memchached Server, der über TCP die Daten aus seinem RAM bereitstellt. Das ist ja mal richtig Banane.
Wieso?
Man hat natürlich noch overhead aber in Summe weniger Aufwand als bei einem physical read oder einer SQL query, wobei auch hier je nach data page caching sehr schnell results returned werden.
 
floq0r schrieb:
weniger Aufwand als bei einem physical read
Das Lesen über eine TCP Session soll weniger Aufwand sein als das Lesen einer lokalen Datei? Das meinst du doch jetzt nicht ernst 🤨

So ungefähr mache ich das übrigens:
PHP:
# cache filename
$cache_file=md5($sql_query);
# cache lesen
if ( ! file_exists($cache_file . '_lock') ) { # nur wenn gerade kein Cache erstellt wird
  $data = @include $cache_file;
}
# cache nicht vorhanden
if ( ! $data ) {
  # sql query
  # ...
  $data = $sql_ergebnis
  # cache erstellen
  if ( ! file_exists($cache_file . '_lock') && @mkdir($cache_file . '_lock')) {
    file_put_contents($cache_file, '<?php return ' . var_export($data) . '; ?' . '>');
    rmdir($cache_file . '_lock');
  }
}
# $data enthält nun Daten aus SQL-Query oder Cache

Ich habe noch mal in meine Notizen geschaut. Bei meinen Tests hatte ich zB auch das Problem, dass der memcached im fcgi Kontext nicht funktioniert hat, weil jede neue fcgi Session einen neuen memcached Bereich resultierte. Keine Ahnung ob das mittlerweile besser geht.
 
@mgutt also, wenn man jemanden schon was "beibringen" möchte, dann bitte nicht solche Lösungen. Viele lernen schlechte Implementierungen und machen es dann in großen Projekten auch so und wundern sich, dass es nicht skaliert.

Ansonsten sage ich immer: "Nimm die Lösung und skaliere die Datenmenge um 1000, 10000 oder 1000000 um die Auswirkungen deiner Implementierung zu sehen.". Und dann wundern sich die Meisten, was die da produziert haben.

In Zeiten, wo die CPUs viele Kerne haben, viel RAM vorhanden ist und SSDs in Servern verbaut sind, sind viele nicht in der Lage schonend mit den Ressourcen umzugehen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: aronlad
mgutt schrieb:
Bei memcached hat man dann ja zb einen memchached Server, der über TCP die Daten aus seinem RAM bereitstellt. Das ist ja mal richtig Banane.
Ich mag Bananen. ;)

Normalerweise würde ich an der Stelle einen Memcached Cluster aufbauen. Hängt von der Projektgröße wie viele Instanzen zum Einsatz kommen würden. Bei kleineren Projekten kann man pro Server dann einen Memcached Instanz packen. Und den Memcached Cluster so ansprechen, dass der Client entscheidet, wo die Daten abgelegt sind. Sollte eine Instanz aus dem Cluster ausfallen, dass ist nur der Teil der Daten weg.

Scheint auch so mit PHP zu gehen: https://www.digitalocean.com/commun...on-multiple-memcached-servers-on-ubuntu-14-04
Ergänzung ()

Skidrow1988 schrieb:
Darf ich das nutzen? 🤣
Bitte, bitte nicht die Lösung. Du wolltest ja was (besseres) lernen. ;)
 
Das war nicht ernst gemeint. Ich arbeite erstmal das gelernte aus.
 
Kleines Update:

Eure Hilfe hat mir sehr geholfen. Vielen dank dafür!

Viele Abfragen habe ich nun im Cache und müssen nicht mehr geladen werden. Wer den Eingangspost gelesen hat, kennt die vorherigen Zeiten. Im Anhang ein Bild mit den jetzigen Zeiten.
 

Anhänge

  • IMG_0168.jpeg
    IMG_0168.jpeg
    1,1 MB · Aufrufe: 111
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: oicfar
Zurück
Oben