Script"diskussion"

[ice-breaker]

ich habe doch nie behauptet dass schleifen nutzlos sind und man nicht verwenden sollte - man kommt doch gar nicht drumrum .... ich habe nur gesagt dass man lösungen ohne schleifen auch machen kann und diese dann auch besser sind !!!!!!!!!!!!!! und das ist kannst du einfach nicht wiederlegen weil es nunmal die wahrheit ist!

Wären solche Zugeständnisse schon früher gekommen, dann hätten wir uns viel Stress sparen können. Klar kann man es auch anders lösen, aber in ner Schleife ist es meist nunmal besser gelöst. Vor allem weil du wieder alles umdrehst, es ging darum, dass du gesagt hast, es sei besser im Code 10mal hintereinander einen code aufzurufen, statt eine Schleife zu nutzen.
In diesem ganzen thread änderst du dauerhaft die aussagen

und erzähl mir doch nix dass du dich mit schleifen gegen minuscaches schützen kannst - schwachsinn! wenn dann must du mit LOCK TABLE arbeiten und das nochmal extra überprüfen und sichern, ne schleife bringt dir dort gar nix!

Es gibt andere Möglichkeiten als LOCK TABLES sicherzustellen, dass kein Minustopf ensteht, und im Gegensatz zu dir schreibe ich net nur groß rum, sondern werde meine Aussagen auch belegen:

<?php

do{
    $repeat = false;
    $gewinn = 0;
    $zahl = rand(1,2);
    if ($zahl == $wahl) $gewinn = $einsatz * $multiplikator;
    if($gewinn>$gewinntopf || mysql_affected_rows($db->query("UPDATE `slot` SET `gewinntopf`=`gewinntopf`-%d WHERE `id`=%d and `gewinntopf`>=%d",$gewinn,$slot["id"],$gewinn))==0){
      $repeat=true;
    }
} while ($repeat);

?>

Und das funzt, ist zwar schnell Quick&Dirty gemacht, aber egal, mal sehen, wann ich diese Idee in deinen Spielen wiederfinde Und darauf wäre jeder gekommen, der sich nen bissel auskennt
Die effizenteste Methode neg. Gewinntöpfe zu unterbinden ohne den immensen Geschwindigkeitsverlust durch gelockte Tabellen oder Transaktionen aus InnoDB.

Ein wenig Kreativität hat noch keinem geschadet, geht nicht gibts nicht

 

[chuone]

ich habe das von anfang an so geschrieben ... leß nach!
das mit dem 10x hinschreiben ist nunmal schneller!!!! ob nun übersichtlich zum ändern ist egal, wenn was fertig ist ändert man nicht ständig was rum, und selbst wenn wo ist das problem 10x das gleiche zu ändern, als ob das so lange dauert! - unsinnig etwas wegen komfort zum ändern zu verlangsamen - wenn es 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000x mehr normal durchläuft als man es ändert!

ich ändere nirgends meine aussage, schau hin!

dein beispiel funktioniert - wie ich gesagt hab du musst es nochmal extra absichern, gut ohne lock tables gehts auch - ich halte diese methode jedoch für die sichere (ist einfach 100% sicher, deine ist nur 99,9% sicher, glaub mir: er fragt ab wie hoch der cache ist, in der zeit ist es möglich den cache durch ne anderen user zu setzen und dann bist du auch im minus -> cache lesen -> cache neusetzen -> cache neusetzen) und genau für sowas gibt es diese funktion auch, und so lahm wird das ganze dadurch auch nicht. das ganze hat jedenfalls nix mit schleifen zutun, ich kann deinen check auch ohne schleife machen UND es ist auch dann besser gelöst, da er nich mehrmals den cache neuauslesen muss!

 

[ice-breaker]

chuone, da muss ich nunmal tiefer in die tasche greifen^^
du weisst wie mysql funzt?
ein lock-tables sperrt für den gesamten zeitraum die gesammten lese und schreibzugriffe.
meine methode kann weiterhin lesen bis es zu dem update-befehl geht, mysql wird ebenfalls in diesem moment einen kompletten lock durchführen, weshalb der update nur ausgeführt wird wenn noch lose im cache sind, da kann mysql nix dran rütteln, es kann net anders, sonst wären die where bedingungen ja total sinnlos

