"permanent-abfragen" und Systemüberlastung

Hallo zusammen,

ich entschuldige mich zunächst für meinen unklaren Themen-Titel, ich weiß nicht richtig wie ich mich ausdrücken soll

Undzwar geht es um folgendes:

Wenn man bei BoM (mein game) etwas baut, wird in der DB ein Datensatz angelegt für den Bauprozess, loggt sich der Spieler ein, wird überprüft ob der Prozess fertig ist und Gebäude.finish wird dann auf TRUE gestellt.

D.h. auch wenn die Bauzeit vorbei ist, der Spieler muss sich noch einloggen damit das Gebäude fertig ist.

Wenn aber jemand angreifen will, und ein angriffs-prozess angelegt wird, dann wäre das aus vielen Gründen blöd wenn der Prozess erst dann durchgeführt wird wenn einer der betroffenen Spieler sich einloggt.

Nun gibt es mehrere Möglichkeiten dieses Prob zu lösen:

1. Crontab alle 60 Sekunden

2. Bei jedem Login irgend eines Spielers die Prozesse prüfen und evtl beenden.

3. Das den Spielern "so verkaufen" dass sie noch einmal bestätigen müssen wenn sie "Vor der Grenze" stehen.

3. Lösung find ich blöd, 1. und 2. Lösung haben wahrscheinlich einen hohen Ressourcen-Verbrauch.

Wie macht ihr das? Was gibt es alles für alternative Lösungen?

Danke im voraus

omarius

Warum stellst du nicht die Bauvorhaben fertig wenn sich der jeweilige Spieler einloggt oder angegriffen wird?

Ich denke nicht dass du den Server mit einem "UPDATE gebäude SET fertig = 1 WHERE bauzeit < UNIX_TIMESTAMP()' übermäßig belastet.

Das kannst du durchaus alle 60 Sekunden ausführen lassen.

(Ich war nicht deutlich: Es geht um angriffs prozesse nicht um bau prozesse aber ega)

Original von Klaus

Warum stellst du nicht die Bauvorhaben fertig wenn sich der jeweilige Spieler einloggt oder angegriffen wird?

Hey Klaus, das ist ja der Fall. Nur will ich dass die "angriffs-prozesse" nicht wie bau-prozesse behandelt werden. Wenn das Gebäude erst tatsächlich fertig ist wenn sich der Spieler einloggt ist das ja kein Problem.

Aber ein Angriff sollte wirklich dann ausgeführt werden, wenn dieZeit gekommen ist.

Original von Kampfhoernchen

Ich denke nicht dass du den Server mit einem "UPDATE gebäude SET fertig = 1 WHERE bauzeit < UNIX_TIMESTAMP()' übermäßig belastet.

Das kannst du durchaus alle 60 Sekunden ausführen lassen.

 Echt? Okay, dann werde ich das mal so ausprobieren. Ich mach mir halt nur Sorgen dass wenn zB 2000 aktive Spieler dabei sind.. aber andernseits, das hat ja auch den vorteil dass "überflüssige" bzw fertige angriffsprozesse gelöscht werden direkt wenn sie fertig sind.

Ich werds mal versuchen und schauen ob das immer gut läuft.

Macht das sonst jemand noch anders?

Alle 60 Sekunden finde ich zu ungenau. Warum nicht bei allen wesentlichen Aktionen (Spieler, der das Gebäude baut klickt/loggt sich ein; Spieler wird angegriffen; ...) kontrollieren ob Gebäude fertiggestellt wurden?

Original von Fobby

Alle 60 Sekunden finde ich zu ungenau. Warum nicht bei allen wesentlichen Aktionen (Spieler, der das Gebäude baut klickt/loggt sich ein; Spieler wird angegriffen; ...) kontrollieren ob Gebäude fertiggestellt wurden?

(nochmal es geht um Angriffs-prozesse nicht bau-prozesse aber egal :)

Wie meinst du das, dass bei jedem Seitenaufruf geprüft wird ob die Armee beim Angegriffenen angekommen ist bzw ein Gebäude fertig gebaut ist? Das wäre ja dann pro seitenaufruf eine query mehr, ist das nich unprofessionell?.

(Also die frage ist nicht ironisch gemeint, ich weiß wirklich nicht wo "die grenze" ist.)

Ich habe dieses Angebot: http://www.hosteurope.de/produkt/Virtual-Server-Linux-XXL

