EDIT: Ich habe den Originalbeitrag falsch gelesen. 168 Module sind eine Menge, und 300 bis 700 ms SQL-Abfragen sind riesig . Je mehr Module Sie verwenden, desto mehr Anfragen werden gestellt, sobald Module welche ausführen.
Verwenden Sie aggressives Caching, solange Sie können. Cachen Sie alles. Wenn es nicht ausreicht, versuchen Sie es mit einem Reverse-Proxy-Cache. Die Verwendung eines CDN für Dateien kann das Ganze erheblich verbessern. Ein Reverse-Proxy-Cache kann Ihnen auch helfen, indem Sie einige Auth-Cookies entfernen, wenn Sie Seiten aufrufen, für die er nicht benötigt wird (dann glaubt Core, der Benutzer sei für diese anonym und maximiert das Caching).
Die Drupal-Kerndynamik verlangsamt die Morgendämmerung, sobald zu viele Module gleichzeitig interagieren.
Wenn Sie beispielsweise viele Module verwenden, die Daten zum Zeitpunkt hook_node_load () laden, anstatt Felder zu verwenden, werden viele Abfragen durchgeführt, während die Feldnutzung die Caching-Effizienz gewährleistet hätte.
Das Rendern kann auch viel Zeit in Anspruch nehmen, drupal_render () (die Rendering-API, die manchmal aufgerufen wird) ist eine nette API (sehr nützlich), aber auch ein bisschen langsam. Das Umschalten auf PDO (D7) und das volle DBTNG (was übrigens großartig ist) erhöhen auch die nicht zu vernachlässigende Latenz.
Das heißt, der Kern an sich ist recht schnell (aber er führt zu viele SQL-Abfragen durch, auch wenn fast nichts installiert ist), schlecht codierte Module sind oft der Engpass.
APC kann die Ausführungszeit je nach ausgeführtem Code auf 2 oder 3 aufteilen. Wenn Sie es gut konfigurieren (aktivieren Sie alle APC-Optimierungen, das offizielle APC-Handbuch ist gut geschrieben und wird Sie führen).
Wenn Sie sich in einer Box mit einem langsamen Dateisystem (Netzwerkdateisystem oder langsame Festplatte) befinden, kann dies einen sichtbaren Einfluss auf die Ausführungszeit haben. Drupal besteht aus vielen kleinen Dateien, wodurch PHP gezwungen ist, jedes Mal, wenn es eine von ihnen lädt, I / O auf dem FS durchzuführen (APC hilft auch sehr dabei).
Ein falsch konfiguriertes DBMS kann auch ein ziemlich hässlicher Engpass sein, wenn Sie mit MySQL überlegen, ob Sie eine Feinabstimmung vornehmen möchten. Wenn Sie ein Shared-Hosting-System verwenden, das nicht Drupal-spezifisch (oder bereit) ist, sind DBMS- und PHP-Stapel wahrscheinlich falsch konfiguriert oder nicht optimiert, was zu sehr langsamen Websites führen kann.
Vergessen Sie nicht, alle Caches zu aktivieren. Wenn Ihre Website nicht benutzerorientiert authentifiziert ist, aktivieren Sie das aggressive Seiten-Caching (es ist wirklich erstaunlich).
Je mehr Blöcke Sie haben, desto langsamer werden die Seiten, und die Blöcke des Views-Moduls stellen einen Engpass dar (abhängig von den von Ihnen verwendeten Views-Plugins kann der Block von OG eine echte Belastung sein), wenn Sie deren Sichtbarkeit nicht einschränken Auf Seitenbasis oder mit benutzerdefiniertem PHP-Code (jeder andere Block kann auch die Blocksichtbarkeit manuell festlegen. Dies hilft dem Framework erheblich, da es nicht versucht, leere Blöcke zu rendern.)
Vermeiden Sie Module, die hook_init () verwenden. Hook_init () wird auf jeder Seite ausgeführt, auch wenn Sie eine 403 oder eine 404 erhalten, die alles verlangsamt (dies verlangsamt sogar die Generierungszeit von | imagecache | style und 404-Fehler in Dateien würden auftreten) Dämmerung langsam, nur um Ihnen zu sagen, dass die Datei nicht existiert).
