19.000 Taxonomy Terms und Views

Ich habe da eine Taxonomy mit rund 19.000 Terms. Das sind ca. 300kb Daten. Alles in allem ein Klacks für MySQL. Die Abfragen sind wohl meist Primärschlüssel Joins soweit ich das sehe. Dabei gehe ich von keinem Leistungseinbruch aus.

Drupal legt mir also die Terms an, knallt dazu 19.000 URLs und Hierarchie Einträge in die Datenbank und gut ist. Drupal im Core scheint damit auch wirklich keine Probleme zu haben.

Aber dann verreckt mir Views. max_packets_allowed wurde überschritten. Gut 1MB ist zu wenig für anscheinend 3 MB Daten, aber was macht denn überhaupt einen so irrwitzig großen Eintrag in die DB? Views ist es, da Views die Taxonomy cached.

Also suche ich etwas verzweifelt eine Möglichkeit den Cache von Views aus zu schalten, was nach meinem Stand nicht geht.

Ich habe aber das Modul hier noch nicht ausprobiert, das ist aber wie ich das verstehe nur für die Nodes.
http://drupal.org/node/190269

Also mache ich erstmal das hier.
http://drupal.org/node/218187

Bin ich nicht begeistert davon Views zu hacken, verspricht aber Besserung.

Für eine Taxonomy dieser Größe hilft das aber gar nichts. Views haut immer noch zu viele Daten in die Tabelle.

Ich erhöhe max_packages und der Fehler ist erstmal weg. Drupal ist aber unglaublich langsam! Wenn auf der Seite ein View ist, dann braucht die Seite ca. 60 Sekunden.

Das machte mich etwas verzweifelt. Es scheint ja so zu sein, das Views http://de.php.net/serialize bzw. http://de.php.net/unserialize bei jedem Aufruf nutzt und php dann so richtig am Ackern ist bei den ganzen Terms. Vielleicht ist das aber nicht das Problem sondern Views iteriert die Daten und bringt das in Form für eine Selectbox, die nicht gebraucht wird. Ich weiß es nicht genau.

Allerdings hatte ich den Entwickler von Views über hierarchische Taxonomien schimpfen gehört und habe dann einfach mal ausprobiert die Taxonomy ohne Hierarchie an zu legen.

Das Ergebnis ist erstaunlich. Plötzlich geht alles. Der Blob des View Caches war mit Hierarchie 3MB und ohne nun 1,5MB. Ich denke das ist immer noch sehr viel, aber irgendwie frisst das nicht so viel Leistung.

Ich frage mich nun, was man denn machen soll, wenn man eine riesen Hierarchie anlegen will. In der ersten Ebene waren das irgendwie 8.000 Terms und dann halt die Verknüpfungen.

Ich dachte ich habe damit eher Probleme beim Auswählen und das ich das noch in mehr Ebenen Zerlegen muss, damit das besser funktioniert. 8.000 Terms kann man immer noch schlecht in eine Selectbox packen und die meisten Module für Taxonomy Hierarchien tun genau das. Nun habe ich alle 19.000 linear und alles ist schneller? Gut nun nehme ich nicht Hierarchical Select sondern einfach Autovervollständigung und gut ist. Aber zufrieden macht mich das nicht.

Es ist ja ehrenwert, das Views versucht sich die ganzen Joins für die Hierarchie Abfrage zu sparen und es in einem PHP Array ablegt. Aber irgendwann ist da halt Schluss und was ich einfach nicht verstehe ist, warum Views das überhaupt macht, wenn ich genau weiß, das das Feld zu groß ist und es definitiv nicht in einem Filter nutzen will. Als erstes habe ich die Views durch gesehen, das das Feld ja nirgends verwendet wird und das ist auch so.

Auf Views kann ich nicht verzichten. Die Abfragen zu schreiben ist ja das geringere Problem, aber die Theming Engine und Paging Sache wäre einfach zu aufwendig.

Ich muss noch eine Hierarchie mit ca. 1.000 Terms ins System nehmen und die brauch ich zwingend. Hoffentlich passiert nicht schon ab der Masse was ähnliches.

Und wie das dann mit den 26.000 Nodes wird, die ins System sollen, bin ich mal gespannt drauf. :)