Und wie immer gibt es nur eine effiziente Loesung: Eine Eventqueue mit allen zeitbasierten Events, die von einem Daemon (sei es eine multi-tier Struktur mit getrenntem Frontend und Daemon oder ein Application Server, hauptsache das Ding laeuft immer, bleibt im Speicher und arbeitet nicht nur auf Request Basis) abgearbeitet wird. Der kann dann regelmaessig aus der Datenbank pollen, wenn eine genutzt wird, oder direkt per Socket/Named Pipe die Events annehmen, sie intern sortiert ablegen und sich schlafen legen bis das naechste Event ansteht.

Dann muss man sich auch keine Gedanken mehr machen, wann der unnoetige Load zu viel wird - man vermeidet ihn einfach vollstaendig. ;)

Siehe: Scheduling / Eventqueue / Dispatching

Das Problem ist meist einfacher als man denkt.

Wenn ein Spieler angegriffen wird musst du eben die Bauschleife, Ressourcen, Einheiten etc. alles vor dem Angriff bis zu einer gewissen Zeit, nämlich die Ankunftszeit der Einheiten berechnen lassen. Die Ankunftszeit die im Kampfbericht (whatever) angezeigt wird machst du dann nicht über UNIX_TIMESTAMP oder sonstwas, du benutzt einfach die Ankunfszeit die du vorher mit dem Auftrag in die Datenbank gespeichert hast. Somit gaukelst du dem Spieler praktisch vor, das der Angriff dort stattgefunden hat, obwohl er erst wenige "Sekunden" zuvor berechnet wurde.

... was wiederum nur bis zu einer gewissen Komplexitaet des Spielkonzeptes moeglich ist, weil die Crossabhaengigkeiten einen irgendwann auffressen. Fuer einige Spiele mag das ausreichend sein - elegant ist es aber sicher nicht. Zudem entsteht immer unnoetiger Overhead, denn checken ob etwas ansteht muss man bei jeder Anfrage die in Bezug zu den Events steht, der je schlimmer wird, desto mehr User eingeloggt sind.

Ein gutes technisches Design sollte doch eher versuchen Peaks zu lindern, als dann noch mehr Load zu generieren...

Mich würde erstmal interessieren, wie lange denn ein Angriffs-Prozess normalerweise dauert.

Wenige Sekunden oder Minute, gar Stunden oder einen halben Tag?

Denn bei langen Angriffszeiten dürften ja schon ein paar Cronjobs in der Nacht reichen um die meiste Berechnung zu sparen. Und allgemein reicht ja ein Cronjob alle (minmale Angriffs-Prozess-Dauer), was ja bei längeren Angriffszeiten so oder so nicht so enormer Aufwand wäre.

MfG Bloodredangel

Also bei den agriffen ist das bei mir so geregelt.

Man wählt die zu plündernde Stadt aus, und eine Truppe mit der man angreifen möchte.

Dann wird aus Entfernung und Geschwindigkeit der Einheiten der Truppe die Dauer berechnet, die die Truppe braucht bis sie ankommt.

es wird also ein datensatz wie folgt angelegt:

striker # victim # ... # ankunftszeit

Ich will dann, dass jede sekunde überprüft wird ob ein angriff jetzt getätigt werden soll sprich die ankunftszeit <= time() ist. Berechnet wird der angriff also erst wenn die zeit wirklich gekommen ist, denn die stadt des einen kann vor dem angriff anderes ausgerüstet sein als zum (versprochenen) Zeitpunkt des Angriffs. Daher ein cronjob bro nacht bringts nicht.

Die Berechnug für den Ausgang eines Kampfes dauert etwa 1 Sekunde schätze ich.

Zu Kallisti: Danke, ich weiß jetzt dass ich ein absolute Noob bin in Sachen Server-techniken: event daemon, scheduling usw .. kann sein dass ich ungefähr weiß was es ist aber über diese begriffe komme ich nicht drauf   zu welchem bzw welchen Oberthemen muss ich mich hier Informieren?

An Alle: Kann ich nicht wenn ich den Angriffszeitpunkt berechnet habe manuell einen cronjob anlegen, der sich um diese uhrzeit ausführt und sich danach löscht?

Danke alle male

1. Arbeite mal an deiner Rechtschreibung.

2.  Ein deamon der in etwa sowas tut:

