Feststellen wo sich in der Drupal-Installation Flaschenhälse beim Laden befinden

Meinst du explizit Ladezeit (browserseitig) oder Seitengenerierungszeit (serverseitig)?
Ladezeiten der Seite kommen natürlich durch Anzahl, Göße und Art der geladenen Ressourcen zustande. Wenn du zig Bilder, Javascripts und womöglich noch lauter externe Ressourcen (Youtube Videos, Icons von externen Servern, externe JavaScripts, dutzende Gravatar-Bilder, ...), wirds natürlich nicht schneller. Hier ggf. Leistungseinstellungen in Drupal anschauen, JS- und CSS-Dateien aggregieren lassen, css_gzip und javascript_aggregator einsetzen.

Bzgl. Seitengenerierung ist das Devel-Modu die erste Anlaufstelle. Damit kannst du erstmal feststellen wieviel Zeit das Skript in der Datenbank verbringt und wieviele im PHP Interpreter.

Ist die Datenbank der Flaschenhals muss man mal die Auflistung der Querys im Devel-Modul aktivieren und in der nach Dauer sortierten Ausgabe mal schauen ob es ggf. nur wenige sehr langsame Abfragen sind. Ggf. kann aber die Anbindung oder Auslastung eines dedizierten DB-Servers beim Hoster ein Problem sein.

Wenn der PHP Interpreter die deutlich meiste Zeit (und deiner Meinung nach zuviel) verbraucht checken, ob ein PHP Opcode Cache serverseitig aktiv ist, wie etwa APC oder phpaccelerator (ersterer ist zu bevorzugen). Dann gilt der Blick auch dem Hosting Environment, sprich was für ein Hosting Plan liegt vor und ist damit ggf. gar nicht viel mehr auszurichten? APC & Co. bringen hier mitunter nicht viel, wenn die Skripte von hunderten Kunden auf einem Server sich gegenseitig dauernd aus dem Cache kicken.

Danke Alexander für die ausführliche Antwort. Mir wurde im Drupal.de IRC-Chat xDebug und kCacheGrind empfohlen. Damit könnte man genau sehen woher ein Skript aufgerufen wird, wie oft und wie lange es zu Laden braucht. Scheinbar ist die Installation etwas fummelig (auch hier unter Mac). Hast du die beiden Programme mal ausprobiert?

Hi,

Cachegrinder und XDebug sind die Tools fürs Profiling, kann ich nur empfehlen.
Allerdings liegt die Performance nicht an PHP selbst sondern meistens an der Datenbank.

Meine Erfahrung ist folgende:
Drupal nimmt zwar viel Arbeit ab, doch für hoch performante Anwendungen
sollte man die Datenbank Programmierung wo es geht selbst in die Hand nehmen.
Drupal selbst verwaltet die Datenbank nämlich alles andere als optimal.
Was verständlich ist, da Drupal mit den meisten Datenbanken läuft.
So kennt Drupal selbst Indexe, Referenzielle Integrität, etc..

Zum Beispiel
CCK erleichtert die Programmierung verlangsamt aber die Ausführzeit um min. das vierfache (Habe ich getestet).
Das löschen von Refrenzen könnte man ohne Programmierung über ein Cascading DELETE machen (MYSQL InnoDB)
Vergleicht man man das mit einem SELECT und foreach DELETE wie es in Drupal gemacht wird wird schnell klar
was man da sparen könnte.

Mit Cachegrinder und Xdebug gewinnst Du auf jedenfall einen sehr tiefen Einblick (sehr empfehlenswert).

LG

Hi,

also ich habe nun XDebug und Webcachegrind (= da plattformunabhängig; unter Mac ist KCacheGrind ein Krampf und KDE-Software allgemein nicht gerade ein Garant für Zuverlässigkeit) installiert.

Mein erster Eindruck:
- XDebug macht die einfachen Dump-Ausgaben von PHP schöner. Ist zudem Vorraussetzung für die Erstellung der Cachegrind-Dateien.
- Webcachegrind gibt mir eine lesbare Auflistung der Prozesse, die bei den letzten Seitenaufrufen, auf meinem lokalen Server, ausgeführt wurden. Für meine Zwecke besonders hilfreich ist das erstmal nicht. Denn die Funktionen aus meinen eigenen Modulen brauchen um die 0,1% der Ausführungszeit. Mit über 630 Abfragen pro Aufruf ist das PHP eigene MySQLi-Modul das am stärksten genutzte Segment meiner Website.

