perun.net – WordPress & Webwork



WordPress: Performance-Problem der besonderen Art

Von am 15. 06. 2010 um 11:57 – Aktualisiert am 20. 07. 2011 um 02:51

Leute ich habe in den letzten Tagen hier ein Performance-Problem, da würde man am liebsten in die Tischplatte beißen. Das Problem existiert erst seit ein paar Tagen. Uns selber und einigen aufmerksamen Lesern ist aufgefallen, dass unsere Websites langsamer geworden sind.

Gute Werte

Trotz guter Werte schlechte Performance

Ich habe daher in den letzten Tagen viele Testreihen und einige Optimierungsmaßnahmen durchgeführt. In vielen Punkten bin ich schlauer, aber das Performance-Problem konnte ich leider nicht vollständig lösen.

Das Problem: statische Grafiken

Es fing damit an, dass die Response-Zeiten (in der das komplette Dokument geladen wurde) sich erhöht haben und Spitzenwerte von über 4 Sekunden hatten. Durch diverse kleine Maßnahmen, wie z. B. vermehrten Einsatz von Sprites, Flattr statisch anstatt dynamisch auf der Startseite, Optimierung der CSS-Datei etc. konnte ich dieses Problem in den Griff bekommen.

Das Hauptdokument oder besser gesagt, die HTML-Ausgabe der Startseite ist nicht das Problem, sondern kurioserweise statische Komponenten, wie zum Beispiel Layoutgrafiken oder Bilder und das in den meisten Fällen 3-4 Grafiken:

Statische Komponenten laden nicht

Das Problem: statische Komponenten zicken herum

Wie man auf dem Screenshot sehen kann sind es diese drei Grafiken die streiken, in sagen wir 80% der Fälle. Manchmal gesellt sich noch beitrag-hinweis.gif oder Büchercover aus der Sidebar hinzu. Aber auf jeden Fall handelt es sich um statische Grafiken, die entweder im der CSS-Datei oder in footer.php bzw. sidebar.php referenziert werden.

Ich habe diese statische Grafiken sogar auf einer anderen Domain ausgelagert, aber geholfen hat es nicht. Ach ja, und manchmal sind es die Smileys, an die sich die Seite verschluckt.

Deaktiviere ich alle Plugins ändert sich nichts am Problem. Schalte ich auf ein anderes Theme, zum Beispiel auf Default oder auf mein Red Train, dann habe ich keine Probleme mit den Grafiken.

Liegt es also am Theme? Aber was könnte es denn sein? Immerhin habe ich auch noch gestern über eine Stunde zusammen mit Sergej das Problem näher angeschaut und schlauer sind wir auch nicht geworden.

Aber auch wenn es am Theme liegt, dann ist das nur ein Teil des Problems, es sind nämlich alle WP-Seiten des Accounts betroffen (wenn auch nicht so stark) und alle Backends sind unendlich langsam. Zudem sind auch die Smileys manchmal das Problem und diese sind im Theme selber nicht referenziert.

Jens brachte mich auf den Gedanken, dass evtl. die Pfadangaben durcheinander gekommen sein könnten. Daher habe ich die Pfade zu den Bildern absolut notiert und es ändert sich auch hier nichts.

all-inkl so: Alles Roger in Kambodscha

Da mir das ganze etwas komisch vor kam, habe ich den Support von all-inkl kontaktiert und zwei Mal wurde mir versichert, dass mit dem Server alles in Ordnung sei. Bestätigt wurde diese Aussage als ich meine statischen Projekte auf dem gleichen Account getestet habe.

Also muss das Problem irgendwie bei WordPress liegen. Nur was? Wenn man sich dann die erste Abbildung, sprich die recht guten Werte anschaut, dann wird die schlechte Performance um so unlogischer.

Diesen Artikel weiterempfehlen:

Hinweis:
Schulungsunterlagen für WordPress
Aktuell und praxiserprobt. Als E-Book für den Privatgebrauch oder als PDF-Volumenlizenz für den geschäftlichen Einsatz.

Verwandte Artikel:

 — 


