Einzelnen Beitrag anzeigen
  #4  
Alt 12.12.2012, 12:33:43
Methos Methos ist offline
Anfänger
 
Registriert seit: Apr 2012
Alter: 47
Beiträge: 3
AW: Performance Problem mit konkurierenden SELECT und UPDATE Anweisungen

So nach dem ich zum einen mit anderen Aufgaben beschäftigt war und zu dem wohl nciht mitbekommen habe, das ich hier eine Antwort bekommen hatte, bin ich wieder bei meinem Performanceproblem angekommen.

Somit auf zur nächsten Runde.

Also, warum das von mir gewählte Konstrukt und nicht eine Tabelle die einfach nur jeden Hit speichert..

Naja ich habe auf der Webseite zahlreiche Anzeigen für die User in denen Inhalte innerhalb ihrer Kategorie nach ihrer Beliebtheit sortiert angezeigt werden.

Ich kann mir eigentlich nciht vorstellen, das es performanter sein soll, für alle Inhalte zu ermitteln wie oft sie ( in einem Zeitraum ) aufgerufen wurden, und dass dann nach Inhalttyp und Kategorie wegzufiltern.

Der Hintergrund ist folgender:

Inhalte können von verschiedenen Typen sein und in verschiedenen Kategorien.

Nehmen wir mal an wir haben TypA und KatB.

Nach deinen Vorschlag müßte ich jetzt erstmal für ALLE Inhalte die Berechnung ausführen, danach sortieren, alle Elemente des TypA raussuchen und danach noch prüfen ob die Elemente in KatB sind. Die 5 beliebtesten geb ich dann aus ...

Da ich davon ausgehe das ich wesentlich mehr SELECTs als UPDATEs habe bin ich einfahc mal davon ausgegangen, das es sinnvoller ist, die Werte bei jedem Update zu aktualisieren, als alle Werte jedesmal zusammenzurechnen.

Der counter Wert ( der halt ALLE jemals erfolgten Aufrufe enthält ) wird z.B. bei JEDEM anzeigen des Inhaltes auf der Webseite ausgegeben und soll sich auch jedesmal ändern wenn ein Aufruf erfolgt ist. Da einmal am Tag ne Tabelle zu erzeugen die quasi einen snapshot des aktuellen Stands darstellt, ist somit auch keine Lösung.
Und bei den Hits die so über die Seite laufen jedes mal alle Einträge zu zählen die zu einer nid gehören macht mir performance technisch schon etwas sorgen.

Was ich aber letztlich zur Zeit nicht verstehe ist, warum ein update auf die Tabelle zur Zeit zwischen 200ms und 700ms dauert. Er soll doch nur die 3 Werte um eins erhöhen und schreiben, und die entsprechenden Indizes aktualisierten.

Wenns keine innodb tabelle wäre würd ich ja annehmen, das er die Tabelle nicht gelockt bekommt, aber da er bei inno nur eine Zeile sperren muss, wundert mich das doch reichlich.

Hat vll noch jemand eine Idee, einen Vorschlag, oder evtl. einen Link mit Infos die zu diesem Problem passen?
Mit Zitat antworten