ich habe mich lange mit datenbanken beschäftigt, ich kann dir versichern, dass meine methode zu 100% funktioniert (da würde ich um alles wetten) und zig mal perfomanter als lock tables ist, denn hab mal 20-30 leute gleichzeitig am selben slot und deshalb an der gleichen tabelle, du wirst extreme geschwindigkeitseinbrüche feststellen, weil dafür MyISam nicht gedacht ist. Will man eine Transaktionssicherheit und trotzdem schnelle Tabellenaktualisierungen sollte man zu InnoDB wechseln und sich mit dessen Gegebenheiten auseinandersetzen.

 

[raven]

ChuOne, du benutzt nicht wirklich LOCK TABLES, oder?
Dann kannst du dein ganzes Performance-Gerede sowieso übern Haufen schmeißen, das bringt dann nämlich gar nichts. Wenn du die komplette Tabelle sperrst, dann bleibt im Prinzip erstmal alles stehen, bis die Tabelle wieder freigegeben ist. Da musst du schon zeilenweise Sperrung / Transaktionen benutzen.

Und nochmal zum Thema 10x / Schleife:
Hast du Tyrells Post mit seinem Benchmark gelesen?
Der Unterschied bei 10 Ausführungen ist genau 0,0001 Millisekunden, das ist nun wirklich Kinderkram. Da sollte es doch eigentlich eine Selbstverständlichkeit sein, der Codequalität vortritt zu lassen, wie auch in allen anderen Fällen - so eine kurze Unterbrechung ist schlicht und einfach nicht spürbar.

 

[chuone]

das letzte was ich dazu schreibe , ich bin echt fertig mit diesem thema hier!

wenn mysql die sachen eh lockt, warum gibt es die lock funktion,
wenn man die tabelle lockt warum ist es dann langsamen als wenn mysql die tabelle eh schon lockt . da is ein sehr großer wiederspruch ice breaker.

wie gesagt ich locke die tabelle nur für den jackpot, bei dem rest ist das mehr oder weniger egal, die wahrscheinlichkeit ist a. sehr gering und b. geht der cache dann genauso schnell wieder ins plus, als das ich da nen sinn sehe das nochmal extra zu sichern und performence zu verlieren. und selbst bei neg. cache laufen meine games nunmal - und geben halt keinen gewinn bis sie wieder im plus sind.

ich hab nie behauptet dass es ein großer unterscheid ist, ich hab nur gesagt dass es besser ist - auch wenn es nur 0,0001 ms besser ist, ist es besser - du raven allerdings warst der meinung die schleife ist besser !
und 0,0001 ms können schnell zu 1 ms werden - wenn der server ausgelastet ist und viele male diese schleife unnötig aufgerufen wird, weil gerade viele viele user die php aufrufen.
und komfort geht auch nicht verloren! ich hab kein problem damit 10x das gleiche anzupassen .. wenn du das hast bist du einfach nur faul!

frag mal leute die php optimieren ob man auf schleifen verzichten sollte wenn es sinn macht oder schleifen immer nehmen soll, auch wenn man nur 10x das gleiche ausgeben will / 10x die gleiche funktion aufrufen will!

und was ist bitte besser? etwas was genau das gleiche ergebnis liefert und dabei genauso sicher ist aber zugleich schneller ist? nee wa......

und ja ich nutze lock tables in weniger fällen wo es sinn macht - ich gehe da lieber auf nummer sicher als dass nachher die tabelle bricht oder sonst was passiert ! leß mal die docu zu lock tabeles, lock tables soll mysql sogar noch schneller machen in eingen fällen !

erzähl mir ausserdem nix von performence, ich hab extra wegen der performence ein schnelles datenbanksystem geschrieben und lass die gewinnberechnung z.b. nicht mehrmals durchlaufen!

