max_questions / max_queries

[plopp]

Hallo,
letzte Woche hat mein Hoster einen Parameter bei seinem mysqld gesetzt, der den Server vor Überlastung schützt.
Das Ergebnis war, das meine vms-seite massiv Fehler brachte. Keine Fehlermeldungen an sich, sondern die User meldeten, das diverse Funktionen nicht mehr richtig liefen. z.B. wurden Banner nicht mehr vergütet, Einsätze und Gewinne bei Spielen nicht gebucht.

phpmyadmin brachte:
#1226 - User 'dbuser6550' has exceeded the 'max_questions' resource (current value: 18000)


Bedeutet, das das Limit von 18k db-zugriffen pro Stunde aufgebraucht war.
Mein Hoster hat nun das Limit kurzzeitig auf 36k gesetzt, damit ich Zeit habe, das Script zu optimieren. Aber selbst das hat nicht gereicht.
Ich habe mir schnell was eingebaut, was die db-abfragen mal mitlogt und habe das dann ausgewertet. In der Woche, wo ja weniger als am Wochenende los ist, hatte ich so schon über 40k Zugriffe in der Stunde. Dabei wurden 100% noch nicht alle Anfragen aufgezeichnet, weil viele Games z.B. nicht über die functions.lib gehen und selbst auf die DB zugreifen.

Besonders schlimm war, das bei Aus- und Einzahlungen erst die Schnittstelle bedient wird und dann der Ab-/Zugang auf dem Konto im VMS gebucht wird. War dann so, das der User sein Guthaben über die Schnittstelle ausgezahlt bekommt, das dann aber nicht im VMS registriert wird.
Ein User hat das dann auch schnell spitz bekommen und ausgenutzt. Zum Glück hat ein User, der ebenfalls eine VMS-Seite betreibt, zufällig zu diesem Zeitpunkt abgebucht, den Fehler bemerkt und mich informiert. Nicht auszudenken, was sonst noch passiert wäre ...


Die letzten Tage habe ich nun optimiert was das Zeug hält und komme in aktiven Zeiten auf 17K in der Stunde. Das reicht immernoch nicht, weil mir die zu 18K einfach zu knapp ist.
Das Script ist in Bezug auf DB-Zugriffe einfach erschreckend. SELECT-Anweisungen werden nur selten mit JOIN oder WHERE zusammengefasst. klick4.php, die hier oft schon angesprochen wurde, ist ein Graus. Ich habe da nun nur noch 2 Anweisungen ... eine, was im reload ist, eine was nicht im reload ist. Spart so schon Tausende von Zugriffen ein und gibt sogar mehr Info aus als vorher.

Ich werde nun nicht alles verraten, was ich mir in den letzten Tagen mühevoll erarbeitet habe. Seit einer Woche bin ich nun dabei und es ist noch nicht erledigt.
SQL ist wesentlich mehr als INSERT, SELECT, UPDATE, DELETE.


Was wichtig wäre: wie kann man nun DB-Anfragen die nicht ausgeführt werden, wiederholen? Setzt voraus, das man eine DB-Anfrage nicht nur einfach so ausführt sondern auch den Rückgabewert auswertet. DB-Anfragen müssten vorher festgehalten werden und die Ausführung überprüft werden.

Macht die Augen nicht zu bei diesem Problem, evtl. setzt euer Hoster auch gerade diesen Wert und auch bei euch geht nichts mehr

Ich hoffe, dass das neue VMS besser wird in Sachen DB-Abfragen. Seit mysql 4.0 gibts den Parameter MAX_QUESTIONS und immer mehr Hoster werden diesen Wert setzen.

[PeterLV]

Original von plopp

Ich werde nun nicht alles verraten, was ich mir in den letzten Tagen mühevoll erarbeitet habe. Seit einer Woche bin ich nun dabei und es ist noch nicht erledigt.
SQL ist wesentlich mehr als INSERT, SELECT, UPDATE, DELETE.

ja weisst du,

vielleicht ist dieser satz, der grund fuer die fehlenden antworten??

peter

[plopp]

Original von PeterLV
ja weisst du,

vielleicht ist dieser satz, der grund fuer die fehlenden antworten??

peter

