[maxhb]

Hi!
Beim Anschauen der Typo3-Tabellen ist mir aufgefallen, dass dort Indizes sehr serh sparsam eingesetzt werden.
Wenn man mal darüber nachdenkt, dann gibt es aber diverse Spalten, die sich als Index nahezu anbieten. Dies sind insbesondere die Spalten "hidden", "deleted" und "sorting".

Ich hab' mal einen kleinen Versuch gestartet und meine Typo3-Db folgendermaßen modifiziert:

ALTER TABLE `cache_hash` ADD INDEX ( `hash` ( 4 ) ) ;
 
ALTER TABLE `pages` ADD INDEX ( `deleted` ( 1 ) ) ;
ALTER TABLE `pages` ADD INDEX ( `hidden` ( 1 ) ) ;
ALTER TABLE `pages` ADD INDEX ( `doktype` );
ALTER TABLE `pages` ADD INDEX ( `sorting` );
 
ALTER TABLE `tt_content` ADD INDEX ( `deleted` ( 1 ) ) ;
ALTER TABLE `tt_content` ADD INDEX ( `hidden` ( 1 ) ) ;
 
ALTER TABLE `sys_template` ADD INDEX ( `deleted` ( 1 ) ) ;
ALTER TABLE `sys_template` ADD INDEX ( `hidden` ( 1 ) ) ;
ALTER TABLE `sys_template` ADD INDEX ( `sorting` );

Mit diesen SQL-Kommandos werden eine Reihe von zusätzlichen Indizes angelegt (Keine Angst, der Vorgang kann problemlos wieder Rückgängig gemacht werden!).

Wie man sieht sind das noch längst nicht alle Tabellen, sondern nur die, die mir so auf Anhieb als besonders wichtig aufgefallen sind.

Nimmt man jetzt mal nur die reine Zeit, die DB-Anfragen zur Anzeige einer Seite benötigen, dann ergeben obige Anpassungen bei mir einen Speedup um den Faktor 300.
Konkret ist die mittlere Zeit für DB-Anfragen von 0,122s auf 0,0004s gesunden.

Das ist zwar in absoluter Zeit nicht die Welt, aber der Faktor 300 steht erstmal als grobe Abschätzung im Raum.

Mir ist klar, dass die Zeit, die DB-Anfragen benötigen nur ein Teil der CPU-Leistung sind, die Typo3 benötigt, aber wenn man solche Zugewinne geschenkt bekommt...

Die Messung der DB-Zugriffszeiten habe ich übrigens durch anpassen der Datei t3lib/class.t3lib_db.php vorgenommen und mr dort ein Logfile erstellen lassen. Habe dort die Methode exec_SELECTquery aufgebohrt:

    function exec_SELECTquery($select_fields,$from_table,$where_clause,$groupBy='',$orderBy='',$limit='')    {
        // Start
        static $total_time = 0;
        $logfile = '/tmp/max/typo3.log';
 
        if($total_time == 0) {
            $message = str_repeat('-',80) . "\n";
        } else {
            $message = '';
        }
        $message .= str_replace("\n"," ",$this->SELECTquery($select_fields,$from_table,$where_clause,$groupBy,$orderBy,$limit));
        $message = preg_replace("/(\s+)/"," ",$message);
        if(!function_exists('getmicrotime')) {
            function getmicrotime() {
            list($usec, $sec) = explode(" ",microtime()); 
            return ((float)$usec + (float)$sec); 
            }
        }
 
        $start = getmicrotime();
        // Ende
 
        $res = mysql_query($this->SELECTquery($select_fields,$from_table,$where_clause,$groupBy,$orderBy,$limit), $this->link);
        if ($this->debugOutput)    $this->debug('exec_SELECTquery');
 
        // Start
        $ende = getmicrotime();
 
        $time = $ende - $start;
        $total_time += $time;
 
        $message = $time . " (" . $total_time . ")\n" . $message . "\n";
        error_log($message,3,$logfile);
        // Ende
        return $res;
    }

Vielleicht mag ja mal jemand einen ähnlichen Versuch starten und seine Ergebnisse hier posten.

Ganz allgemein frage ich mich, ob die Tatsache, dass Typo3 so wenige Indizes verwendet Absicht ist oder ob sich noch niemand die Mühe gemacht hat, das DB-Modell mal genauer anzuschauen.

cu
maxhb

[tom]

das hört sich ja super an - werde ich mir mal anschauen.

Post doch mal in der dev-Gruppe und frage da nach.