Somit hat das Webflo schon gut erkannt. Doch nutze ich auf meiner Website zu 90% Fremdmodule. Daraufhin wäre es dumm, da jetzt den Core anzupacken und alles auf Abfragen auszulagern, die nicht in Drupal drin sind. Zudem wäre dies _super_ viel Arbeit.

Ist es nicht einfach die beste Lösung, Programme wie Memcache zu verwenden, die einfach die allgemeine Website abdecken bzw. den Server aufrüsten, alsdass man sich jetzt die Sysiphusarbeit mit dem Code antut?

-j

Hi jepster,

war ja meine Rede dass das meiste an den schlecht Programmierten
Datenzugriffen liegt.
Du musst natürlich in XDebug auch die Breakpoints an den richtigen Stellen
machen und sehen was Drupal genau macht.
Ich hatte Fälle wo jemand 40 Fremdmodule Installiert hat für eine Sache die
ich mit EINEM (OK etwas komplexerem ) JOIN Statement über meherere Tabellen mache.

Ich würde dann in solchen Fällen auch von APC und Memcache nicht allzuviel erwarten.
Denn schlecht (oder gar nicht) Programmierte Datenzugriffe bleiben schlecht Programmiert.
Die meisten Leute schwören den Himmel auf APC und Memcache sowie V? (cached SQL Statements)
vergessen aber dass wenn Sie das testen Ihre Zugriffe sowieso immer im Cache sind.

Mit XDebug kannst Du jedenfalls sehr genau sehen ob Dinge überhaupt Sinn machen.
Allein mit Deiner Beschreibung (extensiv MYSQLi) nehme ich schon an dass von dieser Site auch CCK Typen extensiv
genutzt werden ;-)

Das mit dem 630 Zugriffen auf MYSQLi sollte doch mit XDEBUG und Cachegrinder genauer gehen.
Ist jetzt nur hypotethisch (weiss ja nicht was die Seite alles anzeigt und wie Sie aussieht)
aber reicht da nicht die hälfte?
Du könntest z.B: gewisse Module einfach disablen und nur in den Templates laden
in denen Sie benötigt werden.

LG

PS:
Ich habe mich schon unbeliebt gemacht mit solchen Statements was die performance betrifft
also sei vorsichtig ;-)

Die bloße Anzahl von DB Zugriffen ist für sich genommen uninteressant. Interessant sind die langsamen unter ihnen, aber auch nur wenn sie einen großen Anteil an der Ausführungszeit der Statements hat und auch nur dann, wenn diese Gesamtzeit für die benötigte Zielperformance zu hoch ist.

Das wichtige bei der Optimierung ist zu wissen, wo es sich wirklich lohnt. Auf einer Seite mit 1000 SQL Abfragen 500 wegzuoptimieren, die zusammen nur 10% der gesamten Abfragezeit ausmachen ist im Kosten-Nutzen-Verhältnis gesehen deutlich ineffektiver als die handvoll Statements einzusparen oder zu optimieren, die den Großteil der Abfragezeit ausmachen. Wenn dann noch die Gesamtausführungszeiten so aussehen, dass ein mehrfaches der Abfragezeit noch für die PHP-Ausführung draufgeht, minimiert sich der Nutzen seitens der DB-Optimierung nochmals deutlich.

Wer also keine Zeit / kein Geld zu verschenken hat analysiert genau um dann ganz zielgerichtet Optimierungen vorzunehmen.

@Alexander
Sehr gut gesagt und 100% richtig.

Was mir im Moment noch einfällt wäre folgendes:
MYSQL hat defaultmässig 100 concurent connections eingestellt.

Wenn Du das noch nicht gemächt hat könntest Du die Anzahl der gleichzitigen Verbindungen auf z.B: 1260 erhöhen.
So könnten 2 User die Seite gleichzeitig aufrufen ohne das MYSQL warten muss bis Verbindungen wieder frei werden.
Probier das einmal aus.
Es wäre auch für mich interessant zu wissen ob und was es für Dich bringt.

Wie kommst du denn jetzt auf 1260? Pro User Request kannst du grob eine Verbindung rechnen. Für 1260 gleichzeitig geöffnete Connections brauchst du auch nen Server mit gigantisch RAM.

