[gelöst] D7 - Lange Ladezeiten - Views-Problem?

Ich krame mal meinen alten, unbeantworteten Thread wieder aus.

Das oben beschriebene Problem konnten wir bisweilen nur dadurch lösen, indem wir Boost installiert haben, und nun alles zwischenspeichern lassen. Im normalen Zustand, also wenn die Seiten direkt aufgerufen werden, ist es wirklich nicht vertretbar. Ladezeiten von 4-10 Sekunden sind da ganz normal. Auch das entfernen und deaktivieren sämtlicher Blöcke hat da nichts gebracht.

Nun will es der Zufall so, das ich derzeit auf dem gleichen Server ein anderes Projekt realisiere, was erstmal noch ganz rudimentär ist. Sprich es ist das Standardtheme installiert, und ein paar wenige Module, z.B. Views, wobei ich mit Views noch nichts gemacht habe.

Leider zeichnet sich ab, dass sich hierbei genau die gleiche Problematik ergibt wie schon oben beschrieben. Beispielhaft sei hier erwähnt, dass wenn ich z.B. über die Profileinstellung neue Felder für eben dieses Profil anlege, dass es dort bis zu 10 Sekunden dauert, bis sich die Seite nach dem Speichern aktualisiert. Das macht ein flüssiges Arbeiten natürlich unmöglich. Auch braucht er teils recht lange die Startseite aufzurufen, obwohl da lediglich die Standard-News zu finden ist.

Der Server ist sowohl beim Speicher, als auch die CPUs nicht wirklich ausgelastet, sprich daran sollte es eher nicht liegen. Nun frage ich mich, ob es eventuell irgendeine Konfiguration des Servers sein könnte, die dazu führt. Denn interessanterweise habe ich diese Probleme nicht, wenn ich die Installation lokal via XAMPP laufen lasse.

Wiederum ist es aber so, dass z.B. ein Forum dass auf PHPBB basiert, oder eine andere Drupalinstallation die noch auf D5 läuft, diese Probleme nicht haben. Sprich es muss schon irgendwas mit D7 zu tun haben, wenn auch D7 selbst nicht die Ursache sein muss.

Nun ja, eventuell hat dazu irgendwer eine Idee oder einen Tipp. Würde mich freuen!

Beste Grüße vom,

Genesis

Was sagt denn das Devel-Modul zur Seitengenerierungszeit und dessen AUfteilung auf PHP und DB-Abfragen?

Hast du ein Modul oder eigenen Code in den Themes im Einsatz, über den externe Daten ins System gezogen werden?

Ist APC installiert und wie sieht die Cache-Hit Rate bzw. der Überlaufszähler aus?

Okay, ich muss nun gestehen, dass ich nicht weiß wo ich all die Sachen finde. Führe sie aber gern nach Anweisung aus.

------

Ich habe nun mal Devel + Protokollierung aktiviert. Beispielhaft hier der Auszug aus dem "Leistungsprotokolle: Details" zur Node/1 (Startseite):

20.07.2011 - node/1 - 82.50 (mb) - 3111 (ms total) - 589 (Anzahl der Abfragen) - 413 (Query ms)

Hier die Angaben aus "Leistungsprotokolle: Zusammenfassung":

20.07.2011 - 83.25 (MB Memory Max) - 79.70 (MB Memory Avg) - 3,563.0 (MS Max) - 2,955.0 (MS Avg) - 814.0 (Query MS Max) - 613.0 (Query MS Avg) - 595 (Abfragenzähler) - 511 (Abfragenzähler Avg)

Aus der Statistik:

Durchschnittlicher Speicherbedarf pro Seite: 64.6 MB
Average duration per page: 3,281.92 ms

------

Eigene Module befinden sich nicht im Einsatz, lediglich ein PHP-Skript das ein paar Infos aus der DB auflistet, welches aber über einen Block eingebunden ist. Dieses ändert aber nichts, also egal ob aktiviert oder deaktiviert.

------

APC haben wir derzeit nicht im Einsatz, wobei wir im Zuge der Probleme bereits darüber nachgedacht haben es zu installieren. Eventuell wäre das also noch eine Maßnahme. Dazu muss ich sagen, dass sich um den Server ein Freund kümmert, der selbst bei einem Server-Hoster arbeitet, und der davon doch mehr Ahnung hat als ich. :)

------

Ich hoffe das konnte deine Fragen irgendwie beantworten. :| Ich bin wirklich dankbar für jedwede Hilfe, und ebenso für jeden der sich die Mühe macht sich damit zu beschäftigen.

Beste Grüße,

Genesis

Dann würde ich mal definitiv mit APC loslegen. Ist von der Shell aus in 2 Minuten installiert. Standardmäßig wird es miest mit 64 MB konfiguriert. Das kann man für Drupal getrost verdoppeln, gerade wenn mehrere Sites auf demselben Server liegen. Ist nur zu hoffen, dass euer Apache nicht als FCGI läuft. Dann bringt APC nämlich nüscht ;)

APC ist mittlerweile installiert, und ich habe es soweit eingerichtet. Gebracht hat es gar nichts. Kläre mal mit unserem Server-Monkey ab ob FCGI läuft, wäre grundsätzlich aber wohl kein Problem das dann zu ändern.