ihr 2 müsst -vorallem raven - noch so einiges an erfahrung sammeln - auch wenn eurer grundwissen noch so gut ist oder sogar besser als meins ist - was wirklich wert hat ist erfahrung!

 

[Hotwave]

ihr 2 müsst -vorallem raven - noch so einiges an erfahrung sammeln - auch wenn eurer grundwissen noch so gut ist oder sogar besser als meins ist - was wirklich wert hat ist erfahrung!

Musst du immer von dir auf Andere schließen?...Das scheint wohl eine deiner am meisten ausgeprägten Neigungen zu sein

 

[chuone]

 

[White]

wie gesagt ich locke die tabelle nur für den jackpot, bei dem rest ist das mehr oder weniger egal, die wahrscheinlichkeit ist a. sehr gering und b. geht der cache dann genauso schnell wieder ins plus, als das ich da nen sinn sehe das nochmal extra zu sichern und performence zu verlieren.
ich hab nie behauptet dass es ein großer unterscheid ist, ich hab nur gesagt dass es besser ist - auch wenn es nur 0,0001 ms besser ist, ist es besser - du raven allerdings warst der meinung die schleife ist besser

Zu 1. hier gehst du mit der AUssage ran die warscheinlichkeit ist sehr gering. Aber bei den Schleifen willste garkeine warscheinlichkeit haben.

Zu 2. Wenn du umbedingt auf jeden Komfort beim coden verzichten willst für maximalen speed dann lern Assembler oder noch besser schreib gleich Binärcode.

 

[chuone]

Zu 1. hier gehst du mit der AUssage ran die warscheinlichkeit ist sehr gering. Aber bei den Schleifen willste garkeine warscheinlichkeit haben.

Zu 2. Wenn du umbedingt auf jeden Komfort beim coden verzichten willst für maximalen speed dann lern Assembler oder noch besser schreib gleich Binärcode.

mir war das klar, dass das kommt, deshalb doch nochmal ganz kurz:
schleifen - welche hängenbleiben oder mehrere sekunden laufen könnten , will ich ausschließen.
beim cache wo nix weiter passiert als das er kurze zeit im minus ist - und die wahrscheinlichkeit darauf eh schon sehr gering ist - lege ich keinen besonderen wert drauf das extra abzusichern und dabei performence zu verlieren.

 

[White]

mir war das klar, dass das kommt, deshalb doch nochmal ganz kurz:
schleifen - welche hängenbleiben oder mehrere sekunden laufen könnten , will ich ausschließen.
beim cache wo nix weiter passiert als das er kurze zeit im minus ist - und die wahrscheinlichkeit darauf eh schon sehr gering ist - lege ich keinen besonderen wert drauf das extra abzusichern und dabei performence zu verlieren.

Mann kann jedoch bei solchen Schleifen wo halt der zufall mit rein spielt einfach ne If abfrage machen die sagen wir mal nach 10 durchläufen den User bescheisst und sagt sry hast nix gewonnen.

 

[chuone]

Mann kann jedoch bei solchen Schleifen wo halt der zufall mit rein spielt einfach ne If abfrage machen die sagen wir mal nach 10 durchläufen den User bescheisst und sagt sry hast nix gewonnen.

richtig, aber würde ich meine gewinnberechnung 10x durchlaufen lassen würde mir das schon zulange dauern und dieser block funktioniert auch nicht ohne dass man den gewinn dann eh blockt
wenn du bei den stanigamecodes einfach break; machst, dann wird nachher ein gewinn angezeigt aber nicht gutgeschrieben.
und wenn man ihn eh blockt, kann man auch nur einmal den gewinn berechnen und wenn er eben nicht in den cache passt blocken -> nix gewonnen.
sicher macht es vielleicht sinn son break zu verwenden, aber ich sehe nix wo es wirklich sinn macht - lieber von vorne herrein die schleife auf 10 durchgänge begrenzen ( dass er immer 10x läuft, z.b. bei gästebüchern, 10 einträge pro seite ) oder keine schleife nehmen.

 

[ice-breaker]

wenn mysql die sachen eh lockt, warum gibt es die lock funktion,
wenn man die tabelle lockt warum ist es dann langsamen als wenn mysql die tabelle eh schon lockt . da is ein sehr großer wiederspruch ice breaker

