Profilerstellungsratschlag – Versuch, das Problem beim Laden der Website zu lokalisieren

Lesezeit: 3 Minuten

Ich habe eine WordPress-E-Comm-Site übernommen (obwohl es bei dieser Frage eher um die Profilerstellung im Allgemeinen geht), die ein Leistungsproblem aufweist, das anscheinend nur einen bestimmten Bereich im Admin-Bereich des CMS betrifft. Beim Versuch, einen bestimmten Produkttyp zu bearbeiten, der mit einer großen Anzahl von Attributen verknüpft ist, führt die Seite in 99 % der Fälle dazu, dass der Browser abstürzt. Ich hatte erwartet, dass dies auf MySQL-Abfragen zurückzuführen ist, die den Engpass verursachen, aber als ich die Datenbank profilierte, erhielt ich die folgenden Ergebnisse:

Abfragen insgesamt: 174 – Gesamtzeit der MySQL-Abfragen: 0,11370

Dies deutet darauf hin, dass der Engpass an anderer Stelle auftritt, aber ich bin mir nicht sicher, wo er sein könnte. Wenn ich YSlow auf der Seite ausführe, gibt es dort nichts Drastisches, das das Problem erklären würde, obwohl etwa 20 Skripte und Stylesheets geladen sind, sodass dort einige Optimierungen vorgenommen werden könnten. Ich werde eine Opcode-Cache-Bibliothek aktivieren, die die PHP-Leistung verbessert, aber gibt es noch etwas, was ich tun kann, um zu versuchen, das Problem hier zu identifizieren? Vielen Dank.

  • Wenn der Browser abstürzt, gibt es wahrscheinlich zu viel HTML auf eine bestimmte Weise, das den Browser zum Absturz bringt. Oder hat “Absturz des Browsers” den Browser nicht wirklich zum Absturz gebracht?

    – hakre

    29. Januar 2012 um 19:38 Uhr

  • Nun, in Chrome friert die Seite für ein paar Minuten ein, erholt sich manchmal, manchmal nicht.

    – bsod99

    29. Januar 2012 um 19:41 Uhr

  • Wurde die Seite bereits vollständig geladen? Hast du Javascript deaktiviert?

    – hakre

    29. Januar 2012 um 19:42 Uhr

  • Ich habe mit und ohne aktiviertem JS getestet. Ohne JS scheint die Seite konsistenter geladen zu werden, obwohl es immer noch sehr lange dauert

    – bsod99

    29. Januar 2012 um 19:51 Uhr

  • Metrik sowie die Ausgabegröße der Seite. Ich vermute, dass es ziemlich groß ist. Deaktivieren Sie Javascript für den Moment, um Nebenwirkungen zu reduzieren.

    – hakre

    29. Januar 2012 um 20:05 Uhr

Verwenden Sie einen Profiler wie Xdebug … wenn das Problem nicht in der Datenbank liegt, hat mein PHP das Problem … finden Sie heraus, welcher Teil des Codes länger dauert … Xdebug wird Ihnen die Zeit pro Funktionsaufruf sowie die Speichernutzung mitteilen .

Als ich das letzte Mal WordPress profilierte, brauchte ich ein Dutzend microtime(1)-basierte Berechnungen, um den Ort zu finden, der die Hälfte von 2,5 Sekunden Ladezeit benötigte. Es wurde die .mo-Lokalisierungsdatei geladen und analysiert.

Auch die Installation des APC-Cache war ein beträchtlicher Gewinn, da sich herausstellte, dass WordPress ein stark aufgeblähtes Monster ist, das viel Zeit verbraucht, um seine Codes zu analysieren.

Ich würde

  • Verwenden Feuerwanze‘s oder Chrome’s Net Panel, um zu sehen, ob es die Seite oder die JavaScript/CSS/Bilder sind, die die Verlangsamung verursachen (Front-End)
  • Verwenden kräuseln um zu sehen, wie lange die Seite braucht: time curl -b PHPSESSID=123 http://example.com/wp-admin/
  • Aktivieren/installieren Xdebug und aktivieren Sie die Profilerstellung. Verwenden KCachegrind um zu sehen, welche Funktionen die größten Verzögerungen verursachen.

Benutzeravatar von Nir Alfasi
Nir Alfasi

Feuerwanze (Add-On zu Firefox) ist das beste Tool, das ich kenne, um solche Probleme zu lokalisieren. Sie können auch ein anderes Plug-in namens “Seitengeschwindigkeit“. Es zeigt Ihnen genau, welcher Teil länger zum Laden braucht. Eine andere Möglichkeit besteht darin, Ihren Code mit “Zeit” -Druck zu debuggen und zu sehen, welcher die größte Zeitlücke hat:
http://php.net/manual/en/function.microtime.php

1386330cookie-checkProfilerstellungsratschlag – Versuch, das Problem beim Laden der Website zu lokalisieren

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy