wildlife

XDebug – Installation und suche nach Performanceproblemen auf Webservern

// December 27th, 2009 // Blog / Website, IT, Tutorials

Um den Performanceproblemen auf den Grund zu kommen, hat mir Uli Xdebug empfohlen. Xdebug ist ein Debugger und Profiler Tool für PHP:

The Xdebug extension helps you debugging your script by providing a lot of valuable debug information. The debug information that Xdebug can provide includes the following:

  • stack traces and function traces in error messages with:
    • full parameter display for user defined functions
    • function name, file name and line indications
    • support for member functions
  • memory allocation
  • protection for infinite recursions

Da Zypper, mit den Repositories von meinem Strato vServer, Xdebug leider nicht kannte, musste ich es manuell installieren. Dazu habe ich mir das aktuelle Paket in der Version 2.0.5 per wget geladen und entpackt:

wget http://xdebug.org/files/xdebug-2.0.5.tgz
tar xfvz xdebug-2.0.5.tgz

Da für die Ausführung phpize notwendig ist und mir das Paket autoconf fehlte, habe ich diese nachinstalliert (auf autoconf wird man nicht explizit hingewiesen, aber Google weiß ja alles):

zypper install php5-devel
zypper install autoconf

Anschließend führt man phpize aus, kompiliert die Sources und kopiert die Binary an einen Ort, den man gut wiederfindet:

phpize
./configure --enable-xdebug
make
cp modules/xdebug.so /to/wherever/you/want/it

Um das Modul für PHP zu aktivieren, gibt man die xdebug-Binary in der php.ini (bei mir /etc/php5/apache2/php.ini) an und startet den Webserver neu:

zend_extension="/wherever/you/put/it/xdebug.so"
/etc/init.d/apache2 restart

Anschließend kann man eine phpinfo-Datei auf dem Webserver erstellen um zu prüfen, ob das Modul erfolgreich eingebunden wurde.

xdebug integration on phpinfoIn der php.ini ergänzt man den o.g. Eintrag um die folgenden Einstellungen

xdebug.profiler_enable="0"
xdebug.profiler_output_dir="/tmp/xdebug"
xdebug.profiler_output_name="cachegrind.out.%u.%p"
xdebug.profiler_enable_trigger="1"

Ich empfehle enable auf 0 zu belassen und enable_trigger auf 1, so dass die Logs nur generiert werden, wenn die Webseite über "http://url-des-webhosts/?XDEBUG_PROFILE" aufgerufen wird. Dies verhindert, dass der Festplattenspeicher vollläuft, was wirklich schnell passieren kann. Als nächstes sollte noch das Verzeichnis erstellt werden (sofern nicht bereits vorhanden), welches wir unter output_dir angegeben haben:

mkdir -p /tmp/xdebug
chmod 1777 /tmp/xdebug/

Zur Auswertung stehen einem unter Windows WinCacheGrind oder unter Linux KCacheGrind zur Verfügung:

WinCacheGrind

Auf Feldstudie.net lagen die Probleme hauptsächlich bei den Plugins Global Translator, Similar Posts, WP-Syntax und WP-Ads. Ich habe diese nun entfernt. Außerdem habe ich das Javascript bzw. die Tab-Funktionalität aus der Sidebar entfernt und die letzten Kommentare über das Standardwidget eingebunden.

Zusammen mit der Reaktivierung der Compression (Deflate, GZip) konnte ich die Antwortzeit des Webservers von ca. 6-9 Sekunden auf 2-3 Sekunden senken. Ich denke, damit kann man getrost leben. :)

Dank geht wiedermal an Uli, der mir Xdebug empfohlen hat.

Ähnliche Beiträge:


