Also für mich ist es ein heikles Thema da ich derzeit meine Querys stark reduzieren wegen falschen Scritpen etc...
Habe derzeit einen schnitt von 99 Querys pro klick das ist extrem und bin grad schon auf 45 gesunken!
So wieviele Querys habt Ihr woran muss ich mich orientieren? Ich zäle jeden Query auch die unbuffered wobei ichs immer noch nicht gechekt habe was genau die bringen!
Querys pro Klick
gepostet vor 17 Jahre, 8 Monate von General Crime
gepostet vor 17 Jahre, 8 Monate von Mudder
Also das kann man nicht vergleichen!
Ein simples Build&Raid-Spiel braucht bei weitem nicht soviele Queries wie eine Wirtschaftssimulation. Auch hängt es stark von der Seite ab die aufgerufen wird. Eine Seite mit einem Baumenü braucht andere Abfragen als das Laden einer Karte.
Also ich denke nicht das du dir hier ein Vergleich holen kannst. Dennoch solltest du dein Script optimieren und schauen wie du dinge in ein Cache packst oder Queries zusammenfasst.
Ein simples Build&Raid-Spiel braucht bei weitem nicht soviele Queries wie eine Wirtschaftssimulation. Auch hängt es stark von der Seite ab die aufgerufen wird. Eine Seite mit einem Baumenü braucht andere Abfragen als das Laden einer Karte.
Also ich denke nicht das du dir hier ein Vergleich holen kannst. Dennoch solltest du dein Script optimieren und schauen wie du dinge in ein Cache packst oder Queries zusammenfasst.
gepostet vor 17 Jahre, 8 Monate von Itchy
Also bei mir ist es so, daß jeder Seitenaufruf in Game mindestens 5 Queries erzeugt. Dann kommen noch, je nach Aktion ein paar Queries dazu, das können 1 oder 2 sein (Informationsseiten), bis hin zu deren 100 (Kampfsimulationen mit vielen Teilnehmern).
gepostet vor 17 Jahre, 8 Monate von sami06
also ich komm bei meinem spiel auf min. 20 bis 30 querys pro Seite und je nach dem noch mehr....
handelt sich dabei um eine Aufbauspiel ein bisschen alla ogame...
www.zehnsur.de.tc
handelt sich dabei um eine Aufbauspiel ein bisschen alla ogame...
www.zehnsur.de.tc
gepostet vor 17 Jahre, 8 Monate von knalli
Zusätzlich kann man Queries verbinden.. daher ist die Anzahl nicht unbedingt ausschlaggebend. Zusätzlich kann man bestimmte Logiken theoretisch in die Queries einbauen, um das Ergebnis bereits im Result zu haben.. das macht mehr Arbeit für die Datenbank (bzw den DB-Server).
Ich würde dir empfehlen: baue in deine (hoffentlich existierende) Klasse/Wrapper einfach folgendes Features ein:
Bei jedem Query wird vorher die Zeit (ms) notiert, und danach (ms).. die Differenz ist die benötigte Zeit aller Queries in Millisekunden. (oder du loggst alles mit.. je nach Bedarf).
Wenn du dann zB eine Seite mit 50 Queries hast, die wiederholt schneller als eine Seite ist, wo nur 10 Queries werkeln, würde ich mich primär um diese 10 bemühen, und nicht die anderen 50, die scheinbar schnell durchgehen.
Wobei natürlich immer die Frage ist, ob die 50 wirklich sein müssen und nicht durch JOINs effektiver gingen - je nach DB-Layout.
Ich würde dir empfehlen: baue in deine (hoffentlich existierende) Klasse/Wrapper einfach folgendes Features ein:
Bei jedem Query wird vorher die Zeit (ms) notiert, und danach (ms).. die Differenz ist die benötigte Zeit aller Queries in Millisekunden. (oder du loggst alles mit.. je nach Bedarf).
Wenn du dann zB eine Seite mit 50 Queries hast, die wiederholt schneller als eine Seite ist, wo nur 10 Queries werkeln, würde ich mich primär um diese 10 bemühen, und nicht die anderen 50, die scheinbar schnell durchgehen.
Wobei natürlich immer die Frage ist, ob die 50 wirklich sein müssen und nicht durch JOINs effektiver gingen - je nach DB-Layout.
gepostet vor 17 Jahre, 8 Monate von exe
Ich liege bei 1-5 Queries pro Klick. Zum einen bleiben Daten wie Sprachen, Konfig, Sessions, User u.ä. im Cache und werden nicht bei jedem Aufruf neu geladen. Zum anderen lade ich Daten via AJAX nach wenn sie gebraucht werden.
Wenn z.B. ein Sektor aufgerufen wird werden nur zwei Abfragen gebraucht um die Karte darzustellen. Wenn dann jemand auf ein Gebäude klickt werden die Daten für die Anzeige via AJAX geholt. Man braucht nicht alle Daten, die der User eventuell ansehen könnte, sofort zu laden ...
Ausserdem lassen sich viele Anfragen zusammenfassen. Wenn man z.B. eine Startseite für ein Forum abfragt muss man nicht für jedes angezeigte Forum einen Query absetzen um das letzte Thema in diesem Forum herauszufinden. Sowas lässt sich auch mit joins verbinden.
IMHO läuft da was falsch wenn bei einem Klick 50-100 Queries an die Datenbank abgesetzt werden.
Wenn z.B. ein Sektor aufgerufen wird werden nur zwei Abfragen gebraucht um die Karte darzustellen. Wenn dann jemand auf ein Gebäude klickt werden die Daten für die Anzeige via AJAX geholt. Man braucht nicht alle Daten, die der User eventuell ansehen könnte, sofort zu laden ...
Ausserdem lassen sich viele Anfragen zusammenfassen. Wenn man z.B. eine Startseite für ein Forum abfragt muss man nicht für jedes angezeigte Forum einen Query absetzen um das letzte Thema in diesem Forum herauszufinden. Sowas lässt sich auch mit joins verbinden.
IMHO läuft da was falsch wenn bei einem Klick 50-100 Queries an die Datenbank abgesetzt werden.
gepostet vor 17 Jahre, 8 Monate von HSINC
es gibt kein limit für eine queryanzahl pro seitenaufruf. es ist aber eine weit verbreitete irre annahme das die queryanzahl in irgendeinem bereich um die 20-30 liegen sollte, warum auch immer.
es gibt eine menge faktoren für geschwindigkeit, aber die reine queryanzahl spielt da gar nicht rein. eher primär die db struktur und die inwiefern die querys in sich optimal sind (wobei da wieder das db design reinspielt). wenn man nun auf zwang querys spaaren will und dadurch komische abfragen produziert (also unoptimale) hat man durchaus die chance das das ganze langsamer wird.
insofern wäre der hinweiss eher dem problem optimal angepasstes db design zu benutzen und seine querys so zu stellen das sie an das db design angepasst sind.
es gibt eine menge faktoren für geschwindigkeit, aber die reine queryanzahl spielt da gar nicht rein. eher primär die db struktur und die inwiefern die querys in sich optimal sind (wobei da wieder das db design reinspielt). wenn man nun auf zwang querys spaaren will und dadurch komische abfragen produziert (also unoptimale) hat man durchaus die chance das das ganze langsamer wird.
insofern wäre der hinweiss eher dem problem optimal angepasstes db design zu benutzen und seine querys so zu stellen das sie an das db design angepasst sind.
gepostet vor 17 Jahre, 8 Monate von General Crime
Ok vielen Dank werde mich mal an einige ratschläge halten!
gepostet vor 17 Jahre, 8 Monate von Kapsonfire
ich komme auf maximal 15...... liegt aber wohl daran das ich mit frames arbeite
gepostet vor 17 Jahre, 8 Monate von knalli
Original von Browser-Games World
ich komme auf maximal 15...... liegt aber wohl daran das ich mit frames arbeite
Naja.. ich denke zwar, das unser BG nicht gerade hochkomplex ist (zu manch anderem).. aber unter der Prämisse, das es noch suboptimal ist, haben wir eine durchschnittliche Queryanzahl von 3-4.. manchmal auch 10. Demnächst noch 3 zusätzliche 3 wegem SessionHandler über DB (Heap). Und das neue ist ohne Frames.. und hat nicht mehr Queries!
gepostet vor 17 Jahre, 8 Monate von mifritscher
Meist so 5-7, wenn alles zusammen kommt 20.
Unser Sessionsystem läuft auch komplett über die DB.
Könnten zwar vielleicht über einige Tricks das ein oder andere Query sparen, aber bei uns schläft der mysql-Server fast, die Hauptlast erzeugt trotz apc der apache. Aber ich mein, bei Durchlaufzeiten von 20-50 ms wirkt sich schon ein HDD-Zugriff verherrend aus *g*
Unser Sessionsystem läuft auch komplett über die DB.
Könnten zwar vielleicht über einige Tricks das ein oder andere Query sparen, aber bei uns schläft der mysql-Server fast, die Hauptlast erzeugt trotz apc der apache. Aber ich mein, bei Durchlaufzeiten von 20-50 ms wirkt sich schon ein HDD-Zugriff verherrend aus *g*