48 Kommentare

  1. 1. – Frank

    Kommentar vom 15.06.2010 um 12:06

    hi,

    hast du Trackingsoftware mitlaufen? Statpress o.ä.? Die bremsen auch ganz schön aus.

    Ansonsten, sind die Pics oben eigentlich vorhanden? Oder findet er sie nicht?
    Wie gross sind die?

    ciao
    Frank

  2. 2.Viktor

    Kommentar vom 15.06.2010 um 12:10

    Bei mir brauchen alle Deiner Grafik ewig zum laden! 700ms – 19s !!!
    Hast Du irgendwie am zlib rumgespielt? Hast Du es überhaupt an? Wenn ja, hat der Server vielleicht ein Problem damit?

    Übrigens hat dein Retweet button von topsy anscheinend auch ein Problem und braucht bei mir allein 4.5s

  3. 3.Andreas

    Kommentar vom 15.06.2010 um 12:12

    Ich hab mal einen Screenshot gemacht, da wird deutlich wo es bereits beim Laden hängt: http://twitpic.com/1wy9gj

    Vielleicht hilft dir das ja weiter. Scheinbar liegt es am Header und/oder der Sidebar. Zumindest würde ich da mal ansetzen und suchen. Artikel sind Ruckzuck geladen bei mir.

    Gruß,
    Andreas

  4. 4.Markus

    Kommentar vom 15.06.2010 um 12:13

    Hast Du es mal mit Sudomains versucht … css.perun.net für die Styles und img.perun.net für die Bilder … anstelle der .eu Domain? Kann mir zwar nicht vorstellen das es was ändert, aber manchmal ist komisch.

  5. 5.Viktor

    Kommentar vom 15.06.2010 um 12:15

    Was mir grad noch aufgefallen ist:

    Wenn ich JS deaktiviere ist die Seite fix da!

  6. 6.Tweets that mention perun.net - Webwork, WordPress und Internet -- Topsy.com

    Pingback vom 15.06.2010 um 12:17

    [...] This post was mentioned on Twitter by Vladimir Simovic, Andreas H. Andreas H said: RT @vlad_perun #WordPress, #Performance-Problem der besonderen Art http://goo.gl/fb/bwdUF #wordpressfaq #wordpresstipps [...]

  7. 7.Perun

    Kommentar vom 15.06.2010 um 12:21

    @Viktor,

    mit und ohne JS, bei mir ändert sich leider nichts :-(

  8. 8.Perun

    Kommentar vom 15.06.2010 um 12:22

    @Viktor,

    ich habe keinen Zugriff auf die Server-Einstellungen (Shared-Hosting).

  9. 9.Perun

    Kommentar vom 15.06.2010 um 12:23

    @Frank,

    ich habe alle Plugins deaktiviert und es ändert sich nichts. Die Grafiken, mit Ausnahme der Kopfgrafik (24 KByte) sind kleiner als 2 KByte.

  10. 10.Viktor

    Kommentar vom 15.06.2010 um 12:25

    vergiss den letzten Kommentar, war zu früh losgeschossen

    In den Screens wird deutlich, dass es immer wieder andere Grafiken sind und die von der eu Domain am längsten dauern…. Aber es keine Andere Regelmäßigkeit gibt:

    http://yfrog.com/fvt9wj
    http://yfrog.com/2mtgpj
    http://yfrog.com/j3iyqj

  11. 11.Dennis Morhardt

    Kommentar vom 15.06.2010 um 12:33

    Bei mir will der das JavaScript für das Plugin "Live Comment Preview" nicht laden. Dadurch hängt bei mir die Seite an der Stelle bis zu 21 Sekunden, denn es entsteht ein Loop: Auf Fehlerseite wird wieder versucht das JS zu laden, und immer und immer wieder. Deaktiviere doch mal das Plugin.

  12. 12.ocean90

    Kommentar vom 15.06.2010 um 12:36

    Im Chrome wurde bei mir gerade gar kein Stylesheet geladen, im Firefox konnte kommentar-icon-klein.gif, sowie quicktags.js und sociable.css nicht geladen werden.
    Wie siehts denn mit der .htaccess aus? Mal leeren/umbennen und in WP die Standardpermalinks einstellen.

  13. 13.Dennis Morhardt

    Kommentar vom 15.06.2010 um 12:37

    Des Weiteren existiert die statische Datei "http://www.perun.net/wp-content/themes/perun5/img/twitter-feed.png" nicht, dadurch landen wir wieder im bekannten Fehlerloop (9s).

  14. 14.ad

    Kommentar vom 15.06.2010 um 12:38

    Erschreckend, dass selbst euer geballtes Know-how nicht dahinter kommt. Ich drücke die Daumen.

  15. 15.ad

    Kommentar vom 15.06.2010 um 12:39

    Nachtrag: ich klicke mich hier so durch und merke nichts davon, dass etwas langsam ist. Hast du es schon hinbekommen?

  16. 16.Ivan

    Kommentar vom 15.06.2010 um 12:40

    @Perun
    Das ist natürlich sehr ärgerlich, wenn die Webseite nicht so will wie es sein sollte. Die Ladezeit ist wirklich lange … Leider kann ich Dir keinen Tipp geben!

  17. 17.ocean90

    Kommentar vom 15.06.2010 um 12:41

    Abgebrochen wurde auch http://www.perun.eu/net/grafiken/flattr-button-klein.png, wenn man die Dateien aber direkt aufruft sind sie vorhanden.

    Die Datei von Dennis existiert nämlich auch.

  18. 18.Perun

    Kommentar vom 15.06.2010 um 12:41

    @Dennis,

    wie gesagt, ich habe schon mehrfach alles Plugins deaktiviert gehabt. jetzt auch und trotzdem dauert es noch sehr lang.

  19. 19.Dennis Morhardt

    Kommentar vom 15.06.2010 um 12:43

    @ocean90 hat Recht. Die Dateien extieren, nur gibt es des öfteren einen 404 an den Kopf. Daher meine Vermutung: .htaccess ist Schuld.

    Noch eine Sache an der JavaScript-Front: Deine Anbindung von Google Analytics ist kaputt: "Fehler: _gat is not defined, Zeile: 413".

  20. 20.Dennis Morhardt

    Kommentar vom 15.06.2010 um 12:47

    @Perun, ja, aber ohne das "Live Comment Preview" sind es bei mir statt 19 Sekunden "nur noch" 3 Sekunden. Was mir auffällt ist noch, dass bei deinen statischen Dateien keine Caching-HTTP-Header mitgesendet werden.

  21. 21.Viktor

    Kommentar vom 15.06.2010 um 12:48

    Hast Du in dem Theme durch die Sprites oder was anderem vielleicht irgendeine dynamische Komponente der Grafikurls gebaut, die jetzt vielleicht lahmt?

    – Es sind ja immer wieder andere Grafiken.
    – Die Grafiken selbst laden fix.
    – Nur das "Connecten" dauert, also der teil, der den Link liefert?

  22. 22.Viktor

    Kommentar vom 15.06.2010 um 12:50

    bspw. sowas wie die "Smilies aktivieren" Funktion

  23. 23.Dennis Morhardt

    Kommentar vom 15.06.2010 um 12:50

    Ich weiß nicht was Perun gemacht hat, die Seite ist aber wieder (bei mir) flott.

  24. 24.Perun

    Kommentar vom 15.06.2010 um 12:50

    @Dennis,

    caching habe ich temporär deaktivert. Nicht das da der Wurm liegt. Bei mir sind es immer noch mehr als 21 Sec. Ladezeit:

    http://tools.pingdom.com/fpt/?url=http://www.perun.net/&id=2453345

  25. 25.Perun

    Kommentar vom 15.06.2010 um 12:52

    @Viktor,

    ja es sind immer andere Grafiken. Bis jetzt war auch immer das Smiley der Mitbremse, wenn ich den Smiley aus dem Artikel nehme, dann nihmt es sich eine andere Grafik.

  26. 26. – Frank

    Kommentar vom 15.06.2010 um 12:52

    Also hier auf meinem PC läuft das Teil jetzt wie Nachbars Lumpy. Alles im Millisekundenbereich.

    Viel schneller geht nimmer.

    Haste was geändert?

    ciao
    Frank

  27. 27.Viktor

    Kommentar vom 15.06.2010 um 12:54

    ich weiß nicht was Du gemacht hast, aber im Moment ist nur noch die Smiley Funktion 11s am lahmen

  28. 28. – Frank

    Kommentar vom 15.06.2010 um 13:00

    Was natürlich auch sein kann, ist dass dein Shared-Hosting lahmt.

    Neben dir sind noch 47 andere Kunden in deinem Account. Kann sein, dass es daran manchmal hakt, wenn bei denen hoher Traffic ist.

    Hiermit kannste das nachvollziehen:

    http://www.serverdna.de/

    cu
    Frank

  29. 29.cimddwc

    Kommentar vom 15.06.2010 um 13:01

    Ich – ebenfalls mit all-inkl Shared Hosting – hatte so ein Problem bei mir auch erstmals bemerkt, nachdem ich die URLs so umgestellt hatte, dass Theme-/Header- und einige andere Bilder von zwei Subdomains geladen werden. Nach einiger Zeit war das aber wieder vorbei und seitdem nur noch sehr selten – zumindest bezogen darauf, was ich selber bemerke.

    Ich hab's dann auf sich beruhen lassen in der Annahme, dass diese gesteigerten gleichzeitigen Zugriffe dem Webserver manchmal, wahrscheinlich wenn er mit anderen Kunden auch gerade viel zu tun hat, eben zu viel auf einmal werden, und in der Hoffnung, dass es nicht zu oft vorkommt…

  30. 30.Schepp

    Kommentar vom 15.06.2010 um 13:07

    Es ist tatsächlich die Reaktionszeit des Servers, die (ungebrochen) das Problem darstellt.

    Da es sich nicht umein generelles Server-Problem, sondern um ein Theme-Problem handelt, wäre die .htaccess daher nicht uninteressant einzusehen. Magst Du sie uns posten? Hast Du noch weitere innerhalb Deines Themes-Ordners liegen? Falls ja: bitte auch mal posten.

    Desweiteren könntest Du noch etwas am Caching ändern und dadurch die Requests, auch die schnellen 304er, komplett einsparen, auf dass der Browser alles aus seinem Cache bedient. Ohne Aufruf, kein Lahmen. Nichtsdestotrotz ist das nur Symptom- und keine Ursachenbekämpfung.

  31. 31.ocean90

    Kommentar vom 15.06.2010 um 13:15

    Was ich gerade feststellen konnte, dass unter wordpress-buch.de und .vlad-design.de mehr oder weniger das gleiche Problem vorhanden ist: http://grab.by/4WD6 – Problem mit der social.css
    http://grab.by/4WD8 – Längere Ladedauer von navi-oben.gif
    In wie weit hängen die drei zusammen, selbe Installation, WPMU/Multisite?

  32. 32.Perun

    Kommentar vom 15.06.2010 um 13:17

    @ocean90,

    das einzige was die gemein haben ist das ich Sie betreue :-) und die alle auf dem gleichen Account liegen.

  33. 33.Perun

    Kommentar vom 15.06.2010 um 13:23

    @Schepp,

    hier die .htaccess:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>

    # END WordPress

    #RedirectMatch permanent /archiv/category/([^\.]+) /kategorie/$1
    #RedirectMatch permanent /archiv/([^\.]+) /$1

    # RewriteCond %{HTTP_HOST} ^perun.net$
    # RewriteRule ^(.*)$ http://www.perun.net/$1 [R=301,L]

    # RewriteEngine On
    # RewriteCond %{HTTP_HOST} !^www.perun.net
    # RewriteRule (.*) http://www.perun.net%{REQUEST_URI} [R=301,L]

    # RewriteEngine On
    # RewriteCond %{HTTP_HOST} ^perun\.net
    # RewriteRule ^(.*) http://www.perun.net/$1 [L,R=301]

    #order allow,deny
    #deny from 213.96.32.14
    #allow from all

    # protect wpconfig.php
    <files wp-config.php>
    Order deny,allow
    deny from all
    </files>

    # mod_deflate aktivieren
    <FilesMatch "\\.(js|css|html|htm|php|xml)$">
    SetOutputFilter DEFLATE
    </FilesMatch>

    # cache
    <FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf)$">
    ExpiresActive on
    ExpiresDefault "access plus 35 days"
    #Header unset ETag
    #FileETag None
    </FilesMatch>

    an den Auskommentierung siehst du das ich schon einige Kombinationen versucht habe. Einige der Relikte aus alter Zweit (Umleitung von nicht-www auf www) sind noch auskommentiert drin.

    Innerhalb des Themes-Ordners ist nur der img-Ordner.

  34. 34.ocean90

    Kommentar vom 15.06.2010 um 13:39

    @Perun
    Ok, heißt also es sind unterschiedliche WordPress Installation. Habe mal den Link von Frank ausprobiert und ein paar Seiten getestet, die laut dieser Liste auch auf *deinem* Server liegen.
    Ergebnis: Du bist nicht der einzige. Bei Seiten mit vielen Bildern musste auf eins-zwei Bilder immer länger gewartet werden. Oder: Es wurde einfach abgebrochen, siehe dazu hier: http://grab.by/4WE6

  35. 35. – Frank

    Kommentar vom 15.06.2010 um 13:54

    was du mal spasshalber noch machen kannst, ist das hier noch in die htaccess eintragen:

    php_value memory_limit 128M

    Hast du auch mal ins error.log des Hosters geguckt? Steht da was drin?

    bye

  36. 36.Monika

    Kommentar vom 15.06.2010 um 13:56

    ich bin ja kein ServerJunkey, doch ich las mal, dass man Bilder niemals länger als 30 Tage cachen sollte,weils sonst zu Problemen kommen kann.

    Sprich sie werden dann nicht angezeigt.

    Ich habe das nur in meinem Kopf und kanns nicht belegen,aber vielleicht ist es eine zusätzliche Überlegung wert.

    lg

  37. 37.Frank

    Kommentar vom 15.06.2010 um 13:57

    Auf die schnelle, da ich die Kommentare nicht gelesen habe:
    – JS in den Footer und im Test deaktiveren, daher am besten via wp_enque_script laden.
    – Grafiken via CSS, dann ist da der Platzhalter und per CSS ist es ein geringeres Problem
    – besser noch, hole die statischen Bilder via Bas64 in das CSS
    – prüfe die Rewrite Rules der Pages, eventuell hast du zu viele.
    – prüfe die Queries "Debug Queries" Plugin, auch wenn ich nicht daran glaube
    – MySQL Slow von allinkl abfordern und prüfen
    Schau dir den Traffic an, eventuell hakt es irgendwo, Feed? auch da können Inhalte sein, die bremsen

  38. 38.Viktor

    Kommentar vom 15.06.2010 um 14:06

    seit wann hast Du den Cache in der .htaccess?

    es kommt zumindest nicht korrekt im Browser an: http://yfrog.com/mhpyxj

  39. 39.Viktor

    Kommentar vom 15.06.2010 um 14:11

    ocean90 hat die "Lösung"
    Alle Deine IP Nachbarn haben das gleiche Problem!
    => Druck beim Provider machen! Die müssen Dir das Gegenteil beweisen (dass es nicht der Server ist)

  40. 40.Viktor

    Kommentar vom 15.06.2010 um 14:13

    Ich hatte das schon mal auf einem Server – da hatte ein Nachbar ein DOS Angriff aufgrund eines Hacks gefahren und es stand auch fast alles Still.

  41. 41.Schepp

    Kommentar vom 15.06.2010 um 14:14

    Der Server bzw. ein Switch bei Allinkl hat definitiv nen Hau weg. Hab eben ein Dauerping laufen lassen und von 519 gesendeten Paketen 2 komplett verloren.

    Wenn die sich doof stellen, dann gib doch den anderen Vertragskunden auf dem Server Bescheid (via ServerDNA). Dann macht Ihr mal zusammen Stress :)

  42. 42. – Frank

    Kommentar vom 15.06.2010 um 14:18

    jepp, oder schick ihnen den Link zu diesem Thread hier :-)

  43. 43.oli

    Kommentar vom 15.06.2010 um 14:54

    Hi Vlad,
    ich glaube deinen Aussagen bzgl Allinkl nicht so recht. Ich hab da auch alles liegen und bin mit dem Tempo absolut nicht zufrieden.
    Selbst bei dem teuren Paket hängt es schon sehr lange. Der Test mit einem anderen theme brachte auch nicht wirklich was.
    So wie ich dich "kenne" wird der fehler weniger bei dir zu finden sein sondern auf der Infrastruktur die wir hier nutzen.
    Schade das sich Allinkl da auch nicht wirklich einbringt. Der Support ist schon lange nicht mehr das was er mal war.

  44. 44. – Frank

    Kommentar vom 15.06.2010 um 15:11

    wennst ne Empfehlung für 2 gute Provider brauchst, schick mir ne Mail.

    Ich möchte hier nicht öffentlich Werbung machen…… :wink:

  45. 45.Rene

    Kommentar vom 15.06.2010 um 15:47

    Hat sich was geändert oder warum ist bei mir die Seite ziemlich schnell?

  46. 46. – quakemaster

    Kommentar vom 15.06.2010 um 15:51

    Tja, leg mal eines deiner betroffenen Projekte auf einen anderen Hoster. Ich tippe auf Allinkl als Quelle des Problems… :evil:

    cu +quakemaster+

  47. 47.WordPress: Performance-Problem erkannt, aber noch nicht gebannt | perun.net

    Pingback vom 15.06.2010 um 15:54

    [...] WordPress: Performance-Problem der besonderen Art [...]

  48. 48. – Sören G. Prüfer

    Kommentar vom 16.06.2010 um 23:52

    Nur eine Vermutung. Bei diesem Fehlerbild tippe ich auf DNS. Warum?

    Verzögerung beim statischer Content kann erst mal nicht an WP und PHP liegen. Sicher macht der Apache seine Arbeit klaglos. Aber um beispielsweise seine LOGs zu füllen wird die IP des Aufrufers mit Reverse-DNS in einen Namen gewandelt und im Protokoll vermerkt. Gibt es hier ein DNS-Problem, kommt es immer mal zu Stockungen beim ausliefern. Lege doch mal Dein WP mit DB auf ein anderes Hosting als Kopie… Das meinen auch die anderen Kommentatoren nicht umsonst.

    Richtig? If (Nein) -> remove(Beitrag) ;-)

Tut mir Leid, aber die Kommentar-Funktion ist momentan deaktiviert.



Weblog der perun.net webwork gmbh mit Artikeln zum Thema WordPress, Webwork, und Internet.