Performance drop durch (etwas) hohe node Anzahl, timeout beim editieren, debugging?

Moin und herzlich willkommen,

ist php error logging auch eingeschaltet?

Im Terminal:

locate php.ini

dann als root

nano /pfad/zu/deiner/php.ini

die Zeile: display_errors = Off auf On setzen und weiter unten

;error_reporting = E_ALL entkommentieren.

Apache neu starten, den Fehler provozieren und mal in (oder wo auch immer die Logdatei bei dir liegt)

tail -f /var/log/apache2/error.log

reingucken. Da müsste der Grund für den letzen 500er zu finden sein.

Danke für die Antwort, als schlimmen Finger konnte ich gleich mal "drupal for firebug" ausmachen.

Nun kommt die Seite mit max_execution_time = 15 aus beim navigieren, wenn ich weiter runter gehe, bleibe ich in skripten bzgl. views oder bootstrap oder ... hängen. Die Gesamtladezeit ist nach wie vor einfach zu hoch, ich muss wohl noch weiter suchen.

Danke noch mal!

Hast du einen Slider drin?
Wann ist die Performance besonders schlecht?
Könnte das eine ungünstig formulierte View sein?
Sind die angezeigten Bilder ggf. nicht für die Anzeigegröße optimiert?
Läuft das Devel module mit?
Ist die Performance nur beim Admin schlecht, oder auch beim unregistrierten User?

Hi,

Slider ist nicht drin. Was drin ist ist eine Karte, die mit dem coordinates module pro node einen Punkt setzt, ABER das ist nicht das Problem. Es ist egal, ob ich eine Seite mit einer view gehe, bei der 10 teaser mit Bildern geladen werden und zusätzlich die genannte Karte mit 200+ Koordinaten, oder ob ich auf einen Detaileintrag einer Node gehe, bei der nur die eine Node geladen wird mit exakt einer view, die die Location auf der Karte zeigt. Die Dauer des Ladens bleibt auch genau so lang, wenn die Koordinate fehlt, also schließe ich die Karte hier mal als Problem aus ... wie sich das verhält, wenn es mehr als 10000 Koordinaten werden, ist ne andere Sache.

Es scheint, als wären view an und für sich eher langsam, aber die Startseite hat viele views, und die Ladezeit bleibt gleich lang. Ich habe mal in context Views an einigen Stellen rausgenommen, dann geht es merklich schneller. Aber die komplexität der view oder die Menge der Treffer scheinen nicht wirklich ausschlaggebend zu sein. Ich werde später noch mal mit meinem Kollegen telefonieren, was er mit cache settings und so gemacht hat, ich will da nicht in seiner Baustelle wildern, ohne zu wissen, was da genau ist.

Mal exakt und kurz:

Wann ist die Performance besonders schlecht - beim laden der Taxonomie Terme für eine Superfish Menu

Könnte das eine ungünstig formulierte View sein? - die view selbst scheint egal zu sein, habe verschiedene rausgenommen, reingenommen, ...

Sind die angezeigten Bilder ggf. nicht für die Anzeigegröße optimiert? - Bei 100% Skalierung mit einem Bild oder in Teasern mit 10 skalierten Bildern ist kein wirklicher Unterschied erkennbar. Da habe ich vielleicht noch Bedarf zur Optimierung, aber die am langsamsten ladende Seite hat keine Bilder ...

Läuft das Devel module mit? - Das habe ich noch nicht bedacht, habe jetzt mit und ohne getestet, wenn es einen Unterschied macht, ich erkenne keinen Unterschied

Ist die Performance nur beim Admin schlecht, oder auch beim unregistrierten User? - Bei beiden gleich.

Danke für die Ideen!

Vielleicht bin ich auch beim maximal Erreichbaren angekommen mit den Modulen, den views, der Anzahl an nodes, ... keine Ahnung. Ich werde nächste Woche mal sehen, wie es auf dem Produktivserver läuft, der ist ja dann doch deutlich performanter...

Für weitere Vorschläge bin ich natürlich weiterhin dankbar :)

Drupal ist schon sehr ressourcenhungring. Aus deinen Ausführungen würde ich schließen , dass es schlichtweg an der Konfiguration von Apache-mysql-php deiner Dev- Kiste liegt. Die Idee, die Installation mal auf einem (managed?) Liveserver zu testen, wird dir letztlich Aufschluss geben.

So ab 50 contrib- Modulen würde ich dir empfehlen, einen OpCode- Cache wie beispielsweise APC zu verwenden, damit der PHP Code nicht bei jedem Funktionsaufruf neu kompiliert werden muss. Dies bringt eine deutliche Performancesteigerung.

Der klassische Flaschenhals ist oft die DB, bzw. die Abfragen. Gerade wenn du viel mit Views ausgibst, ist der Einsatz eines memcached Servers äußerst sinnvoll. Der Performanceschub ist deutlich spürbar. Selbst im etwas trägen Drupal "Backend" erreichst du durch die Reduktion der Plattenzugriffe und query's Seitenaufrufe unterhalb 300ms.

Ok, dann werde ich das mal machen. Feedback kommt dann in paar Tagen.

Danke nochmal an alle, die geantwortet haben!