while (true) {

SELECT * FROM anstehende_kämpfe WHERE sollzeit < jetzt

while(nextrow) {

kämpfe();

lösche_kampfauftrag();

sleep(1sek);

 }

Was Kaempfhoernchen beschreibt ist die einfachste Variante des Ganzen, das geht natuerlich auch wesentlich eleganter, aber es trifft den Kern (und so war es ja wohl auch gemeint). ;)

Es geht um einen Prozess, der einmal gestartet wird, dauerhaft im Hintergrund laeuft und alle Aufgaben erledigt, die zu einer bestimmten Zeit anfallen werden.

Und wenn die minimale Dauer eines Angriffes in deinem Fall z.B. 30 Minuten waere, dann wuerde es in dem Fall auch ausreichen alle 30 Minuten aus der Datenbank zu lesen und nicht jede Minute. Aber wie in meinem verlinkten Thread diskutiert ist es noch effizienter, wenn nicht alles ueber die Datenbank geht, sondern wenn deine normalen php scripts direkt mit dem Daemon reden und ihm die neuen Events unterschieben, die der dann verwaltet und zur jeweiligen Zeit ausfuehrt bzw. an weitere Prozesse delegiert.

Vor allem ist es so kinderleicht ein skalierendes "realtime" System zu schaffen.

Scheduling heisst ja nichts als bestimmte Ereignisse zeitlich planen. Seien es Events wie ein Angriff oder regelmaessige Jobs, wie das generieren von Statistiken, das Verteilen von Punkten oder Ressourcen, etc...

Eine Eventqueue ist eine Warteschlange fuer Events, idealerweise nach der Ausfuehrungszeit sortiert, die sukzessive abgearbeitet wird. In der jeweiligen Zeit zwischen time() und next_event() macht man einen usleep oder ein select und "schlaeft" so exakt bis das naechste Event ansteht.

Dispatching bedeutet dabei dass der Prozess der die ganze Verwaltungsarbeit macht sich weiter nur darum kuemmert und die letztendlich Berechnung der Events jemand anderem ueberlaesst, damit er nicht blockiert wird. Am effektivsten macht man das mit einem Pool an Forks/Threads, der nur auf neue Events wartet und die dann abarbeitet. Hat sich z.B. im Apache und an vielen anderen Stellen bewaehrt, um den Overhead zu sparen einen neuen Prozess zu erstellen. Die Menge an Workern muss man eben an die jeweiligen Beduerfnisse und den RAM anpassen.

Okay, jetzt bin ich schonmal ein ganzes Stück schlauer ;)

Ich werde zunächst mal Kampfhoernchens Variante laufen lassen. Und später wenn alles richtig läuft, probiere ich das ganze mal professioneller.

@Kampfhoernchen:

Die Funktion die du geschrieben hast ist genau das was ich meine. Nur fällt es mir schwer den Begriff Daemon da in Zusammenhang zu bringen. Denn generell bedeutet Daemon ja einfach nur ein Prozess der im Hintergrund läuft, richtig?

Für mich heißt das: Ein Cron-Job der jede Sekunde ausgeführt wird. Somit kann man den Prozess stoppen wenn er mal pausieren soll.

Oder gibt es eine andere Variante als einen Cron-Job um etwas im Hintergrund laufen zu lassen?

Danke nochmal

Ich würde den Prozess einfach immer laufen lassen, und einmal pro Minute prüfen ob er noch lebt (per Cron) und ggf. abschießen und neustarten.

Kallisti's Ansatz ist dabei natürlich auch interessant, benötigt aber wiederrum eine eigene API. Ich bin nunmal der Freund von schon vorhandenem Zeugs, sprich dem Einsatz einer Tabelle als Event-Queue.

Cron ist ja auch nichts als ein Programm das immer läuft und zu bestimmten Uhrzeiten andere Programme startet. ;)

Das Ding ist einfach, dass Du mit einem eigenen Daemon nicht an vorgegebene Zeiten gebunden bist, sondern dich dynamisch den Gegebenheiten anpassen kannst und so quasi "Echtzeit" (nicht im eigentlichen Informatiksinn, sondern im Sinne des Spielverständnisses) erreichen kannst und vor allem hast du einen persistenten Status im Speicher und musst nicht jedes mal "neu" anfangen.