Also im Klartext: wenn ich meine Arbeit von über eine Woche hier veröffentliche, bekomme ich evlt. Antworten? Optimierer bekommen für ihre Arbeit 50 Euro und ich gebe mein Wissen nun kostenlos weiter ... ja klar
Ich muss auch für jeden Download hier zahlen und addons und Spiele bekomme ich auch nicht umsonst
Auch wenn ich das hier aufzeigen wollte ... es ist einfach zuviel. Es sind nicht einfach nur 2-3 Seiten wo ich was ändern musste, es ist wesentlich mehr.

Zwei Tipps geb ich aber mal:
Bei Ralleys wird geschaut, ob der User schon einen Wert am Tag geschrieben hat (select). Wenn ja folgt ein update, wenn nicht ein insert.
mysql bietet "insert ... on duplicate key update" an. Sieht dann z.B. so aus:

db_query ("
INSERT INTO ".$db_prefix."_dynklickralley (uid,klicks)
VALUES ('".$_SESSION['uid']."','1')
ON DUPLICATE KEY UPDATE klicks = klicks + 1
");

... ups, jetzt hätte ich das doch als Paket fertig machen können und hier in den Downloadbereich stellen können. Schade um die Downies

2. wäre etwas, was man beim Senden von Mails verwenden könnte. Ich habe es noch nicht umgesetzt, ist aber in Arbeit.
sql bietet die Möglichkeit an, insert-anweisungen zusammenzufassen. Also nicht je versendeter Mail ein insert sondern die inserts in z.B. einem array sammeln und dann geschlossen in einer einzigen Anweisung eintragen.
Das select davor entfällt. Macht 1 db-zugriff pro banner/mail/wasweissichwas aus ... 20k bannerklicks am tag .....

Ich glaube, das viele vms-seitenbetreiber noch nie von diesem Problem gehört haben. Das ihr Hoster diesen Wert nicht gesetzt hat oder sie evtl. noch nie an die Grenze gestossen sind. Evt. haben sie es auch noch nicht gemerkt, vms gibt keine Fehlermeldungen von mysql weiter. Es findet nirgens eine Auswertung der Rückgabewerte statt. Entweder die sql-Anweisung geht durch oder eben nicht ... Pech, wenn es eben eine Auszahlung mit hohem Betrag war.
Ich hab auch erst gedacht "nicht so schlimm, dann gibts eben mal keine Bannervergütung, Reloads werden nicht geschrieben ... in einigen Minuten gehts wieder und die User können die Banner nochmal klicken". Bis ich dann den Hinweis bekam, das es bei Auszahlungen Probleme gibt. Ein User hatte dann auch über 50 mal verucht auszuzahlen und es wurde auf der vms-seite nicht vermerkt. Real wurde aber ausgezahlt. Und der User hatte noch mehr vor, zahlte einen hohen Betrag ein und wollte wohl warten, bis die Seite wieder "klemmt" und dann richtig absahnen.

Eigentlich sollte das Aufzeigen von diesem Fall schon Hilfe sein.

Grüsse

[plopp]

Hm, das war wohl doch nicht der Grund. Schade. Nun hab ich schon was darüber gesagt was ich so gemacht habe und trotzdem keine Antworten oder Unterstützungen. Schade.

[Masterphil]

So, habe diesen Threat von Anfang an beobachtet und da du ja regelrecht um eine Antwort bettelst tu ich dies nun mal.

Also zu den Datenbank-Problem gabs schon zig Beiträge, auch und vorallem in den alten Forum was nun nicht mehr ist.

Sämtliche Beiträge gingen in etwa doppelt soweit wie deiner, und alle wollten immer dick Lose sehen, um es bei anderen volständig zu machen.

Mit deinem Threat hier ist aus meiner Sicht niemanden geholfen, da die meisten sich mit sql und Datenbanken eh nicht so wirklich auskennen.

Also gib mal ein paar konkrete Veränderungen, so wie es sie schon für die klick4.php gab/gibt.

Wie gesagt, das Problem mit den DB- Sachen besteht schon sehr lange, ohne das bisher jemand ne Anleitung zur kompletten Optimierung des Scrits angeboten hat.

Einzig ein User ist bekannt dafür, das für entspr. Bezahlung ordentlich zu machen.

Veröffentliche wenigstens Teile deiner Erfolge, damit wäre vielen hier geholfen, mich eingeschlossen.

MfG

und gute Nacht