Hi Alexander,
ja da hast Du schon wieder recht.
Sorry, da war ich etwas schnell mit meiner Antwort.

Was ihm vermutlich etwas bringen wird ist diese MYSQL Einstellung:

LG

Vermutungen sind immer so eine Sache. Einfach mal das MySQL Tuning Primer Skript auf die Karre packen und nach wenigstens 24 Stunden Laufzeit des MySQL-Deamons die Ausgabe des Skripts auf Optimierungsmöglichkeiten der MySQL-Konfiguration hin untersuchen.

Hi,
na ohne das System zu kennen kannst Du nur vermuten.
Ich wollte eigentlich darauf hinaus, dass auch
an Systemgrenzen die durch das OS geben
optimiert werden können.
z.B: Anzahl an Descriptoren per User oder Anzahl der Threads
die ein User anstossen kann.
Diese Boundaries können natürlich auch einen Einfluss
auf MYSQL haben.

Ändert nix daran dass mein letztrer Beitrag total falsch war ;-)

LG

Klar, ändern kann und sollte man ggf. Dazu muss man aber erstmal schauen wie im Betrieb die Eckdaten überhaupt ausschauen und muss sich dann mit einem Taschenrechner daran begeben die Konfigs der diversen Dienste, vornehmlich Apache, MySQL und PHP Opcode Cache durchzukonfigurieren. Das geht nur im Rahmen der durch die Hardware zur Verfügung stehenden Ressourcen (CPU Cores, RAM). Beacht ich die nicht, jage ich mir die Karre ggf. in die ewigen Jagdgründe der Swap-Partition.

@ Alexander Langer:
Wie gehst du denn bei der Optimierung des Codes konkret vor? Damit lässt du uns etwas im Schwammigen (Eckdaten, Konfigs, Taschenrechner). Du benutzt also das Skript von https://launchpad.net/mysql-tuning-primer und stellst damit fest, dass Drupal selber ziemlich langsam ist und rückst an den Core ran, oder wie? Denn wenn meine eigenen Module Drupal nicht verlangsamen, führt über die Programmierung dort der Weg hin. Oder schaust du dir stundenlang Configs an und beschliesst dann, den Server von der Hardwareseite her einfach aufzurüsten? :-)

Hi nochmal.

Kann es sein das wir die ursprüngliche Anfrage
besser beantwortet haben als er es eigentlich wollte ;-)?

Nach nochmaligem überlegen meine ich, er sollte die
MYSQL MAX Conntections doch höher setzten als die Default 100.
Im MYSQL Forum das ich gelesen habe, steht auch dass das sehr wenig ist.

Grund:
Alexander hat zwar absolut Recht dass in Drupal ein User normalerweise
nur eine connection offen haben sollte.
Doch wenn eines seiner zig Fremdmodule einen db_connect macht
Oder eins Seiner Module macht die DB Connection selber (keine Drupal db Funktion).
Das ist nicht unwarscheinlich und ich habe das schon öfter gesehen.

Dann sieht es schon so aus ein User 2 Verbindungen offen hat.
Das bedeutet widerum, dass bei 50 gleichzeitigen Zugriffen diese Ressourcen schon erschöpft sind.
Bei 5 Verbindungen können nur noch 20 gleichzeitige Verbindungen stattfinden, usw.

LG

Hast du schon das Devel modul ausprobiert? Könnte dir ggf. auch weiterhelfen.

@jepster

Also den Core umprogramiieren weil einige Module
langsam sind ist wohl etwas vorbeigeschossen.

Wäre es nicht besser die Module die langsam laufen zu optimieren
oder gar durch bessere zu ersetzen.

Manche Module kannst Du nicht einach ersetzen.
Aber Du kannst überlegen ob Du nicht evtl.
selbst etwas Programierst wofür Du sonst zig Fremdmodule benötigst.

Ein konkretes Beispiel:
Du willst einen Node um ein Feld (Oder meherere) erweitern.
a)
Du kannst nun die 5 CCK Module benutzen
b)
Oder Du kannst selber ein Modul machen dass die Felder über NodeAPI
anfügt.

Du hast meine Garantie dass durch Version b) dieser Node (bei nur einem Feld) min. 4x schneller geladen wird.
Ich habe das getestet mit genau einem Feld.
Bei meheren Felder ist Variante b) noch viel schneller.