Ich habe gerade noch mal versucht sämtliche Template-Dateien zu entfernen. Da ich einige Views, Seiten und Nodes gethemed habe, gibt es an die 30 Template-Dateien. Aber auch das hat absolut gar nichts gebracht, und da wird dann ja wirklich gar nichts mehr aufgerufen, also zumindest zusätzliche Sachen.

Stehe da echt auf dem Schlauch. Mittlerweile bin ich mir einfach nicht mehr sicher, ob nicht irgendein Modul, die zu seiner Zeit ja teils noch Beta waren, irgendwas zerschossen hat. Aber was sollte das sein? Zumal das Deaktivieren jedweder Module auch nichts gebracht hat. Die DB wurde auch mehrfach geprüft.

Unser Server-Mensch prüft jetzt noch mal den kompletten Server und alle Einstellungen, bzw. versucht die DB noch zu tweaken. Aber auch er sagt, dass eigentlich alles stimmt, und ich denke er kennt sich da wirklich ganz gut aus, weswegen man ihm da schon vertrauen kann.

Kerlo Kiste. Solch Probleme hatte ich mit D5 nie, wobei ich ja D6 komplett ignoriert habe. *hust*

Danke erst einmal für die Hilfe. Sollte noch jemandem was ein- oder auffallen, wäre ich wirklich dankbar für eine kurze Notiz! :)

Vorab: ich bin relativer Drupal-Anfänger.

Ich hatte auf meinem Managed Server bei all-inkl.com (Athlon DualCore 2x 3000 MHz mit 4 GB RAM) zunächst die Version 6.2 installiert und ein wenig damit experimentiert. Da ich glaubte ein für meine Zwecke geeignetes System gefunden zu haben, installierte ich anschließend die Version 7.7 komplett neu, und zwar auf demselben Server, aber auf einem getrennten Account.

Der Geschwindigkeitsunterschied ist fast wie zwischen Tag und Nacht. Es dauert in der 7er Version beim Erstaufruf von einzelnen Seiten bis zu 15 Sekunden bis die Inhalte angezeigt werden. Die Arbeit in der Admin-Area erfordert teilweise eine hohe persönliche Toleranzschwelle für Lade- und damit Wartezeiten. Das Ganze wohlgemerkt ohne installierte Zusatzmodule, d.h. im „Auslieferungszustand“.

Natürlich habe ich mich zu dem Thema auch schon in Foren umgesehen. Etwas gebracht hat die Heraufsetzung des PHP-Values memory_limit mittels .htaccess auf 512 MB. Aber insgesamt sind die Seiten doch recht behäbig unterwegs.

Ich würde ja auf einen gut versteckten Bug im Core tippen. Oder benötigt das System jetzt so viel Ressourcen, weil vielleicht an der Architektur grundlegend geschraubt wurde? Was sagen die Entwickler unter Euch? Ich bin Drupal-Einsteiger, Ihr habt die Erfahrung.

schmittrich

Ich würde eher auf einen schlecht konfigurierten Server tippen. Ich habe beispielsweise ein D7 System mit ner handvoll Contrib-Modulen auf einem popeligen vServer (ein 4.0 von Hosteurope mit 2 GB RAM, selbst aufgesetzt) mit wenig Last zusammen mit diversen anderen D6 und D5 Sites laufen und habe überhaupt kein Speed-Problem.
Die Startseite kommt eingeloggt (mit Admin-Menu) in etwas über 400-500ms bei mir an.

Habt ihr mal auf ein Standard-Theme umgeschaltet und die Performance verglichen?

Begründung: Ich habe verschiedene CMS-Systeme auf demselben Server laufen, darunter das Profi-CMS Weblication, Typo3, Contao, Joomla, Wordpress und ein selbstgestricktes. Drupal 7.7 ist mit Abstand das behäbigste, und das wie gesagt in der Basiskonfiguration, ohne Zusatzmodule, mit dem Bartik Theme im Frontend und Seven im Backend.

Erst mal noch mal Danke an Alexander für die Hilfe hier.

Wir konnten das Problem nun endgültig lösen. Es war, wie sollte es auch anders sein, ein fremdes Skript, genauer zur Anzeige eines TS-Servers. Dieses hat die Last regelmäßig auf Peeks um 100% gepusht. Interessant dabei ist, dass das Skript in einem Block mit PHP-Filter war, der Block aber nicht wirklich aktiv auf der HP eingebunden war. Irgendwas hat da aber nicht gepasst, schwer zu sagen was genau. Am Ende waren es wohl die ständigen Aktualierungsintervalle. Nun nutzen wir ein Skript, welches die Übersicht zeitweise cached, was deutlich besser geht. Außerdem liegt die Seite nun auf einem leistungsstarken dedicated Server.

Man lernt eben nie aus, gerade was solche Dinge anbelangt.

Danke noch mal für die große Hilfe!

Ja, solche Sachen sind nervig und mitunter schwierig zu debuggen. PHP in Blöcken ist eh bähh.. Es dauert vll.t 5 Minuten länger, aber eben ein eigenes Modul dafür zu klöppeln lohnt in Sachen Wartbarkeit meist schnell und man kann, wie ihr ja jetzt selbst erfahren habt, dort eben auch cachen.