p2p-Kredite

mgutt · Anmeldedatum: 14.12.2010 Beiträge: 1333

Das mit der Transaktionssicherheit verstehe ich nicht. Was meinst Du mit Parallelisieren? Transaktionen kenne ich jetzt nur daher, dass man damit mehrere INSERT/UPDATE Prozesse eines Nutzers in ein Paket schnürt und dieses nur dann ausgeführt wird, wenn wirklich alle ausgeführt wurden. Aber das gibt es ja auch bei MySQL.

Der Datenbankdienst von Wiseclerk drückt in dem Moment auf die Gesamtperformance des Servers. Das ist egal ob die Sachen nun gekapselt laufen. Klar man könnte enge Grenzen setzen. z.B. nur x Prozesse im Pool erlauben, max. Ausführungszeit reduzieren, usw. Aber dann wird die Seite einfach irgendwann mehr Fehlermeldungen auswerfen als alles andere.

Theoretisch könnte man den jeweiligen Tabellentyp einfach auf InnoDB umstellen, so dass Schreiben und Lesen parallel möglich ist. Damit verhindert man in der Regel den Flaschenhals. Aber man sieht ja schon am reinen Öffnen eines Anlegerprofils, dass das Problem wohl bei den SELECTs liegt. Die brauchen einfach zu lange. Entweder weil es zu viele sind oder die einzelnen Abfragen sind nicht optimal, weil sie zu viele JOINS besitzen und/oder Indexe fehlen.

Ich vermute mal Claus nutzt keine DB-Klasse. Sonst könnte man nämlich einfach hingehen und alle Abfragen auswerten und überlange Abfragen in eine Log packen. Alternativ kann aber auch der Server-Techniker die Option Slow Query Logs aktivieren:
http://dev.mysql.com/doc/refman/5.1/de/slow-query-log.html

Ich würde mit allen Abfragen die länger als 3 Sekunden laufen anfangen (alles über ein paar Millisekunden ist eigentlich schon zu langsam). Für die Slow Query Logs gibt es auch diverse Tools, die einem bei der Optimierung helfen.

Gruß
_________________