Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Module › Modulsuche ›

Performance-Analyse und -Optimierung bei umfangreichem Moduleinsatz (>100 Module und mehr)

Eingetragen von Phil Ewert (69)
am 18.09.2008 - 14:41 Uhr in
  • Modulsuche

Hallo Leute,

wie einige von euch wissen, habe ich mir eine Liste der ca. 300 meistgenutzten und attraktivsten Dupal-Module zusammengestellt, um auf diese Art für meine Kunden umfangreichere und attraktivere Portale aufbauen zu können. Gleichzeitig möchte zu einer Erforschung umfangreicherer Drupal-Portale und zur Einschätzung und Lösung von Komplexitäts-Problemen beitragen.

Ich fürchte mich bei diesem Pionier-Vorhaben vor 2 möglichen Problemquellen :

a)Inkompatibilitäten zwischen zwei oder mehreren Modulen (, die nicht einfach zu diagnostizieren sind)
b)Performance-Einbußen durch die schiere Anwesenheit so vieler Module in einer Installation oder durch 'Performance Lecks' einzelner Module bzw. Modulkombinationen.

Einen Thread zu a) habe ich bereits eröffnet und werde mich hier mit b) beschäftigen.

Grundsätzlich ist ja Drupal von sich aus schon sehr performant. (Deutlich performanter als Typo3 und Joomla)

Darüberhinaus erlaubt es auch selbst noch weitgehendere Optimierung z.B. mitttels folgenden Modulen

- Vielfältige allgemeine Performance-Optimierung (mit dem 'boost'-Modul)
- Zusammenfassung der Javascript-Dateien, um eine einzige schnelle Übertragung zu ermöglichen (per 'javascript-aggregator'-Modul)
- Zusammenfassung der CSS-Dateien
- Throtteling (Kern-Modul) zum selektiven Abschalten, nicht zwingend benötigter Module.

Es sind auch viele händische programmier-technische Performance-Optimierungen möglich.

Schlußendlich läßt sich natürlich jedes Drupal-Portal beliebig(!!) skalieren mit Mitteln wie :

- Schnellere(r) Anschluß, HW, Server, Prozessor(en), Speicher, Festplatte etc.
- Aufspaltung in Funktionsserver wie : Proxyserver, Apache-Server, PHP-Script-Server, DB-Server, Such-, Multimedia-, Streaming- u.ä. Server
- Paralelle Server-Architekturen

Auf diese Weise ist dem Umfang und der Größe eines Drupal-Portals keine prinzipielle Schranke gesetzt, während natürlich Kosteneinschränkungen stets existieren können. Ich möchte nun in einem ersten Schritt in einer Multisite-Installation 2 ähnliche Seiten vergleichen, von denen die erste 50 Module hat und die zweite 150 Module haben soll. Eine erste Performance-Messung soll die Ladezeit-Messung per Firebug sein.

Nun zu meiner Frage b) also :

- Gibt es umfangreichere, genauere und systematischere Performance-Testmethoden?
- Welche Möglichkeiten gibt es, seine Seiten Lasttests oder Stresstests zu unterwerfen?

- Welche händischen Optimierungsmethoden kennt Ihr noch für Drupal

- Kennt Ihr Leute, die sich damit beschäftigt haben oder unfreiwillig Erfahrung sammelten ?
- Gibt es vlt. Erkenntnisse, die besagen, wieviel Performance ein Modul zieht, welsches bei einem Aufruf nicht aktiv wird ?
- Gibt es systematischeres Material zu diesem Fragenkreis irgendwo im Netz ?

Ich freue mich auf einen umfangreichen Erfahrungsaustausch.

Herzlichst,

Phil Ewert

‹ Video-Konferenzsystem Drupal als Verzeichnis? / PLZ-Suche ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

jmeter

Eingetragen von micha_1977@drup... (32)
am 18.09.2008 - 15:45 Uhr

für Last- und Stresstests bietet sich z.B. JMeter an (frei wie Freibier), nicht ganz einfach zu lernen, aber damit lassen sich - entsprechende Resourcen vorausgesetzt - auch mehrere 1000 parallele Lasttests starten

um dann Aussagen zu bestimmten Modulen treffen zu können, müßte man die PHP Scripte zeitgleich überwachen lassen um eben zu wissen ob Modul A oder Modul B das Zeitproblem verursacht
im Java Bereich käme dafür sowas wie Wily in Frage (kommerziell) im PHP Bereich habe ich in der Richtung noch nicht gearbeitet

  • Anmelden oder Registrieren um Kommentare zu schreiben

Prinzipiell kannst du mit