LG

5 CCK Module - meinst du damit einfach CCK Felder oder eigenständige Module, die CCK Felder mit etwas Funktionalität bringen?

Mit dem MySQL Tuning Primer kann ich lediglich erkennen wie welche Parameter in MySQL gesetzt sind und wie sich diese zur Laufzeit verhalten haben. Das hat mit Drupal und irgendwelchem PHP Code nichts zu tun. Wie im Einzelnen vorzugehen ist ist fallspezifisch. Da müsste ich hier jetzt einen rieisigen Entscheidungsbaum reinzeichnen, der alle möglichen Fälle abdeckt ;)

Ohne ein gutes Monitoring (z.B. via Munin auf alle wichtigen Services wie Apache, MySQL, CPU, RAM, ..), Laufzeitinfos von der Shell, aus MySQL, aus Drupal und technischen Daten des Servers kommt man früher oder später an die Grenzen einer jeden Glaskugel.

Ich hatte erst letzte Woche jemanden dessen System ich mir anschauen sollte, weil es im Backend unerträglich langsam geworden war. Das Devel-Modul hatte er schon angeworfen und fragte mich immer und immer wieder wie er die Anzahl von Datenbankabfragen (je nach Seite im vierstelligen Bereich) verringern könne. Ein Klick mehr in der Devel-Konfig förderte zutage, dass >1000 Querys in 600ms abliefen, aber im PHP Skript zwischen 3 und über 40 Sekunden verbracht wurden. Ich kam also nicht umhin immer und immerwieder zu betonen, dass die Datenbankabfragen hier nicht das Problem waren.

Wozu sollte er das tun? Wenn ich nichts überlesen habe, ist es eine unbestätigte Annahme von dir, dass sein Max. auf 100 eingestellt ist (Default-Werte unterscheiden sich auch zwischen div. Distributionen, Hostern, ..). Hinzu kommt, dass ich mich nicht entsinne, dass er schrieb, dass sein Server irgendwann mit einer Fehlermeldung ausgestiegen sei, nach der zu viele Verbindungen offen seien.

Er fragte nach Möglichkeiten die Performance zu verbessern, bzw. Bottlenecks zu finden, Max. Connections sind aber zunächst einmal "erst" relevant bei Fragen der Skalierung.

Der (noch) aktuelle Server vom Drupal-Center hat auch "nur" 80 Max. Connections, bei im Tagesdurchnitt 400 DB-Abfragen pro Sekunde. Die erreicht er ausnahmslos aber nur wenn nachts das Backup läuft und dieses die Maschine einfach zu sehr in den Keller zieht, um parallel noch alle Anfragen (um die Zeit hauptsächlich durch Bots) abarbeiten zu können. Im Normalbetrieb reichen die 80 hier dicke aus, obwohl hier der Anteil eingeloggter User recht hoch ist.

@Alexander

Natürlich ist das eine Annahme.
Die Annahme bezieht sich darauf dass es MYSQL Default ist.
Also wenn nix eingestellt ist oder er den Server selber compiliert hat
ist max_connections 100.

Hier bei Drupal.de (ja ist eine vermutung) kann es ja durchaus sein
dass ein User genau eine Verbindung offen hat.
Bei ihm wäre das allerdings auch nur eine Vermutung.

Dieser Fehler würde erst nach einem Timeout auftreten und nicht sofort.
Das heisst er mysql_connect wartet bis zum timeout bevor die Meldung too many connections
auftritt.
Ich betone WARTET (TCP Layer).

Sonst müsste hier diese Fehlermeldungen schon auftreten.
Ich schätze auch hier, dass durchaus gleichzeitg 80 user mal eine Seite
laden.
Immerhin es dieses Forum ja gut besucht!
Das der Fehler nicht auftritt liegt daran dass eine Verbindung wieder frei wird
bevor der Timeout ausgelöst wird.

Wie gesagt ist nur eine Vermutung (Muss ich das jetzt immer dazu schreiben?)!

LG

Also das ist auch nichtssagend:

1000 Queries in 600 ms.
Was wurde denn da gemessen?
Oder haben die 1000 Queries keine Daten zurückgeliefert?

