Geschwindigkeit

[Sven Rautenberg]

Moin!

ich würd gern grundsätzlich über eine MySQL Datenbank erlernen, wie sich Geschwindigkeiten einschätzen lassen.

Kannst du den Satz vielleicht noch mal anders formulieren? Er ist nämlich ziemlich mehrdeutig, und selbst wenn man den im Kontext wahrscheinlichsten Sinn nimmt, keinesfalls verständlich.

Ich überlege derzeit, ob es schneller wäre, aus verschiedenen Tabellen bei einem Seitenaufruf immer Daten zusammenzutragen oder aus einer Datei lesen zu lassen, die den Wert bei Bedarf per Dateifunktionen angegeben bekommt.

"If you can't measure it - don't optimize it".

Oder anders gesagt: Beides programmieren, beides vom Zeitaufwand her ausmessen und das schnellere dann nehmen. Wobei die möglichen Begleitumstände natürlich bei der Messung zu berücksichtigen sind. Es dürfte also kaum ausreichend sein, exakt EINEN Zugriff je Methode zu messen, sondern es müssen selbstverständlich MEHRERE PARALLELE Zugriffe auch in der Messung berücksichtigt werden, denn Besucher greifen ja auch parallel zu.

Kennt jemand einen guten Artikel zu Datenbankgeschwindigkeit (mysql)?

Was soll denn in einem Artikel zu Datenbankgeschwindigkeit drinstehen?

Entweder gibt es Artikel, die ein gegebenes Setup, also eine definierte größere Datenbank, mit unterschiedlichen Datenbanken (mysql, pgsql, Oracle, DB2,...) einspielen und diversen "praxisnahen" Abfragen unterwerfen - und davon jeweils die Zeit messen und am Ende einen "schnellste Datenbank ist"-Sieger küren.

Dann gibts Artikel, die konkret bei einer gegebenen Datenbank alle möglichen Optimierungsmöglichkeiten durchkauen, also beispielsweise die Cachegröße im RAM, irgendwelche internen Block-Größen, vielleicht auch die Abhängigkeit vom Dateisystem oder von der zugrundeliegenden Festplatten_Architektur (SCSI vs. IDE, Single Drive vs. RAID 0 vs. RAID 1 vs. RAID 5).

Aber keiner dieser Artikel bespricht, ob und in welcher Form es überhaupt sinnvoll ist, eine Datenbank einzusetzen oder stattdessen vielleicht lieber nur mit Dateien zu arbeiten - oder welche Optimierungsmöglichkeiten bestehen können, tatsächlich als zu langsam empfundene Datenbankzugriffe durch schnellere Methoden wie z.B. Caching zu ersetzen.

Das Problem ist: Solche Optimierungen erfordern zunächst mal ein konkretes Problem auf einem existierenden System. Denn nur wenn tatsächlich ein realer Anwendungsfall mit seinen individuellen Ausprägungen existiert, kann man nach einem Optimierungsversuch ja tatsächlich sehen, ob eine Verbesserung eingetreten ist, oder nicht.

Außerdem gibt es so dermaßen viele individuelle Möglichkeiten einer Datenbankabfrage und damit zusammenhängender Möglichkeiten, dass es kaum in einem Artikel eine einzige goldene Lösung geben kann.

Um nur mal zwei Beispiele zu nennen:
1. Es ist sicherlich absolut nicht sinnvoll, die Suchergebnisseiten von Google in irgendeinen Cache zu schreiben, um beim nächsten Mal schnelleren Zugriff darauf zu kriegen.

2. Andererseits ist es vermutlich ziemlich sinnvoll, anstelle einer immer wieder dynamisch zusammengestellten Website, auf der sich die Inhalte einer Seite aber maximal einmal im Monat verändern, diese Website einmal als statisches HTML zu generieren und dann darauf zuzugreifen. ABER: Würdest du diese Generierung auch dann noch einbauen wollen, wenn diese statische Website aus einer Millionen Dokumenten besteht, die Generierung einer einzigen Seite eine Sekunde benötigt, und es für den Betrieb der Website zwingend erforderlich ist, dass die eine monatliche Änderung zeitlich exakt und sehr zeitnah veröffentlicht wird?

Du siehst also: Deine bisherige Fragestellung ist so dünn und allgemein gestellt - dass du da keine Artikel finden wirst, selbst wenn du suchen würdest, ist mir schon klar.

- Sven Rautenberg