Den Kampfhörnchen Ansatz haben wir nun quasi seit über 5 Jahren im Einsatz gehabt, aber wenn man sämtliche Eventberechnungen ausführt, hat das auch schon einmal länger als eine Sekunde gedauert (bei damals 1000 Usern und mit Berechnungen in C... aber hängt natürlich mit der Komplexität der Events zusammen) und um Überlappungen und zeitliche Verschiebungen zu vermeiden haben wir bisher mit Minutenticks gearbeitet.

Das funktionioniert soweit alles, aber Minutenticks sind eben ein gewisser Schönheitsfehler und wenn man nicht sofort eine eigene EventQueue baut, führt es dazu, dass man alle verschiedenen Events einzeln überprüfen muss (das fängt an mit Ressourcen, dann Gebäude, Forschungen, Truppen, Angriffe, Kriege usw...). Irgendwann kann das recht unschön und unnötig belastend werden. Durch eine saubere Queue Implementation beugt man dem von Anfang an vor. Das ist dann mehr Arbeit am Anfang, aber später weit einfacher, sauberer und vor allem auch schneller. :)

Insofern ist es imho die Mehrarbeit wert. - das gilt btw auch wenn man alles mit Cron oder je Request abarbeitet!

Was mich in der Hinsicht mal brennend interessieren würde:

Kann man einen Daemon in PHP entwickeln ohne Zugriff auf die Kommandozeile? Daher für Leute die zwar ein kleines Browsergame auf einem Webspace haben aber dennoch nicht auf eine ordentliche Implementierung verzichten wollen? :)

Man müsste dafür ja ein PHP Skript haben, welches man per Browseraufruf starten/stoppen und überwachen kann, aber im Hintergrund "ewig" weiterläuft. Ein "sleep()" gibt es ja in PHP, zwar nur auf Sekunden beschränkt, aber soo genau muss es ja auch nicht sein.

Bisher habe ich auch immer nur per Polling bei jedem Aufruf die Events verarbeitet. Was natürlich nicht optimal ist (langer Seitenaufbau je nach Anzahl der anstehenden Events und ähnliches).

PS: Fall es zu OT wird einfach sagen, mach ich eigenen Thread auf, aber denke mal es gehört noch gut zum Thema. :)

Original von DrakeL

Was mich in der Hinsicht mal brennend interessieren würde:

Kann man einen Daemon in PHP entwickeln ohne Zugriff auf die Kommandozeile? Daher für Leute die zwar ein kleines Browsergame auf einem Webspace haben aber dennoch nicht auf eine ordentliche Implementierung verzichten wollen? :)

Auf (shared) Webspace kannst du normalerweise keine externen Prozesse starten weil system(), exec(), proc_open() etc. deaktiviert sind. Wenn du ein Script im Webserver auch nach geschlossenem Browser weiterlaufen lässt macht dir früher oder später das Timelimit des Interpreters ein Strich durch die Rechnung. Kann man bei shared Webspace normalerweise auch nicht deaktivieren. Mal davon abgesehen das dir vermutlich jeder shared Hoster früher oder später die Verträge kündigen dürfte, solltest du Daemonprozesse starten.

Man müsste dafür ja ein PHP Skript haben, welches man per Browseraufruf starten/stoppen und überwachen kann, aber im Hintergrund "ewig" weiterläuft. Ein "sleep()" gibt es ja in PHP, zwar nur auf Sekunden beschränkt, aber soo genau muss es ja auch nicht sein.

Es gibt auch usleep() mit einer höheren Auflösung (millionstel Sekunden)

Bisher habe ich auch immer nur per Polling bei jedem Aufruf die Events verarbeitet. Was natürlich nicht optimal ist (langer Seitenaufbau je nach Anzahl der anstehenden Events und ähnliches).

Leg dir einen VServer zu. Kostet auch nicht viel mehr als vernünftiger Webspace und erlaubt dir Zugriff auf die Commandline.

Original von Kampfhoernchen

Ich würde den Prozess einfach immer laufen lassen, und einmal pro Minute prüfen ob er noch lebt (per Cron) und ggf. abschießen und neustarten.

Wäre das von der Speicherauslastung nicht das gleiche wie ein cronjob der den prozess immer ausführt?

Nein, wenn du jede Minute per "php -f file" das Script aufrufst, wird immer wieder der Interpreter geladen, ein neuer Prozess erstellt und im schlimmsten Fall das Script immer wieder komplett neu geparst und interpretiert (letzteres lässt sich durch eAccelerator verhindern)