Relevant wäre hier eher die Datenmenge die nach einem Query
aufbereitet werden muss.

Dass das PHP Skript die meiste Zeit braucht ist ja wohl auch logisch.
Ausserdem buffert Drupal ja die Ausgabe bis alles vorhanden ist
was gerendert werdewn muss.

Dafür brauche ich kein Devel

LG

Ms steht für Millisekunden und sofern ich in Physik richtig aufgepasst habe, ist das eine Einheit der Zeit. ;)

Da gebe ich dir Recht, allerdings lässt sich diese indirekt über die Ausführungszeiten der einzelnen Queries ebenso ablesen. Abfragen die große Resultsets liefern brauchen oft auch länger. Hierbei geht es ja zunächst einmal um eine grobe Einschätzung ob ich mit unnötigen oder unoptimierten Abfragen (bzw. Abfragen über unoptimierte Strukturen) die Zeit verschwende und die mir die Performance runterziehen.

Ich kann auch mit wenig Daten in schlechtem PHP Code Ewigkeiten verbringen ;)

Im Normalfall ja, aber im Normalfall mus sich auch nicht auf die Jagd nach Performancefressern gehen, weil im Normalfall alles ordentlich läuft ;)

Es braucht aber nur etwa viele Daten, schlechtes Schema, gruseliges SQL, vermurkste MySQL Konfig (ich sah schon 1und1-Root-Server die standardmäßig keinen Query-Cache aktiviert hatten), problematische Modul-Kombinationen (OG + Forum + zus. Access-Module), ext. DB-Server, ... und wirf noch ein paar Hände voll eingeloggter User mit in den Mix und schon überwiegt die Zeit die in der DB verbracht wird die im PHP Interpreter bei weitem.

Hi Alx
die Diskussion ist sehr interessant, darum nehme ich daran Teil.

BTW:
Es ist auch bei langen Queries und grossen Datenmengen logisch,
dass das Skript selbst ungebuffert länger braucht.

Beispiel (Ich hatte so einen Fall 1997 für eine Versicherung.):
Eine HTML Tabelle mit 100.000 TR's im Browser zu rendern.
Man musste damals mehr als 5 min. vor dem (nicht mehr reagierenden) Browser warten
bis er anfing zu rendern, dann dauerte es nochmal 2-3 min. unter rattern der Maschine bis
die Tabelle fertig gerendert wurde.

Ich habe damals feststgestellt dass der Browser erst anfängt zu rendern wenn er auf den /TABLE Tag trifft.
Machst Du das gleiche ohne Table rendert der Browser die Daten sofort beim eintreffen.

Man musste damals mehr als 5 min. vor dem (nicht mehr reagierenden) Browser warten
bis er anfing zu rendern, dann dauerte es nochmal 2 min. unter rattern der Maschine bis
die Tabelle fertig gerendert wurde.

Der Browser hatte zwischen den TABLES immer Zeit zu reagieren und er hat sofort
angefangen die Daten darzustellen (Keine Wartezeit).

Das war in diesem Fall nur Klientseitg.
Ein PHP Skript muss ähnlich geparst und Interpretiert werden.
- start php tag
- DB abfrage und ausgabe
- end php tag

LG

Wie du selbst schon sagst ist das eine client-, also browserseitige Geschichte, nämlich wie genau eine Rendering-Engine Daten verarbeitet und wie man mit diesem Hintergrundwissen umzugehen hat. Das sollte ein Themer im Grunde auch wissen.

Das spielt in den Bereich der wahrgenommenen Performance mit rein, wogegen wir bisher rein von serverseitiger Performance gesprochen haben. Hierzu gibt es mit Firebug, Yahoo YSlow bzw. Google Page Speed (Erweiterungen für Firebug) entsprechende browserbasierte Tools zur näheren Betrachtung.

Insgesamt umfasst die Performance einer Web-App Zusammenhänge aus einer ganzen Reihe von Technologien sowie serverseitig, als auch clientseitig und seitens von Basistechnologien / Infrastruktur / Services (Netzwerktechnik, DNS, ...).

Ein PHP Skript wird zunächst in Gänze (mit allen Includes) geladen, geparst und auf korrekte Syntax untersucht, in Opcode gewandelt und dieser wird dann ausgeführt. Hier gibt es keine Zwischenschritte in der irgendwelche im Code liegenden Anweisungen ausgeführt werden (Includes / Requires ausgenommen, die analog wie in C einfach nur eine Art Suchen / Ersetzen des Quelltext der entsprechenden Datei bewirken).

