Performance Probleme neuer Seite
Eingetragen von Julsen (178)am 19.02.2014 - 10:46 Uhr in
Hallo zusammen,
gibt ja bereits einige Themen zu meinem Problem und auch diverse Lösungsansätze, wovon ich auch schon einiges umgesetzt habe. Viele sind leider schon was in die Jahre gekommen und beziehen sich auch zum Teil auf Drupal 6 oder älter und es sind leider auch nicht alle Module für Drupal 7 verfügbar, wie z.B. Cache Router. Daher wollte ich mal ein neues Thema starten.
Habe mein aktuelles Projekt lokal unter XAMPP entwickelt (hat da auch schon längere Ladezeiten) und die Tage auf einen Server übertragen. Der Server ist ein 4 Core Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 24GB Ram und als OS wird Ubuntu genutzt. Apache, PHP und MySQL befinden sich in der aktuellen Version und es ist auch noch suhosin installiert. Memory Limit für PHP habe ich auf 2GB gestellt.
Die Site ist noch nicht live und befindet sich noch in der Entwicklung. Aktuell sind es um die 600 Inhaltsseiten (300 deutsch und 300 englisch). An Modulen ist die Seite eigentlich auch nicht überladen. Verwende eigentlich nur die nötigen Module wie Views, Taxonomy, Media, Devel, Fields, Flags, CKEditor, Metatags, den Kram für Mehrsprachigkeit, Path, Redirect, TVI, Webform, XML Sitemap und dann noch die für die benötigten Module für die genannten Module. 2 kleine Module habe ich auch noch selber entwickelt.
CSS und JS word aggregiert und Caching ist für anonyme Nutzer auch aktiviert. Interne Drupal Statistik ist deaktiviert.
Surfe ich die Seite an, so ist die Antwortzeit des Servers im perfekten Bereich, also reagiert sofort. Leider dauert es teilweise über 10 Sekunden bevor ich überhaupt etwas angezeigt bekomme. Habe daher auch mal Devel und XHProf aktiviert. Erneutes besuchen geht dann natürlich wesentlich schneller.
Executed 465 queries in 120.8 ms. Queries exceeding 5 ms are highlighted. Page execution time was 1573.16 ms. XHProf output. Memory used at: devel_boot()=6.25 MB, devel_shutdown()=107.92 MB, PHP peak=116.25 MB.
Executed 331 queries in 63.05 ms. Queries exceeding 5 ms are highlighted. Page execution time was 1132.89 ms. XHProf output. Memory used at: devel_boot()=6.25 MB, devel_shutdown()=97.25 MB, PHP peak=101.75 MB.
Die Beispiele oben liegen bei 1-2 Sekunden laut Anzeige, wenn ich aber die Seite anfange zu laden und dabei mitzähle, so komme ich immer auf min. 4 Sekunden bis ich etwas angezeigt bekomme. In den 4 Sekunden ist die Seite dann immer weiß und nach den 4 Sekunden ist alles komplett da. Hier ist es auch egal ob es nur eine Text Seite ist oder eine Seite mit vielen Bildern.
Die einzige Fehlermeldung die ich seitens Drupal angezeigt bekomme ist
Notice: Undefined index: term_node_tid_depth in tvi_render_view() (Zeile 210 von /var/www/vhosts/test/httpdocs/sites/all/modules/tvi/tvi.module).
Da diese aber nicht immer angezeigt wird, bzw nicht auf allen Seiten, so denke ich das dies nichts mit den langen ladezeiten zu tun hat?
Hätte evtl. noch wer einen Tip oder Rat wie ich die Performance verbessern könnte? Würde es auch schon helfen, wenn ich die nicht aktivierten Module lösche? Laut XHProf benötigen die Funktionen
main() 277ms
_drupal_bootstrap_full 248ms
module_load_all 194ms
drupal_load 192ms
am meisten Zeit. Rest liegt im 1-2 stelligen ms Bereich.
Viele Grüße
Julsen
- Anmelden oder Registrieren um Kommentare zu schreiben
vielleicht ist es ein browserproblem?
am 19.02.2014 - 11:16 Uhr
Die Seite ist in ca 1-2 Sekunden zur Auslieferung bereit.
Also muss die Bremse im Auslieferungsprozess liegen, der erheblich vom Browser abhängt.
Schau mal, was da geht.
Ok, danke.Im Firefox und IE
am 19.02.2014 - 11:34 Uhr
Ok, danke.
Im Firefox und IE braucht die Seite in etwa identisch lange. Firefox scheint die komplette Seite wohl vor dem Ausliefern zu laden. Safari und Chrome sind etwas schneller und laden die Bilder erst, wenn der Rest schon angezeigt wird. Dauert hier als anonymer Nutzer aber auch 3-4 Sekunden. Sind die 1-2 Sekunden zur Auslieferung nicht eigentlich auch zu hoch?
Bei Gelegenheit wollte ich noch ein Modul zum asynchronen Laden der JS und CSS verwenden und teilweise die unwichtigen JS und CSS Ressourcen in den Footer packen, so dass die das Rendern nicht blockieren
Habe jetzt auch mal sämtliche
am 19.02.2014 - 16:21 Uhr
Habe jetzt auch mal sämtliche Module, die nicht mehr genutzt werden, über den Admin Bereich deinstalliert und dann aus dem Modul Verzeichnis gelöscht. Des Weiteren noch den Patch für den TVI Fehler eingespielt. Zusätzlich habe ich noch LABjs installiert, um die Javascripte asynchron zu laden. Leider war alles ohne Erfolg.
Executed 894 queries in 566.33 ms. Queries exceeding 5 ms are highlighted. Page execution time was 8974.91 ms. XHProf output. Memory used at: devel_boot()=6.24 MB, devel_shutdown()=123.52 MB, PHP peak=131.5 MB.
Die Datenbankabfrage ist eigentlich meist innerhalb von 10-500ms erledigt. Nur leider schwankt die Page execution von 1.2 bis 10 Sekunden. Besteht eigentlich die Möglichkeit seitens Drupal das laden von jQuery zu unterbinden? Würde gerne sämtliche Scripte manuell per Template laden und auch auf jQuery_Update verzichten.
Falls es wen
am 23.03.2014 - 18:29 Uhr
Falls es wen interessiert.
Habe nun APC installiert und diesem 1gb Memory spendiert. Somit konnten die DB Queries auf 200ms reduziert werden. die Page execution time liegt jetzt bei 800-1400ms. Der PHP Memory peak konnte von 131MB auf ca. 60MB reduziert werden.
Anonyme Nutzer bekommen die Seite als Cache angezeigt und die Seite läd sofort.
Denke ist zwar immer noch nicht optimal mit 1-2 Sekunden und daher lasse ich den Beitrag mal noch als offen.
Installiere auf jeden Fall
am 23.03.2014 - 19:52 Uhr
Aktiviere zusätzlich SQL-Query-Cache und installiere auf jeden Fall noch Memcache ....
... und/oder ... falls du lange Weile hast "Varnish" :-)
Nachtrag: Lagere sämtliche Bilder und die CSS/JS auf CDN aus bzw. schau dir dazu mal die Drupal-Module an ..... wenn du viele Grafiken/Icons etc. verwendest, nutze Sprites - sprich - alle Grafiken/Icons sind in einer einzigen Bilddatei enthalten und werden nur per CSS verschoben .... das hat den Vorteil, dass der Browser nicht unzählige winzige Grafiken parallel laden muss sondern nur eine einzige Datei ... für den Browser ist das auf jeden Fall besser zu handeln (von der Geschwindigkeit her).
Jupp danke, direkt mal
am 23.03.2014 - 20:28 Uhr
Jupp danke, direkt mal installiert :). Dachte eigentlich mit nem quad Xeon und 26 gig Ram komme ich locker hin, auch ohne viel zu cachen. Auf SQL Query Cache verzichte ich denke ich erstmal. Muss die Page execution time noch weiter runter bekommen. Grafiken nutze ich recht weniger, nur halt viele Bilder die ich nicht als Sprite setzen kann.
Lies Dir bitte auch die Doku
am 23.03.2014 - 20:36 Uhr
Lies Dir bitte auch die Doku von Memcache und APC durch - falsch konfiguriert kann man das System verlangsamen statt es schneller zu machen ....
SQL Query Cache ist trotzdem zu empfehlen da dies Vorteile für angemeldete User bringt da der Datenbankzugriff minimiert wird.
Hatte die Dokus bissl
am 25.03.2014 - 20:50 Uhr
Hatte die Dokus bissl angelesen, sollte aber von den Settings her passen.
Die Seite ist wenn ich eingeloggt bin deutlich schneller geworden, nur leider braucht es wenn die Seite für einen längeren Zeitraum nicht besucht wurde, mega lange bevor sich überhaupt was tut:
Executed 1180 queries in 713.85 ms. Queries exceeding 5 ms are highlighted. Page execution time was 8818.07 ms. Memory used at: devel_boot()=2.11 MB, devel_shutdown()=91.25 MB, PHP peak=98 MB.
Erneutes ansurfen der Seite
Executed 275 queries in 64.29 ms. Queries exceeding 5 ms are highlighted. Page execution time was 788.43 ms. Memory used at: devel_boot()=2.11 MB, devel_shutdown()=46.27 MB, PHP peak=46.75 MB.
Für anonyme Nutzer ist die Seite teilweise super schnell und teilweise auch wieder mega lahm.
Wenn ich mir den Log von XHProf anschaue, brauchen die Funktionen (erster Aufruf nach mehreren Stunden ohne Aufruf)
main()
menu_execute_active_handler
drupal_deliver_page
drupal_deliver_html_page
call_user_func_array
module_invoke
am längsten. Die ersten 4 liegen bei über 10.000ms und die letzten beiden bei über 8.000ms. Klicke ich mich hier weiter druch, komme ich auf die Funktion drupal_cron_run-> module_invoke. Heißt das Drupal lässt erst mal einen Cron laufen und blockiert so lange bis er vollständig geladen ist oder wie kann man das verstehen? Muss man den Cronjob speziell noch konfigurieren oder sollte man den durch ein Shell Script austauschen?
Bei weiteren Aufrufen benötigen (Funktionen durchgeklickt und am Ende bleibt Views über)
module_load_all
module_invoke_all
call_user_func_array
menu_execute_active_handler
drupal_deliver_page
drupal_deliver_html_page
drupal_render_page
block_page_build
block_get_blocks_by_region
block_list
_block_render_blocks
module_invoke
call_user_func_array
system_block_view
menu_tree
menu_tree_page_data
menu_tree_check_access
_menu_tree_check_access
_menu_tree_check_access@1
_menu_link_translate
_menu_check_access
call_user_func_array@1
tvi_render_view_access
view::access
view::init_display
Kann man da noch irgendwie etwas optimieren? Habe leider keine Ahnung mehr was ich noch machen kann.
Habe gerade noch Boost installiert und eingerichtet. Cron steht jetzt auch auf 1 mal am Tag
Wenn Du Root-Zugriff hast,
am 08.06.2014 - 11:49 Uhr
Wenn Du Root-Zugriff hast, installiere folgendes pl-Script und führe es über SSH aus.
http://www.mysqltuner.pl
Dieses Script zeigt dir die Flaschenhälse an und gibt Tipps zum Optimieren von MySQL.
Ich nutze ja schon APC und Memcache aber durch den mysqltuner läuft das jetzt noch alles viel besser.
Besonders wenn ich als Admin eingeloggt war und gearbeitet habe, hat das teilweise ziemlich gelaggt und gelamt ... nach dem Feintuning der my.cnf ist das jetzt alles spürbar besser geworden.
Echt TOP!
Danke. Bei mir hat es sich
am 08.06.2014 - 11:55 Uhr
Danke.
Bei mir hat es sich aber inzwischen irgendwie wieder gelegt. Habe die Memcache und APC Module von Drupal bereits wieder deaktiviert, Boost habe ich auch wieder gelöscht. Aktuell nur noch Memcache und APC im Apache aktiviert. Keine Ahnung wodran es gelegen hat.
Lass den mysqltuner trotzdem
am 08.06.2014 - 12:05 Uhr
Lass den mysqltuner trotzdem mal rüberlaufen. Die Anpassungen dauern nur ein paar Minuten - dann mysql neu starten und freuen :-)
Ich nutze fast 200 Blöcke und der Aufruf der Block-Übersicht hat immer unglaublich gelaggt und recht lang gedauert ... nach dem Tuning der my.cnf dauert das alles fast nur noch einen Wimpernschlag.
Das Arbeiten im Admin-Bereich macht jetzt wieder richtig Spaß und auch der Aufruf der Nodes/Profile/Views (wenn eingeloggt) ist spürbar besser geworden - ein Gedicht! :-)