Startest du das Script einmal, so ist es schon da und liegt im Op-Code vor, der Prozess existiert, Klassen, Libs, Config und sonstige (meist statische) Daten sind alle schon geladen.

Der Overhead ist wahrscheinlich nicht wirklich groß, aber Kleinvieh macht auch Mist...

Wenn du es nicht in PHP oder anderen Interpretersprachen programmierst und der Code compiliert vorliegt, ist der Overhead sicherlich geringer. Allergings wenn du sowas schon in C oder so machst, ist ein richtiger Daemon auch nicht mehr weit weg ;)

ne bin noch ein reiner PHPler ..

ok also kein cron sondern einfach ein php script aufrufen.. nun ja was ist wenn ich eine Datei die vom Skript geladen wird iwo ändere, dann muss der Prozess ja wieder neugestartet werden.

By the way. kann ich mir das so vorstellen, dass ich die php-Datei einfach mit dem Browser öffne und das Fenster dann schließe, während der Prozess "unendlich" weiterläuft? Oder ein Crontab die datei jeden tag einmal von neu aufruft?

.. oder wie ?  ? 

also wie gesagt in Sachen Server-Module kenn ich mich nicht allzugroß aus, aber ich werde mich bald weiterbilden..  thx2all

Nach jahrelanger Erfahrung mit einem Daemon in C und einem Frontend in PHP rate ich jedoch ersthaft jedem dazu beides in der gleichen Sprache zu schreiben. Zum einen ist das intuitiver, zum anderen profitiert man enorm von Code reusibility und muss das meiste nur einmal schreiben...

Und meiner Meinung nach sind Skriptsprachen definitiv intuitiver und angenehmer. ;) Grad bei einem Daemon ist der Unterschied in Sachen Speicher und Performance eben eher gering - solang man mit einem DBMS und einem getrennten Webserver arbeitet.

Der groesste Vorteil in Sachen Performance ergibt sich aber eben daraus, dass man den Status ueber zwei "Ticks" hinaus speichern kann und es daher u.U. unnoetig sein kann, erneut die Datenbank abzufragen bzw. man nur die Differenz der Daten seit der letzten Abfrage benoetigt.

ok also kein cron sondern einfach ein php script aufrufen.. nun ja was ist wenn ich eine Datei die vom Skript geladen wird iwo ändere, dann muss der Prozess ja wieder neugestartet werden.

Richtig. Laufenden Prozess stoppen - eleganterweise ueber ein Event, das man an den Server pushed, aber er kann auch regelmaessig einen status pollen und im schlimmsten Fall kann man ihn einfach abschiessen.

By the way. kann ich mir das so vorstellen, dass ich die php-Datei einfach mit dem Browser öffne und das Fenster dann schließe, während der Prozess "unendlich" weiterläuft? Oder ein Crontab die datei jeden tag einmal von neu aufruft?

Also wie exe vorher schon schrieb, bei shared hosting gibt es ganz sicher timeouts fuer die Scripts, also mit aufrufen und schliessen ist da nix. Das waere ja noch schoener. ^^

Ob die php.ini Einstellungen fuer Cron ein Timeout haben weiss ich nicht, aber wahrscheinlich ist das schon.

Der sicherste und sinnigste Weg ist ueber die Commandozeile. Wenn du das daemonizen nicht im Prozess selbst erledigst reicht ein "nohup php daemon.php" und er verabschiedet sich in den Hintergrund. Genauso koenntest du es in einer Screen Session starten und gar nicht wirklich daemonizen. Oder du daemonized eben per script selbst und forkst dich von der shell (zumindest macht man es in perl so).

Aber wenn du es ein wenig komfortabel haben moechtest - und ein wenig Verantwortung gegen anderen Shared Hosting Kunden, sowie gegenueber deinen Spielern hast, kommst du um einen vServer oder rootserver sowieso nicht herum. Mit Kommandozeile hat man einfach viel mehr Spass. ;)

Original von omarius

Also bei den agriffen ist das bei mir so geregelt.

Man wählt die zu plündernde Stadt aus, und eine Truppe mit der man angreifen möchte.

Dann wird aus Entfernung und Geschwindigkeit der Einheiten der Truppe die Dauer berechnet, die die Truppe braucht bis sie ankommt.

es wird also ein datensatz wie folgt angelegt:

striker # victim # ... # ankunftszeit