Ein Opcode Cache wie APC, xcache & Co. kann hier beschleunigend eingreifen, indem er den generierten Opcode vorhält und beim nächsten Aufruf desselben Skripts das Parsing und die Syntax-Prüfung einspart.

@Alexander
Hi,

ich konnte das mit PHP Skript und Interpeter nicht mehr fertig ausführen,
weil ich weg musste.

Nein, so einfach ist das nicht:

Stell dir ein PHP Skript vor
mit allen Includes , Tags, Funktionsaufrufen.
In diesem Beispiel sind es 3 Tags.

Welcher Tag ist zuerst fertig abgearbeitet?
Ich meine jetzt ohne Buffering.
Die Funktionsaufrufe können wieder eigene
Prozesse oder Threads anstossen.

Meine damit:
Die Ausführzeit eines PHP Skripts zu messen
sagt wenig.
Man kann damit nicht wirklich sagen was langsam ist
und schon gar nicht welcher Teil zuerst abgearbeitet ist.

Gute Lösung für dieses Problem (Habe das mal mit ASP gemacht):
Du machst einen timstamp in jedem PHP starttag.
Du machst einen timstamp in jedem PHP endtag.

Die Differenz gibt die ausführzeit des Tags in ms (Eine Zeiteinheit glaube ich ;-)
So kannst Du bestimmen in welchem TAG du optimieren solltest/musst.

LG

@jepster

Also nach nun 3x überlgen habe ich entschieden,
dass Du wenn Deine max_connection in MySQL
<100 ist das auf 1000 erhöhen solltest.

Der Grund ist der, dass bei Drupal.de es ja sein
kann dass
1. jeder user nur eine connection bekommt (Sollte in Drupal ja so sein)
Bei Dir kann ich es nicht sagen.

2.Das das Ressourcenverschwendung wäre oder der Sever mehr RAM
braucht sehe ich nicht. Diese Einstellung hat die Grösse int.

3. Du so auf jedenfall auschliessen kannst das eine Verbindung
erst frei werden muss wenn sich ein User verbinden möchte.

Also zu verlieren hast Du da bei zu hoher Einstellung nix

LG

PS: Sorry baer Dein Problem wird das auch nicht wirklich lösen :-(

Deinen gute Willen in allen Ehren, aber deine Tipps sind unbrauchbar, irreführend, sachlich falsch, ...

Ein PHP Skript wird von oben nach unten entsprechend der Ausführungslogik abgearbeitet, so wie jedes andere Programm auch. Multithreading gibt es in PHP nicht, lediglich Prozesse können über die PCNTL Erweiterung kontrolliert werden. Diese ist aber per default nicht einkompiliert / deaktiviert und benötigt zudem zwingend ein Unix-System. Die Betrachtung eines solchen esoterischen Falls können wir uns in Drupal (das auch auf Windows Servern läuft) daher getrost sparen.

Bzgl. des MySQL Connection Limits:
Klar ist die Angabe der Anzahl in der Konfiguration bloß eine Ganzzahl. Die Anzahl der Autos die ich besitze ist auch eine Ganzzahl. Wenn ich aber statt 1 Auto 100 Auto besitze, brauche ich nicht nur zwei Zeichen mehr tippen, ich brauche auch einen ganzen Arsch mehr an Stellplätzen / Garagen / Carports, Versicherungen, Cash, etc.

Bei MySQL ist es nicht anders. Jede Connection braucht Speicher für diverse Puffer. Man kann hier nicht einfach irgendwas eintragen, ohne zu schauen wie der tatsächliche Bedarf ist und welche Ressourcen (RAM) man überhaupt zur Verfügung hat. Zu jeder DB Connection gehört schlussendlich auch ein Webserver-Prozess. Auch der braucht RAM... Gib deinen Diensten mehr RAM als du hast und wenn der Bedarf da ist, wird die Karre anfangen zu swappen und ist dann in Minutenschnelle unerreichbar auf allen Diensten. Wenn du aber gut und richtig rechnest, bekommen die User die "zu viel" sind wenigstens noch eine Fehlermeldung zu sehen und geben dir den dezenten Hinweis, dass es Not tut zu optimieren / aufzurüsten.

Literaturhinweise:
- http://www.php.net/manual/de/intro.pcntl.php
- http://blog.theplanet.com/2010/07/19/audit-your-mysql-memory-usage/
- Google

Hi,

danke für die lebendige Diskussion hier.

@ Hyp1: bei der clientseitigen Abarbeitungszeit der Tabellendarstellung hast du mit Sicherheit Recht. Ich merke hier (ohne es zu messen) zudem, dass es kürzer dauert, eine valide HTML-Tabelle aufzubauen als eine, wo der Browser tolerieren muss. Und gerade Javascript bringt Browser oft in die Knie. Weshalb ich 10 Mal versuche, etwas mit CSS, HTML und PHP umzusetzen, alsdass ich Javascript einbaue (auch mit Frameworks).

@ Alex: Danke für die ganze Theorie. Diese hat mit Sicherheit ihre Berechtigung und mag für deinen Anwendungsfall und den Bedarf deiner Kunden interessant sein, doch würde ich definitiv erstmal zu einem schnelleren Server greifen, wenn es auf meiner Website zu lahm wird. Klar würde ich mir auch die Cachegrind-Dateien anschauen. Aber bestehende Module nachprogrammieren, würde ich wohl kaum. Oft ist es eben günstiger Computer arbeiten zu lassen. Wobei ich auch offen gestehen muss, dass ich mich bisher mit Clustern und enormen Lasten, wie es diese in umfangreichen Foren gibt, noch nicht praktisch auseinander gesetzt habe. Das würde ich dann auch von der Praxisseite tun - Probieren geht über Studieren. :-)