14 Responses to “XDebug – Installation und suche nach Performanceproblemen auf Webservern”

  1. Uli says:
    27. December 2009 at 14:00

    Keine Ursache, bin nur über Global Translator etwas bestürzt...

    Viele Grüße,
    Uli

    Reply
  2. Frank says:
    27. December 2009 at 18:59

    Du solltest unbedingt Plugins meiden, die viele filtern bzw. via Filter auf content von WP zugreifen, das ist extreme Last für WP; z.B. eben WP Syntax. Ebenso machen diese Plugins sehr abhängig, man kann das Blog nur schwer ohne sie laufen lassen.
    Zum Analysieren kann ich noch Webgrind empfehlen, eine Webplattform.

    Reply
    • Torsten says:
      27. December 2009 at 19:04

      Danke für den Tipp. Ja, das mit den Plugins musste ich über die Zeit auch feststellen. Habe sämtliche "pre lang"-Tags jetzt in normale pre-Tags umgewandelt und einfach die Formatierung direkt im CSS vorgenommen. Habe ich zwar kein Geshi, aber darüber komm ich auch noch hinweg. ;)
      Bis ich die nächste Google Auszahlung erreicht habe, werde ich die Werbung statisch im Template einbauen. Damit habe ich dann auch WP-Ads gespart. Nach der nächsten Auszahlung werde ich wahrscheinlich sowieso auf Google, etc. verzichten. Bleibt noch Analytics, aber das werde ich mir vermutlich nicht nehmen lassen. xD

      Reply
      • Uli says:
        27. December 2009 at 19:07

        Naja Analytics kommt statisch ins Template und dann isses ja eh nur nen Javascript-Call...die gs.js kann man noch lokal hosten (regelmäßig updaten nicht vergessen!) und dann hat man da eh keinen stress mit externen ladezeiten und zusätzlichen DNS-Aufrufen ;)

        Reply
        • Torsten says:
          27. December 2009 at 19:18

          Stimmt... die .js kann ich noch lokal vorhalten. Das könnte ich morgen noch machen. Ansonsten werde ich auch evtl. noch die diversen CSS-Dateien zusammenfassen. Oder bringt das nicht so viel?
          Was bedeutet es eigentlich, wenn .js oder css-Dateien mit Versionsnummer als Parameter übergeben werden? Beispiel:
          .../wp-includes/js/jquery/jquery.js?ver=1.3.2
          .../wp-includes/js/jquery/jquery.form.js?ver=2.02m

        • Uli says:
          27. December 2009 at 19:52

          DIe Versionsnummern bedeuten vor allem, dass der Browser bei einer neuen Version sich auf jeden Fall auch das neue Skript runterzieht. Nur muss man auch sagen, dass man das eh nicht so häufig tauscht.
          Die CSS-Files zusammenzufassne bringt sogar recht viel, denn jedes weitere Skript benötigt eine Verbindungssteuerung und erhöht damit die Download-Zeit deiner Seite.

          Ehrlich gesagt würde ich dir raten mal das Firefox-PluginGoogle Page Speed laufen zu lassen, das sagt dir sehr genau, wo es hakt ;) Beispielsweise kannst du dein CSS mal minifien lassen (macht auch das Plugin). Bringt zwar nur 5,6kb, aber immerhin ;) Gleiches mit JS, bringt auch nochmal knapp 16kb. Kombinieren der CSS-Files bringt ebenfalls was, momentan sinds ja 5 Stück, die man vermutlich leicht auf 2-3 reduzieren kann.

          Ich mach grad ähnliches, nur hilft bei mir eh scho nix mehr, das is einfach zuviel ;)

        • Torsten says:
          27. December 2009 at 19:55

          Habe mir das Plugin gestern installiert. Zeigt im Prinzip ja die gleichen Informationen wie die Funktion aus den Webmaster-Tools. Daher kam ich nämlich auf die Idee. ;)
          Also bräuchte ich eigentlich nur die Inhalte der CSS-Dateien in eine einzige Datei übernehmen, die Aufrufe für die jeweiligen Dateien auskommentieren und die einzelne Datei dann im Header angeben, oder?

        • Uli says:
          27. December 2009 at 22:07

          Genauso funzt das ganze :) Manchmal sind auch Sachen doppelt vorhanden, behalt dir das im Hinterkopf. Die werden in der richtigen Reihenfolge wieder das richte anzeigen, aber man kann ja das erste gleich weglassen.

        • Torsten says:
          30. December 2009 at 08:41

          Erstmal die ganzen CSS-Aufrufe in den Plugins, etc. finden, aber das ist eigentlich auch nur eine Fleißarbeit. Werde mir das mal anschauen. :)

  3. Frank says:
    27. December 2009 at 19:20

    Suche in den Plugins nach add_filter('the_content' und prüfe, ob du das brauchst. Ich kenne kein WP plugin, was Geany richtig und sinnvoll einsetzt, daher habe ich mir eine eigene Lösung gebaut, die aber noch nicht soweit ist, dass ich sie in die Öffentlichkeit geben kann, die Zeit. Wichtig; Code sollte im Editor maskiert abgelegt werden, sonst muss das ein Plugin machen und das kostet Last, weil es ein Filter ist.

    Reply
    • Torsten says:
      27. December 2009 at 19:26

      hmm... in drei Plugins reingeschaut (wp-seo, wp-syntax, wp-fancyzoom) und alle drei hatten "add_filter('the_content'" im Code. Wäre Deine Empfehlung, alle Plugins, die das beinhalten, zu deaktivieren / löschen?
      Was meinst Du mit "maskiert ablegen"?

      Reply
      • Frank says:
        27. December 2009 at 20:03

        Fancyzoom, Wp Syntax ja; wpSEO musst du wissen; ich nutze nie ein Plugin, passe aber auch die Themes an bzw. erstelle sie nach SEO gesichtspunkten.
        Maskieren: < muss als &< sein etc.

        Reply

Leave a Reply