Ich will dann, dass jede sekunde überprüft wird ob ein angriff jetzt getätigt werden soll sprich die ankunftszeit <= time() ist. Berechnet wird der angriff also erst wenn die zeit wirklich gekommen ist, denn die stadt des einen kann vor dem angriff anderes ausgerüstet sein als zum (versprochenen) Zeitpunkt des Angriffs. Daher ein cronjob bro nacht bringts nicht.

Die Berechnug für den Ausgang eines Kampfes dauert etwa 1 Sekunde schätze ich.

Zu Kallisti: Danke, ich weiß jetzt dass ich ein absolute Noob bin in Sachen Server-techniken: event daemon, scheduling usw .. kann sein dass ich ungefähr weiß was es ist aber über diese begriffe komme ich nicht drauf   zu welchem bzw welchen Oberthemen muss ich mich hier Informieren?

An Alle: Kann ich nicht wenn ich den Angriffszeitpunkt berechnet habe manuell einen cronjob anlegen, der sich um diese uhrzeit ausführt und sich danach löscht?

Danke alle male

Mir ging es aber nicht um den Angriffszeitpunkt, sondern wie klein die Differenz zwischen "jetzt" und "ankunftszeit" minimal sofort nach dem Starten des Angriffes sein kann. Also hast du zB. eine Map mit 5min Laufwegen zwischen den Kacheln oder kann man bei geschickter Spielweise (meist über den Zielpunkt steuern und mittendrin abbrechen & angreifen) in Nullzeit angreifen?

Interessiert mich nach wie vor, auch wenn die Sache ja nu wohl mit nem Daemon hübsch gelöst wird. ^^

Sry, hab grad nicht die Zeit den ganzen Topic zu lesen, meine aber meinen Beitrag noch nicht gesehen zu haben:

Ich habe mich auch recht intensiv mit dem Thema beschäftigt und wurde gerne Richtung SQL Programmierung motiviert (das wurde schon bereits woanders duskutiert..).

Jedenfalls möchte ich dir als Alternative zu deinem Cronjob MySQL Events ans Herz legen, solang zu keine zu großen Aktionen vor hast. Wenn das ganze auf zwei drei Queries runterzubrechen ist (Stored Procedure?), wäre das eine schnelle Möglichkeit, wenn auch nur limitiert belastbar - aber deinen Datenbankserver wirst du immer belasten...

Melde mich morgen nochmal zu Wort ;D

> MySQL Events

Und sich damit abhängig von einem kommerziellen GPL-Produkt abhängig machst, bei dem jeder Zeit entschieden werden kann, dass die nächste Version unter AGPL oder gar nicht mehr unter OpenSource läuft...

Würde ich NIEMALS empfehlen.

Ganz unabhaengig davon dann noch die diversen Probleme in Sachen Wartbarkeit, Entwicklungszeit, beschraenkte Moeglichkeiten und vor allem mangehaftes Skalieren, was wir ja schon an anderer Stelle vor ein paar Wochen besprochen haben...

Ach Leute, ihr hackt auf etwas herum, das ihr gar nicht ausprobiert habt.

AGPL? Joa, werd ja meinen Kram auch unter AGPL stellen ;D

Ich würde jedenfalls nach ein Zwischending suchen, weder Daemon noch Eventhandler, möglichst effizient und flexibel.

Einen Großteil der Sachen kann man einfach nachberechnen, einige Dinge sollten aufgrund von Raceconditions nur einmal und von einer höheren Instanz ausgeführt werden.

Dabei spielt einerseits was dir zur Verfügung steht (Serverkapazitäten), aber auch wie dein Spiel überhaupt abläuft eine Rolle. Je mehr Interaktion es zwischen den Spielen gibt, desto höher die Chance, dass es zu Raceconditions kommen kann.

Auf jeden Fall - und da werden mir auch die Kritiker zustimmen - musst du eben auf diese Raceconditions aufpassen, zum Beispiel indem du in der Datenbank Tabellen oder - besser bei großen Tabellen - Einträge sperrst, solange du wichtige Berechnungen anstellst.

Je mehr du dabei in der Datenbank bleibst (statt selectieren+php verarbeitung+updaten nur update), desto schneller und unanfälliger wird es, dafür natürlich auch statischer und unflexibeler. Und, daher auch die Kritik an mir, natürlich sollte die Datenbank nicht unnötig belastet werden.

dir ist schon klar das mysql funktion/stored procedures nicht atomar sind ?

Es sei denn man baut eine Transaktion ein.