das ist kein Wiederspruch, du hast den Unterschied net verstanden

frag mal leute die php optimieren ob man auf schleifen verzichten sollte wenn es sinn macht oder schleifen immer nehmen soll, auch wenn man nur 10x das gleiche ausgeben will / 10x die gleiche funktion aufrufen will!

sry. aber das ist quatsch, man optimiert kein PHP, man optimiert Datenbanken, denn lassen sich viel größere Performanceschübe holen, ich habe zB für nen kleines mittelständiges Unternhemen in Frankfurt ne VLDB (Very Large Database) mit 80GB optimiert und einen Performanceschub des Faktors 150 rausgeholt, mit PHP-Optimierung holst du da gar nix raus.

und ja ich nutze lock tables in weniger fällen wo es sinn macht - ich gehe da lieber auf nummer sicher als dass nachher die tabelle bricht oder sonst was passiert ! leß mal die docu zu lock tabeles, lock tables soll mysql sogar noch schneller machen in eingen fällen !

Sry, aber das hast du dir mal wieder aus den Fingern gezogen, denn es ist logisch komplett unmöglich. Denn Lock-Tables locked über einen gesammten Zeitraum, ein Lock bei einem Update-Befehl ist nur die paar msec aktiv. Wäre schön, wenn du die Stellen aus dem Doku lieferst.

erzähl mir ausserdem nix von performence, ich hab extra wegen der performence ein schnelles datenbanksystem geschrieben und lass die gewinnberechnung z.b. nicht mehrmals durchlaufen!

das ist jetzt aber net dein Ernst? Mit deinem Wissen kannst du niemald ein komplexes DBMS schreiben, denn das ist mit eines der schwersten Dinge. Und eine richtige genutzte MaxDB-Datenbank (Industrie-Datenbank) ist einfach rasend schnell, da gibt es kaum besseres.

ihr 2 müsst -vorallem raven - noch so einiges an erfahrung sammeln - auch wenn eurer grundwissen noch so gut ist oder sogar besser als meins ist - was wirklich wert hat ist erfahrung!

Ich glaube jemand anderes sollte noch lernen, Erfahrung ist gut, und haben ma auch, verlass dich drauf, aber nur mit dem nötigen Expertenwissen schaffst du wirkliche geniale Sachen, gerade Datenbankperformance ist sehr sehr wichtig, das ist der Flaschenhals aller Webanwendungen.

richtig, aber würde ich meine gewinnberechnung 10x durchlaufen lassen würde mir das schon zulange dauern

musst du immer von dir auf andere schließen?

 

[chuone]

ice wieder alles nur ohne wirklich zu wissen von was du redest,
du weist nich wie ich arbeite und was ich drauf habe.
wenn ich den teil aus der docu find post ich ihn hier .... red nicht von sachen die du nicht verstehst, denn es stand nunmal in der offizielen doc von mysql dass man mit lock tables optimieren kann - du weist es doch gar nicht - ich habs gelesen, du nicht, und nur weil du es nicht gelesen hast denkst du irgendwas dir aus!
wenn man keine datenbank braucht, optimmiert man natürlich die datenbank und nich den phpcode - man optimiert beides und man optimiert auch den server!


INSERT-, UPDATE- und DELETE-Operationen sind in MySQL sehr schnell, aber Sie können eine noch bessere Gesamtperformance erzielen, indem Sie Sperren für alles setzen, was mehr als fünf Einfüge- oder Änderungsoperationen in einem Datensatz umfasst. Wenn Sie sehr viele Einfügeoperationen in einem Datensatz vornehmen, könnten Sie ab und zu (d. h. etwa alle 1.000 Datensätze) ein LOCK TABLES gefolgt von einem UNLOCK TABLES absetzen, damit auch andere Threads auf die Tabelle zugreifen können. Dies bringt trotz allem einen ansehnlichen Leistungsgewinn.

https://dev.mysql.com/doc/refman/5.1/de/insert-speed.html

 