Eingetragen von Lim_Dul (9)
am 18.09.2008 - 16:41 Uhr

Prinzipiell kannst du mit einem PHP-Debugger, wie xdebug feststellen, welcher Code, wieviel Zeit verbraucht. Allerdings dürfte die Auswertung bei vielen Modulen alles andere als trivial sein.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Man muss zwischen Zwei

Eingetragen von dawehner (2639)
am 18.09.2008 - 18:46 Uhr

Man muss zwischen Zwei wichtigen Dingen unterscheiden:
Dabei braucht die Zeit für die Auslieferung der Webseite in der Regel einfach länger, als die Seite zu generieren, also kann man hier am meißten drehen.

Frontend-Performance
1. CSS Aggregation gibts schon seit D5
2. JS Aggregation gibts als Path für D5 und für D6 im Core

Backend-Performance
1. PHP Code im Arbeitsspeicher halten: http://en.wikipedia.org/wiki/Alternative_PHP_Cache#Xcache
->Bootstrap von Drupal braucht deutlich weniger Zeit
2. Datenbankcache
3. Anzahl an Modulen verringern: Man bedenke:! der User möchte nicht von den Anzahl sondern vom Einfallsreichtum der Funktionen erschlagen werden(ist zumindestens bei mir so)

Performancetest

time curl -s "http://mysite.org[1-1000]"

--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.deXING

  • Anmelden oder Registrieren um Kommentare zu schreiben

dereine schrieb 1. PHP Code

Eingetragen von Alexander Langer (3416)
am 18.09.2008 - 18:59 Uhr
dereine schrieb

1. PHP Code im Arbeitsspeicher halten: http://en.wikipedia.org/wiki/Alternative_PHP_Cache#Xcache

Da wird nichts groß "im Arbeitsspeicher gehalten", sondern der nach dem Parsen des PHP-Quellcodes erzeugte Bytecode wird zwischengespeichert (auf der Platte) und beim erneuten Aufruf (so das Skript zwischenzeitlicht nicht verändert wurde) wird das Parsen eingespart und direkt der Bytecode ausgeführt. Darum heißen die Dinger auch Bytecode Caches.

Im Arbeitsspeicher wird was gehalten, wenn man memcache einsetzt. Performancevorteile bringt dies in der Praxis aber auch nicht zwingend in signifikantem Ausmaß.

Es sind immer viele Faktoren, die zusammenkommen. Mal einfach in ne leere Installation 50 und 100 Module reinpacken und da was messen bringt auch nur für diesen speziellen Einzelfall ein Ergebnis, sagt aber nichts über die Performance von Produktivsystemen aus.

Es gilt die alte Weisheit: Wer misst misst Mist. ;-)

--
Webseiter

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • für drupal11 ein Slider Modul
  • [gelöst] W3CSS Paragraphs Views
  • Drupal 11 neu aufsetzen und Bereiche aus 10 importieren
  • Wie erlaubt man neuen Benutzern auf die Resetseite zugreifen zu dürfen.
  • [gelöst] Anzeigeformat Text mit Bild in einem Artikel, Drupal 11
  • Social Media Buttons um Insteragram erweitern
  • Nach Installation der neuesten D10-Version kein Zugriff auf Website
  • Composer nach Umzug
  • [gelöst] Taxonomie Begriffe zeigt nicht alle Nodes an
  • Drupal 11 + Experience Builder (Canvas) + Layout Builder
  • Welche KI verwendet ihr?
  • Update Manger läst sich nicht Installieren
Weiter

Neue Kommentare

  • melde mich mal wieder, da ich
    vor 2 Wochen 5 Tagen
  • Hey danke
    vor 2 Wochen 6 Tagen
  • Update: jetzt gibt's ein
    vor 3 Wochen 12 Stunden
  • Hallo, im Prinzip habe ich
    vor 3 Wochen 4 Tagen
  • Da scheint die Terminologie
    vor 3 Wochen 5 Tagen
  • Kannst doch auch alles direkt
    vor 4 Wochen 2 Tagen
  • In der entsprechenden View
    vor 4 Wochen 2 Tagen
  • Dazu müsstest Du vermutlich
    vor 4 Wochen 2 Tagen
  • gelöst
    vor 6 Wochen 5 Tagen
  • Ja natürlich. Dass ist etwas,
    vor 6 Wochen 6 Tagen

Statistik

Beiträge im Forum: 250233
Registrierte User: 20465

Neue User:

  • Znogsnernoimb
  • ByteScrapers
  • Mroppoofpaync

» Alle User anzeigen

User nach Punkten sortiert:
wla9461
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3924
ronald3857
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 0 User und 25 Gäste online.

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association