Hallo,
ich will einen Satz von Queries mehrmals parallel auf eine DB loslassen. Dabei soll die Zeit gemessen werden, bis der letzte Prozess den letzten Query abgearbeitet hat. Leztendlich hängt davon die Entscheidung InnoDB oder MyISAM ab. Ich weiss, dass ich damit nicht wirklich parallele Abfragen erzeuge, aber wie soll man es denn sonst rausbekommen?
Mir schwebt was vor mit 'use Benchmark' vor, alledings weiss ich nicht, wie ich einzelne Kind-Prozesse damit messen kann. Führt ihr mich auf den richtigen Weg?
Mit freundlichen Grüßen
Jens Puruckherr
Am Wed den 01 Oct 2003 um 03:14:59PM +0200 schrieb Jens Puruckherr:
Hallo,
ich will einen Satz von Queries mehrmals parallel auf eine DB loslassen. Dabei soll die Zeit gemessen werden, bis der letzte Prozess den letzten Query abgearbeitet hat. Leztendlich hängt davon die Entscheidung InnoDB oder MyISAM ab. Ich weiss, dass ich damit nicht wirklich parallele Abfragen erzeuge, aber wie soll man es denn sonst rausbekommen?
Als fast hack kann man ja die Kommandozeilentools nutzen, die können sicherlich auch sql aus Dateien lesen. Parallelität bekommt man durch mehrfaches Starten und Zeit messen kann time. Ist allerdings durch die Ladezeiten und den Verbindungsaufbau zur DB nicht frei von Fehlern. Eventuell kann man diese Effekte einzeln untersuchen und dann "herausrechnen". Falls die Performance auch von den Perl Datenbank Modulen beeinflußt wird, wäre dies natürlich der falsche Weg.
andre
Andre Schulze as8@rcs.urz.tu-dresden.de wrote:
Am Wed den 01 Oct 2003 um 03:14:59PM +0200 schrieb Jens Puruckherr:
Hallo,
ich will einen Satz von Queries mehrmals parallel auf eine DB loslassen. Dabei soll die Zeit gemessen werden, bis der letzte Prozess den letzten Query abgearbeitet hat. Leztendlich hängt davon die Entscheidung InnoDB oder MyISAM ab. Ich weiss, dass ich damit nicht wirklich parallele Abfragen erzeuge, aber wie soll man es denn sonst rausbekommen?
Als fast hack kann man ja die Kommandozeilentools nutzen, die können sicherlich auch sql aus Dateien lesen. Parallelität bekommt man durch mehrfaches Starten und Zeit messen kann time. Ist allerdings durch die Ladezeiten und den Verbindungsaufbau zur DB nicht frei von Fehlern. Eventuell kann man diese Effekte einzeln untersuchen und dann "herausrechnen".
Den Overhead beim Starten der Anfragewerkzeuge hast du im praktischen Betrieb ja auch. Weiterhin: Du musst ihn gar nicht herausrechnen, weil er ja bei beiden Testläufen gleich ist, wenn man beide Tabellen mit den selben SQL-Queries füttert.
Liegen die Laufzeitunterschiede zwischen den beiden Typen bei dir im Sekundenbereich? Brauchst du sie genau? Bei Anfragen, für die die DB-Maschine Minuten braucht sollte der Overhead deiner Anfragemethoden nahezu egal sein.
mfg, Fabian
lug-dd@schlittermann.de writes:
Liegen die Laufzeitunterschiede zwischen den beiden Typen bei dir im Sekundenbereich? Brauchst du sie genau? Bei Anfragen, für die die DB-Maschine Minuten braucht sollte der Overhead deiner Anfragemethoden nahezu egal sein.
Ich habe es jetzt erst mal so gemacht:
4 Shells öffnen und ganz fix hinternander den mysql-client im Batchbetrieb mit den Anfragen füttern. Zum Schluss den Mittelwert aus 4 * time nehmen und hoffen, das das so halbwegs aussagekräftig ist. Es geht nicht um genaue Zeiten oder Abweichungen von paar Sekunden. Aber das momentane Verhältnis von MyIsam zu InnoDB von 0,6 spricht nicht gerade für InnoDB .... Tja, Transaktionen muss man sich hat teuer erkaufen. Allerdings liegt hier der Punkt, denn für einen OnlineShop sollte die DB schon flott sein ......
Mit freundlichen Grüßen
Jens Puruckherr
hallo jens,
nicht gerade für InnoDB .... Tja, Transaktionen muss man sich hat teuer erkaufen.
das problem mit der 'nicht-richtigen' datenbank habe ich bei mysql auch und schon mehrfach den gedanken gehabt statdessen postgresql zu verwenden, kannst du zur probe mal die tests mit postgresql starten? (ich nehme jedoch an das es dabei deutlich schlechter weg-kommt)
hast du vieleicht irgendwelche erfahrungen 'größerer' internet-angebote die psql verwenden?
aufjedenfall hat psql deutliche vorteile der datenkonsistenz und sql-kompatibilität gegenüber mysql...
gruss thomas
Am Thu den 02 Oct 2003 um 08:45:06AM +0200 schrieb Thomas Baum:
hallo jens,
nicht gerade für InnoDB .... Tja, Transaktionen muss man sich hat teuer erkaufen.
Nur mal so aus allgemeinem Interesse: wie feingranular ist denn eigentlich der Locking Mechanismus bei Transaktionen in mysql? Postgres nutzt sowas wie "multiversion concurrency control", was ohne oder zumindest weniger locks auskommen soll. Nur zur Serialisierung von schreibenden Zugriffen werden Sperren benutzt, die lesende Zugriffe nicht beeinflussen. Sperren sind auf die manipulierten Datensätze beschränkt, im Gegensatz zu anderen Implementierungen, die ganze Tabellen oder sogar Indizes sperren (sowas haben wir in der Uni *brech*).
Aus diesen Gründen habe ich auch noch nie Probleme mit Deadlocks gehabt, obwohl die Anwendung durchaus konkurrierend auf die Datenbank zugreift.
das problem mit der 'nicht-richtigen' datenbank habe ich bei mysql auch und schon mehrfach den gedanken gehabt statdessen postgresql zu verwenden, kannst du zur probe mal die tests mit postgresql starten?
Würde mich auch interessieren, kann mir jedoch nicht vorstellen, daß andere Datenbanken funktionell so toll wie PostgreSQL sind.
Tschau,
andre
Hallo,
lug-dd@schlittermann.de writes:
nicht gerade für InnoDB .... Tja, Transaktionen muss man sich hat teuer erkaufen.
das problem mit der 'nicht-richtigen' datenbank habe ich bei mysql auch und schon mehrfach den gedanken gehabt statdessen postgresql zu verwenden, kannst du zur probe mal die tests mit postgresql starten? (ich nehme jedoch an das es dabei deutlich schlechter weg-kommt)
hmm, da muss ich erst mal den ganzen Shop in pgsql anlegen.
hast du vieleicht irgendwelche erfahrungen 'größerer' internet-angebote die psql verwenden?
Nö.
aufjedenfall hat psql deutliche vorteile der datenkonsistenz und sql-kompatibilität gegenüber mysql...
Ja, aber kein Schwein wird unsere Datenbank wechseln wollen.
Hier noch das Ergebniss meiner Tests: Es handelt sich um echte Queries auf einen echten Datenbestand, also keine syntetischen Tests. InnoDB ist beim Lesen 25% langsamer als MyIsam. Egal ob 1, 4 oder 8 "parallel" laufende Prozesse. Das macht dem Chef natürlich Angst, obwohl ich nicht glaube, das in der Praxis sich das so gravierend auswirkt. Naja, InnoDB ist erst mal gekippt. Hoffen wir auf saubere Daten um wenig Müll zu produzieren ....
Mit freundlichen Grüßen
Jens Puruckherr
lug-dd@mailman.schlittermann.de
-
Andre Schulze -
Fabian Hänsel -
Jens Puruckherr -
Thomas Baum