it-swarm.com.de

Was alles trägt zur Ausführungszeit der Seite bei drupal?)?

Ich habe eine Site, die ich untersuche und die große Leistungsprobleme aufweist. Mit memcache konnte ich die Anzahl der Abfragen sowohl in Bezug auf die Anzahl als auch auf die Gesamtausführungszeit (von 3 Sekunden auf 230 ms) verringern, aber die Ausführungszeit der Seite entgeht mir (ich bin es) Wenn ich mir die von devel ausgegebenen Werte ansehe, ist mein Verständnis, dass die Seitenausführungszeit = Zeit, die für die Ausführung von PHP benötigt wird, daher habe ich APC installiert und ich kann sehen, dass PHP-Opcode zwischengespeichert wird und Statistiken Treffer in der APC-Systemsteuerung anzeigen (apc.php wird mit APC geliefert), aber Die Ausführungszeit meiner Seite sinkt nicht. Ich denke, meine Frage ist zweifach:

  • Was alles trägt zur (besseren Verlangsamung) Seitenausführungszeit bei? Ist es nur Zeit, um PHP auszuführen?
  • Welche Ansätze sollte ich wählen, um die Ausführungszeit der Seite zu verkürzen? Ich habe APC ausprobiert, aber nicht viel geholfen

Die Anzahl der auf dieser Site verwendeten Module ist einfach enorm (168), aber im Moment bin ich nicht in der Lage, diese Empfehlung abzugeben, es ist eher wie ein Feuer in der Lochsituation.

Edit : Ausgabe von xhprof auf lokaler Instanz (empfohlen von mikeytown), das scheint verrückt zu sein Ich denke, die späteren Ergebnisse sind auf Thrashing zurückzuführen? Diff-Läufe für dieselbe URL haben drastische Unterschiede und sind einfach zu viel Ressourcen verbraucht. Auch nicht sicher, warum es Werte anzeigt, die nicht von heute sind: | (Ich habe gerade xhprof auf diesem Laptop installiert)

Output of running xhprof on local instance

16
Dipen

Holen Sie sich einen Cachegrind Ihrer Website. xdebug oder xhprof kann einen generieren. Hier erfahren Sie, welche Funktionen am längsten ausgeführt werden. Bis Sie dies tun, ist es ein schlechtes Ratespiel.

4
mikeytown2

EDIT: Ich habe den ursprünglichen Beitrag falsch gelesen. 168 Module sind eine Menge, und 300 bis 700 ms SQL-Abfragen sind riesig. Je mehr Module Sie verwenden, desto mehr Abfragen werden gestellt, sobald Module einige ausführen.

Verwenden Sie aggressives Caching, solange Sie können. Zwischenspeichern Sie alles. Wenn dies 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 Authentifizierungs-Cookies entfernen, wenn Sie auf Seiten zugreifen, die ihn nicht benötigen (dann wird der Kern glauben, dass der Benutzer für diese anonym ist, und das Caching maximieren).


Die Kerndynamik Drupal) verlangsamt die gesamte Morgendämmerung, sobald zu viele Module gleichzeitig interagieren.

Ich würde zum Beispiel sagen, wenn Sie viele Module verwenden, die Daten zur Zeit von hook_node_load () laden, anstatt Felder zu verwenden, werden viele Abfragen durchgeführt, während die Feldverwendung die Effizienz des Cachings sichergestellt hätte.

Das Rendern kann auch viel Zeit in Anspruch nehmen. Drupal_render () (die Rendering-API wird manchmal aufgerufen) ist eine nette API (wirklich nützlich), aber auch etwas langsam. Das Umschalten auf PDO (D7) und das vollständige DBTNG (was übrigens großartig ist) erhöht auch die nicht zu vernachlässigende Latenz.

Das heißt, der Kern selbst ist ziemlich schnell (aber er führt zu viele SQL-Abfragen aus, selbst 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 teilen. Wenn Sie es gut konfigurieren (aktivieren Sie alle APC-Optimierungen, das offizielle APC-Handbuch ist gut geschrieben und führt Sie).

Wenn Sie sich auf einer Box mit einem langsamen Dateisystem (Netzwerkdateisystem oder langsame Festplatte) befinden, kann dies einen sichtbaren Einfluss auf die Ausführungszeit haben. Drupal besteht aus viel kleinen Dateien, wodurch PHP gezwungen wird, E/A auf dem FS jedes Mal, wenn einer von ihnen geladen wird (APC hilft auch sehr dabei).

Ein falsch konfiguriertes DBMS kann auch ein ziemlich hässlicher Engpass sein, wenn Sie MySQL verwenden und über eine Feinabstimmung nachdenken. Wenn Sie sich auf einem gemeinsam genutzten Hosting befinden, ist es nicht Drupal spezifisches (oder bereit) DBMS und PHP Stack) wahrscheinlich falsch konfiguriert oder nicht optimiert, was möglich ist führen zu sehr langsamen Websites.

Vergessen Sie nicht, alle Caches zu aktivieren. Wenn Ihre Site 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. Die Modulblöcke von Views sind ein Engpass im Morgengrauen (abhängig von den von Ihnen verwendeten Views-Plugins kann der Block von OG ein echtes Problem sein), wenn Sie deren Sichtbarkeit nicht einschränken auf Seitenbasis oder mit benutzerdefiniertem PHP Code) (jeder andere Block, der Ihre Blocksichtbarkeit immer manuell einstellt, hilft dem Framework erheblich, indem er vermeidet, dass er versucht, leere Blöcke zu rendern).

Vermeiden Sie Module, die hook_init () verwenden. Hook_init () wird auf jeder Seite ausgeführt, selbst wenn Sie eine 403 oder eine 404 erhalten, die alles verlangsamt (dies verlangsamt sogar die Generierungszeit für den Imagecache | -Stil und 404-Fehler bei Dateien Morgengrauen langsam, nur um Ihnen mitzuteilen, dass die Datei nicht existiert).

1
Pierre