Dagegen ist nichts einzuwenden. Ich sehe persönlich auch keinen Sinn darin zu versuchen ein System zu Tode zu analysieren und umzukrempeln um aus irgendeinem kleinen Hostingpaket, vServer oder ollem Rootie noch ein paar Wochen oder Monate Daseinsberechtigung rauszuquetschen.

Wenn für den Dienstleister oder Kunden absehbar ist, dass Aufwand und Nutzen in keinem guten Verhältnis stehen und ein signifikantes Systemupgrade vergleichsweise günstig zu haben ist, dann ist dies die einfachere Alternative und dazu wird dann auch geraten. Dienstleistung zu erbringen heißt dem Kunden einen möglichst guten Dienst zu leisten und nicht ihm möglichst hohe Rechnungen für Beratungstätigkeit unterzujubeln ;)

Nichts desto Trotz sollte man sich ggf. jemanden mit Ahnung schnappen, der mal drüberschaut. O.g. Kunde der letzte Woche anfragte hatte - nachdem seine Seite mal vor einigen Wochen in die Knie ging - auch kurzerhand auf Verdacht aufgerüstet. Viel hilft aber eben nicht immer viel und schneller geworden ist in dem vorliegenden Fall durch ein Upgrade des vServers nichts.

@jepster

Wir reden da über C und wenn Du das Beispiel mit
den Autos nimmt, da get es um Platz für 100 Autos
und nicht um die Autos selbst.

Hier wird nur eine int berechnet und kein Speicher alloziert (memset oder malloc)!

Ich schätze mal der MYSQL Server ist clever genug geschrieben
dass er den Speicher für Buffer dann alloziert wenn er benötigt wird und nicht
beim starten des Servers.

Wenn Du ein C Programm schreibst, allozierst Du
den ganzen Speicher der evtl. vom Programm benötigt wird beim initialisieren?
Eigentlich sollte da nur der Speicher für die Varaiblen/Pointer reserviert werden.
Das ist bei max_connections immer noch eine int!

Auch das durch ein PHP Skript nicht mehrere Prozesse angestossen
werden können ist ja wohl ein Witz.
Was glaubst Du was die exec Funktion macht?
mail_send o.Ä.
Auch viele extensions stossen neue Prozesse an und können gethreaded sein.

Lebenszyklus eines PHP Skripts:

Eigentlich lassen sich diese Dinge ganz einfach testen:

Zu keiner DB Connection gehört auch ein Webserver Prozess.
Schalte den Webserver Prozess ab und mach über PHP eine Verbindung zur Datenbank.

In der Threadliste sehen wieviel Speicher der MYSQL Server braucht.
- Prozess stoppen.
- max_connections nach oben
- Prozess starten
- nochmal nachsehen.

