Drupal ist nicht gerade sparsam, wenn es an die Anzahl von Queries geht. Hier eine kleine Auflistung, wo es "Query-Schleudern" gibt.

• Mobile Tools: Eigentlich ein praktisches Tool, aber es hat noch ein paar Problemchen. Wenn man viele Rollen hat, dann werden eine Unmenge an Queries generiert. Ich habe da je nach Seite zwischen 80 und 200 Queries gezählt.
• Node Relationen: Das ist etwas super praktisches. Man kann alle möglichen Sachen damit abbilden, doch wie sieht es mit der Performance aus. Als ganz simples Beispiel: Einen Artikelnode und ein Bildnode. Beides wird über eine Noderelation verbunden. Um den Artikel darzustellen, muss zuerst node_load für den Artikel aufgerufen werden und dann entsprechend noch node_load für das Bild. Wenn jetzt auf einer Seite 10 Artikel sind, dann summiert sich das ziemlich schnell auf.
Es ist zwar extrem praktisch node_load zu verwenden, aber man sollte dabei die Performance im Hinterkopf halten.
• Übersetzungen: Übersetzungen über die T Funktion t(), werden hauptsächlich im Backend verwendet. Jede t() Funktion bedeutet eine DB Anfrage. Auch das kann sich aufsummieren.
• Links: Links welche über die l() Funktion gebaut werden, verlangen ebenfalls eine DB Abfrage, da geschaut wird, ob es einen Alias gibt. Dabei handelt es sich um eine ganz einfache Select Abfrage, aber es ist nicht die Komplexität, sondern die Masse. In einem Link Block finden sich schnell mal 30 Links, was bedeutet, dass 30 Abfragen gemacht werden müssen.
• XML Sitemap: Entpuppte sich als wahrer Bremsklotz. Noch ist mir nicht ganz klar, was hier genau die Ursache ist, da ich noch nicht dazu gekommen bin, das Modul genauer zu untersuchen. Die XML Sitemap generiert ein XML, welches eigentlich alle Links der Seite enthält und schickt dieses XML an Suchmaschinen, damit der Inhalt optimal indexiert wird.
Aus irgend einem Grund führte die Generierung dieses XMLs zu extremer CPU und Datenbanklast (Spitzen von 3000 Queries pro Sekunde), bis der Server ein Timeout gab.

Viele dieser Abfragen lassen sich durch Einsetzen eines Caches abfangen. Cache ist King! Nehmen wir zum Beispiel einen nochmals unseren Links Block mit den wichtigstens Links im Footer (wie z.B. auf der Skype Seite). Dieser Block ist auf jeder Seite identisch. Ohne Blockcache wird jedoch für jeden Link eine Datenbankabfrage nötig sein, was völlig unnötig ist. Blockcache einschalten und sicherstellen, dass der Cache für diesen Block auf "global" gestellt ist, will heissen, dass der erste User, der eine Seite aufruft, den Block generieren muss und jeder folgende dann einfach die fertige Version aus dem Cache bekommt, bis zum nächsten Mal, wenn der Cache wieder frisch aufgebaut wird (defaultmässig ist das beim Speichern eines Nodes).