Vielen Dank für deine Einsicht und mithilfe
Es tritt so ab 25-30 Usern auf ... schwer zu sagen ... auch mal schon ab 20 ... ist dann aber stabil lahm
Es kam so ab ca. 500-600 Usern. Da habe ich auch angefangen etwas mehr für die Klicker zu tun und spätestens seit den Team-Rallyes ist die Seite (soll sie werden) auch für Klicker interessant.
Ich vermute mal stark, dass es mit dem Klickbereich zusammenhängt (also vorallem). Ich selbst hatte kein Problem beispielsweise 100 Games (Spieler) zu simulieren. Also mehrere 100 Anfragen pro Minute waren "kein Problem" ... zumindest von den Games. In diesem Test war die Seite im Wartungsmodus, sodass nur ich und ein paar Tester online waren.
Also der Gaming-Bereich läuft (scheinbar) einwandfrei. Will ja auch nicht immer alles auf die Klicker schieben, aber ich vermute halt sehr stark, dass es eher an den klickern liegt. Zumal ich eine Slot-Begrenzung von max. 3 Slots (Fenster) pro User eingebaut habeBei den Klicks (bisher) nicht. Also dass beispielsweise nur eine Werbe-Art (Paidbanner) geklickt werden kann, und nicht mehrere auf einmal (Paidbanner u. Paidlinks) ist bei mir bisher nicht der Fall ... es geht ja auch bei anderen ohne. Habe nun allerdings die max. Banner (und Linkanzahl) pro Seite auf 10 pro User beschränkt. Dadurch wird die Seite jedoch nur ein wenig schneller ...
Beste Grüße
Jo
P.S. ich hoffe ich hab nix vergessen![]()
Was ich noch nachreichen wollte. Hier mal ein paar "wichtige" bzw halt rote (schlechte) Daten aus meiner MySQL-Laufzeit-Status-Anzeige (innerhalb von PHPMyAdmin)
Aus der mysql-slow.log geht aber nicht wirklich viel hervor. Ich habe das Gefühl dort gibt mir das Script alle Abfragen aus. Obwohl ich die "long-query-time" auf 5 sek. gestellt habe, stehen dort auch Abfragen drin, die schneller gingen. Wahrscheinlich liegt es dabei dann an "log-queries-without-indexes" (o.ä.) welches ich auch mal aktiviert HATTE (beides deaktiviert - also das komplette logging von slow-queries wurde deaktiviert). Da stoße ich dann aber leider an Wissensgrenzen, bzw. sehe keine Indizes-ProblemeSlow_queries 118 k (Anzahl der Anfragen, die länger als long_query_time benötigten.)
Wahrscheinlich siehe obenHandler_read_rnd 247 k (Anzahl der Anfragen, eine Zeile basierend auf einer festen Position zu lesen. Dieser Wert wird hoch sein, wenn Sie viele Anfragen ausführen, die erfordern, dass das Ergebnis sortiert wird. Wenn Handler_read_rnd hoch ist, haben Sie wahrscheinlich viele Anfragen, die MySQL zwingen, ganze Tabellen zu scannen, oder Sie haben Joins, die Schlüssel nicht richtig benutzen.)
Wahrscheinlich siehe obenHandler_read_rnd_next 100 M (Anzahl der Anfragen, die nächste Zeile in der Daten-Datei zu lesen. Dieser Wert wird hoch sein, wenn Sie viele Tabellen-Scans durchführen. Im Allgemeinen weist das darauf hin, dass Ihre Tabellen nicht korrekt indiziert sind, oder dass Ihre Anfragen nicht so geschrieben sind, dass Sie Vorteile aus den Indexen ziehen, die Sie haben.)
Wahrscheinlich siehe obenOpened_tables 2.449 (Anzahl der Tabellen, die geöffnet wurden. Wenn Opened_tables hoch ist, ist Ihre table_cache-Variable wahrscheinlich zu niedrig.)denke nicht dass diese Variable mit 2048 (ohne Einheit) zu niedrig ist. Oder sollte man die nocoh etwas höherschrauben? Hab halt viel gegooglet in letzter Zeit und eigentl. wurde mir oft 1024 vorgeschlagen (bei ähnlicher Server-Config) ...
Siehe Punkt 1 ... Stoße da leider (scheinbar) an WissensgrenzenTable_locks_waited 33 k (Wie oft eine Tabellensperre nicht sofort erlangt werden konnte und gewartet werden musste. Wenn dieser Wert hoch ist und Sie Performance-Probleme haben, sollten Sie zunächst Ihre Anfragen optimieren und dann entweder Ihre Tabelle(n) zerteilen oder Replikation benutzen.)bin aber bereit diese zu füllen
Danke nochmal für Euer offenes Ohr und euer Engagement
Jo
edit: sorry for Doppelpost, aber dies alles in nen Edit zu packen, fand ich zu heftigBitte um Gnade ...
Das ist (bei dem Server vorausgesetzt, auf einem Webspace könnte es etwas zu groß sein) absolut im grünen Bereich.
OK, da kann man quasi immer was optimieren, ein paar Indizes etc. wobei diese Werte alle nicht direkt auf ein totales "lahmen" des Servers hindeuten.
Was steht den ganz oben bei der Statistik von der Menge der Abfragen?
Also Abfragen /Sekunde (Durchschnitt), Minute/Stunde?
Hast du/User deine Seite in einer Surfbar oder so einem *** oder Besuchertausch *** eingebucht?
Da kann das auch mal zu extremen "Spitzen" kommen, wenn auf einmal das Programm drin ist und die 1000 Chinesen, die schon alle weg haben, dann glei9chzeitig deine Seite aufrufen
Du kannst dir ja als Admin bei jeder Seite im VMS unten die Anzahl der Querys ausgeben lassen, und über die Spiele und topframe Dateien mal drüber schaun, ob da jemand allzu verschwenderisch mit DB Anfragen umgeht.
Zusätzlich gibt es ja unabhängig von der Hardware noch Methoden, die MySQL Schnittselle zu limitieren, wobei das je nach Server(software) nicht immer gleich umgesetzt ist, und auf einem Server eigentlich nicht vorinstalliert sein sollte, eher bei Freewebsapce und billig Webspaces.
Kill one man, and you are a murderer.
Kill millions of men, and you are a conqueror.
Kill them all, and you are a god. - Jean Rostand, Thoughts of a Biologist (1939)
Also ich habe den Server jetzt mal 9 stunden laufen lassen ;-) Macht auch bisher nen ganz guten Eindruck ... habe gestern Abend/Nacht noch einige Indizes geändert/gesetzt und es läuft auf jeden Fall schonmal besser. Ich habe schon VIEL weniger Slow-Queries. Die Zahl ist dennoch ziemlich hoch ...
Abfragestatistik: Seit seinem Start wurden 11.868.668 Abfragen an diesen MySQL-Server gesandt.
Insgesamt ø pro Stunde ø pro Minute ø pro Sekunde
12 M 1,23 M 20,47 k 341,12
Also da ist schon einiges los aufm Server
Slow_queries 201 k (nach 9h Laufzeit) ...
Also ich denke ich werde mir diese "Slow-Queries" mal nochmal alle zu Gemüte führen. Wüsste aber nicht so recht wie ich die noch optimieren soll.
Ich poste hier gegen 12 Uhr nochmal ein paar dieser Slow-Queries ...
Habe grade gesehen du bist ja auch bei mir angemeldet jpwfour ;-)
Achja hier nochmal ein paar Daten (ausm Footer) als Beispiel die Seite der Team-Rallye:
103 MySQL Abfragen | SQL: 0,0129 s ...
Das finde ich für 103 Abfragen schon SEHR anständig. Da ich jetzt aktualisiert habe, passiert das auch bei anderen Usern nicht mehr (erst in 1 Minute wieder) ... also ich Cache die Rallye-Übersichten mit 1 Minute Laufzeit ...
Danke nochmal für Eure Hilfen
Jo
edit: hier mal die Dauer der Refübersicht ... wobei ich auch in Game-Ref-Übersicht und normaler Ref-Übersicht unterscheide (dadurch doppelt so viel wie "sonst")
1821 MySQL Abfragen | SQL: 5,6664 s
Finde ich bei ingsgesamt knapp 300 Refs schon ordentlich ... sind ja quasi 6 Abfragen pro Ref ...
Naja da ist ja nun die frage was du da alles mit ausliest und ob es da möglichkeiten gibt wenn du aus mehren tabellesn ausliest da die querys mit left join etc zu machen.
Wenn du magst kannst du dich mal bei mir im ICQ melden ich kann mir mal entsprechende Datein anschauen die viele MySQL Abfragen haben
Ich nutze den Firefox nur um Opera Google Chrome runterzuladen
Moin Hardliner,
naja "das übliche" wird dort ausgelesen. Bzw. ich zeige nicht die UID sondern die Nicknames der Werber/Refs an ... das verbraucht ja auch nochmal mehrachja und ich habe ein COUNT(uid) um anzuzeigen wieviele Refs pro Ebene sind. Dann wird der Ref-Verdienst und der Game-Refverdienst ausgelesen. Da könnte man sicher noch etwas optimieren, wobei die Anzeige des Ref-Umsatzes und die des Game-Refumsatzes in 2 verschiedenen Dateien liegen. Aber die könnte man auch zusammenfassen (bei Bedarf).
Kann dir gerne mal die Abfragen zukommen lassen. Erinnerst dich ja vielleicht noch an ne PN von gestern von "mir" *dumdidum*
Nochmal kurz zu den Slow-Queries. Da stört am meisten (öftesten) folgende beiden Abfragen. Slow sehen die nicht aus, also gehe ich mal davon aus, dass diese wegen fehlernder/suboptimaler Indizes geloggt werden.
# User@Host: web6[web6] @ localhost []
# Query_time: 1 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
UPDATE vms_tages_rang SET ap = ap + 1000 WHERE uid = 309950;
Indizes von vms_tages_rang:
Name | Typ | Kardinalität | Feld
uid | INDEX | 370 | uid
# User@Host: web6[web6] @ localhost []
# Query_time: 0 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
UPDATE vms_king SET `lose` = `lose` + 1000;
Indizes von vms_king:
Name | Typ | Kardinalität | Feld
lose | INDEX | 1 | lose
Beste Grüße
Jo