[bastie]

was willst du uns damit sagen? was ist das für ein fahrzeug?

 

[ice-breaker]

Ich denke mir nicht etwas aus, habe ich net nötig
Im Gegensatz zu dir habe ich mich 1 Jahr lang mit Datenbankoptimierung beschäftigt und weiß daher sehr gut was im Hintergrund alles passiert (Thema: Indizies, Joins, etc etc).
Und ein lock table KANN eine Datenbank nicht beschleunigen, da es den gesamten Zugriff auf eine Tabelle sperrt, da lase ich mich gerne auf eine Diskussion ein, nenne mir ein Anwendungsgebiet wo eine Sperre auf eine Tabelle die Anwendung beschleunigt und ich gebe dir Recht, leider wirst du nichts finden, da Datenbanken ja extra auf parallele Zugriff optimiert sind und dafür gemacht wurden.

 

[Hotwave]

was willst du uns damit sagen? was ist das für ein fahrzeug?

Wahrscheinlich soll das Artwork o.Ä. von ihm sein

 

[chuone]

was willst du uns damit sagen? was ist das für ein fahrzeug?

damit wollt ich nur sagen, no comment .. das is mein honda

Wahrscheinlich soll das Artwork o.Ä. von ihm sein

das ist ein ganz normales foto

ice:

INSERT-, UPDATE- und DELETE-Operationen sind in MySQL sehr schnell, aber Sie können eine noch bessere Gesamtperformance erzielen, indem Sie Sperren für alles setzen, was mehr als fünf Einfüge- oder Änderungsoperationen in einem Datensatz umfasst. Wenn Sie sehr viele Einfügeoperationen in einem Datensatz vornehmen, könnten Sie ab und zu (d. h. etwa alle 1.000 Datensätze) ein LOCK TABLES gefolgt von einem UNLOCK TABLES absetzen, damit auch andere Threads auf die Tabelle zugreifen können. Dies bringt trotz allem einen ansehnlichen Leistungsgewinn.

https://dev.mysql.com/doc/refman/5.1/de/insert-speed.html

 

[ice-breaker]

verstehst du was da beschrieben wird? Es geht darum dass massive Einfügeoperationen dadurch abgebremst werden, dass parallel Anfragen auf diese Daten ausgeführt werden, und das ist sicherlich kein reales Anwendungsgebiet, da die Indexerstellung für diese massiven Einfügeoperationen sehr viel Zeit beanspruchen, gerade bei VLDBS dauert sowas ewig.
Und das ist auch kein Beispiel für eine Gameberechnung eines Slots im Gegenteil.

 

[chuone]

verstehst du was da beschrieben wird? Es geht darum dass massive Einfügeoperationen dadurch abgebremst werden, dass parallel Anfragen auf diese Daten ausgeführt werden, und das ist sicherlich kein reales Anwendungsgebiet, da die Indexerstellung für diese massiven Einfügeoperationen sehr viel Zeit beanspruchen, gerade bei VLDBS dauert sowas ewig.
Und das ist auch kein Beispiel für eine Gameberechnung eines Slots im Gegenteil.

du wolltest ein anwendungsgebiet, jetzt hast du eins -sag doch nicht real oder unreal, oder bist du echt so begrenzt dass du niemals mehrere tausend zeilen einfügen würdest? das brauch ich sogar.
- und du sagst ich hab gelogen? ich hab nie gesagt dass es für games relevant ist - ich hab nur gesagt dass man mit dieser lock geschichte auch optimieren kann und zwar ganz allgemein!

 

[ice-breaker]

ich hab nie gesagt dass es für games relevant ist - ich hab nur gesagt dass man mit dieser lock geschichte auch optimieren kann und zwar ganz allgemein!

k, das klang jedoch genau so (und es steht vorher nichts wiedersprüchliches da), dass du mit Lock Tables deine DB optimieren willst.
dann entschuldige mich, neija ich klinke mich aus der Diskussion nun mehr oder weniger aus, auf diesem Niveau, dass du dir immerwieder alles später zurecht drehst, wie du es dann brauchst, bringt das nix.