Ich weiss nicht, ob das ein Problem mit Backwards-Kombabilität ist und TYPO3 versucht auch alte MySQL-Versionen zu bedienen ?

Tom

[maxhb]

Zitat von tom

Post doch mal in der dev-Gruppe und frage da nach.

Ist sicherlich auch einen Versuch Wert, bisher habe ich den beitrag aber nochmals als Crossposting unter http://www.typo-3.de/forum/list/list_post//40125/ veröffentlicht, mal schauen, ob da jemand ein paar Gedanken zum Thema äußert.

CU
maxhb

[maxhb]

Zitat von tom

Post doch mal in der dev-Gruppe und frage da nach.

Danke für die Idee, habe ich mittlerweile getan und auch schon ein paar weitere Ideen gewonnen

CU
maxhb

[maxhb]

Hi!
Unter http://wiki.typo3.org/index.php/Database_optimization habe ich mal eine Wiki-Seite angelegt, damit man Ideen sammeln kann.

CU
maxhb

[chaosgenie]

Hallo,

sehr interessant. Wir betreiben hier einen Webserver mit mehreren TYPO3-Installationen und gelegentlich hängt sich mal eine Datenbank weg.

Dann hilft nur noch ein Restart des MySQL-Servers.

Werde mal ein paar Settings ausprobieren.
Für mich stellt sich immer noch die Frage, wann ein vernünftiges Limit von Seiten auf einem Server erreicht ist. Aber das ist ja nicht nur von der Anzahl der gehosteten Seiten abhängig, sondern auch von der Anzahl der PIs.

So, back on test - CG

[pulponair]

Hmmm, was soll n index auf nem boolschen Feld bringen (hidden, deleted)?
Wenn dann eher l18n_parent und sys_language_uid. Sorting ist in neueren Versionen schon Teil des parent index.

Im uebrigen ist die Messung auch nicht besondere aussagekraeft, da Du den Querycache und aehnliches voellig ausser Acht laesst.

Bye,
Nikolas

[maxhb]

Hi!
Eines vorweg: Die Optimierung der MySQL-DB-Struktur hat sich im Prinzip erledigt, da es offenbar Wunsch und Wille des Core-Teams ist das TYPO3-Projekt unabhändig von einer bestimmten DB zu betreiben.

Zitat von pulponair

Hmmm, was soll n index auf nem boolschen Feld bringen (hidden, deleted)?

Was spricht gegen Indizes auf boolschen Feldern?! Die sind doch z.B. viel effektiver als ein Index auf einem Timestamp-Feld, das eine Kardinalität von zig-tausend besitzt...

Zitat von pulponair

Im uebrigen ist die Messung auch nicht besondere aussagekraeft, da Du den Querycache und aehnliches voellig ausser Acht laesst.

Bei aktiviertem Query-Cache kann man jegliche Optimierung der Indizes de facto vergessen, wenn man den benutzten Speicher nur groß genug dimensioniert. Letzten Endes landet dann irgendwann alles im Cache

Indizes nutzen in diesem Zusammenhang eigentlich nur dann etwas, wenn eine Reihe von Bedingungen erfüllt sind:

• Es gibt SQL-Anfragen, die nicht im Cache vorliegen (sprich der query-Cache ist nicht monstergroß)
• Die im Index erfassten Felder haben tatsächlich verschiedene Werte (Gibt es z.B. keine gelöschten Seiten, dann bringt ein Index auf deleted in der pages Tabelle nix)
• Es muss hinreichend viele Tabelleneinträge geben, damit eine Suche über Indizes überhaupt relevante / messbare Ergebnisse liefert (bei 10 Einträgen in der pages Tabelle wird man kaum Unterschiede Messen)
• Die Tabellen werden überwiegend lesend verwendet, da das Anlegen und Verwalten von index-Informationen beim Speichern immer ein wenig zeitlichen Extra-Aufwand bedeutet
• Die durch einen Index ermittelte Teilmenge einer Tabelle überschreitet nicht einen bestimmten Schwellwert (ich meine 50%), da ansonsten eh die ganze tabelle eingelesen wird.

Abgesehen davon kann man die mittlere Zugriffsgeschwindigkeit auch noch durch den richtigen Einsatz von passende MySQL-Tabellentypen optimieren.

Fazit Alles in Allem ein spannedes Thema, aber das TYPO3 Projekt scheint leider nicht der richtige "Testballon" zu sein. bei etlichen anderen Projekten (z.B. Datawarehouse auf MySQL-Basis) konnte ich aber schon einige Performanzvorteile erreichen.

CU
maxhb