Das mit den PHP Tags und Tmestamps habe ich schon gesagt.

LG

@Alexander
Noch ein Wort zum MYSQL Server, seinen
Buffern und Buffergrössen.
Würde der MYSQL Server den Speicher für seine
Buffer statisch reservieren und nicht dynamisch
wären die Binaries wohl etwas grösser,
meinst Du nicht? ;-)

Upps, der vorige Beitrtag war nicht an jepster gerichtet sondern an Alexander

LG

Sorry,
aber ein bisschen Zynismus konnte
ich mir jetzt nicht mehr verkeifen.

Es spielt keine Rolle ob MySQL die Ressourcen beim Start oder bei Bedarf benötigt (bei den Connections ist Letzteres der Fall). Der Punkt ist, dass sie vorhanden sein müssen. Wenn ich Max Connections auf 1000 setze muss ich auch dafür Sorge tragen dass der Server die Ressourcen hat überhaupt 1000 Connections zeitgleich offen halten zu können. Sonst kann ichs auch gleich auf 1 Million per default setzen und muss mich nie mehr um etwas kümmern.
Du rätst aber einem Admin einfach mal eine Stellschraube zu betätigen ohne aber irgendwelche erforderlichen Eckdaten des Systems zu kennen und riskierst damit im Fall der Fälle dessen Stillstand. Noch dazu gab es überhaupt keine Infos bzgl. des "Verbrauchs" von MySQL Connections auf dem System des Betreffenden. Du rätst einfach ins Blaue und ohne Rücksicht auf Verluste.
Die Größe der Binarys hat übrigens auch nicht das geringste mit Laufzeitbuffern zu tun. Mein Auto hat auch nicht ab Werk allen jemals benötigten Sprit an Bord.

Exec() in PHP ist nicht wirklich eine Prozesssteuerungsfunktion (nach dem Start kannst du nichts mehr steuern), ist bei vielen Hostern gesperrt, ist systemabhängig, wird in Drupal nicht genutzt und spielt somit ebenfalls keine Rolle in der hiesigen Betrachtung.

Und natürlich gehört zu einer MySQL Connection auch ein Webserver-Prozess, denn wir (also der Thread-Ersteller und ich, bei dir bin ich mir nicht sicher) sprechen von Flaschenhälsen in Zusammenhang mit einer Drupal-Anwendung und die läuft nunmal über einen Webserver.

P.S.:
Die Default-Werte seitens MySQL AB für max_connections betragen übrigens 100 bis v5.1.14, seither 151. Das Maximum liegt bei v5.1.15 bei 16384 und dananch bei 100000. Standardwerte in den Paketen der diversen Distributionen weichen hiervon gerne ab.

Hab ich was verpasst?

Dem ersteller ging es darum die Flaschenhälse zu finden
sowie die Geschwindigkeit zu optimieren.

Kennst Du sein System besser?
(Ich meine, dass es bei 1000 statt 100 Connections abstürzt)

Sorry, aber zur Suche des Flaschenhalses finde ich
den Tipp mit den PHP Tags sehr konstruktiv!

LG

@Alexander

Erst wenn der Tank auch wirklich leer ist,
schiebst Du Dein Auto zur Tankestelle ;-)

LG

Hmm..

also ich muss nochmals betonen, dass ich wohl der Praktikertyp in Sachen Drupal bin. Mir geht die Diskussion zu sehr ins Theoretische und hat kaum mehr einen Nutzen, der sich in der tatsächlichen Umsetzung wiederspiegeln würde. Wobei die Unterhaltung auch in einen Streit ausufert und mehr verunsichert als weiterbildet. Jetzt wird hier auch bei der Sprache C ins Detail gegangen. Verzeiht bitte, aber nach einigen Unterhaltungen mit hochtrabenden Informatik-Studenten, die tatsächlich kaum eine simple fehlerfreie Website erstellen konnten, bin ich bezgl. allzu tiefgreifender Theorie mit Skepsis geimpft. Wenigstens konnte ich mir im Zuge der Diskussion XDebug und die Cachegrind-Dateien näher ansehen, die anhand von konkreten Zahlen Aufschlussreiches vermitteln _können_.

Nochmals danke für Eure Nerven und die Zeit.

- j