Archiv für April, 2007

IPC 2012 Spring Edition

Prozesskonfiguration

Eine der wichtigsten Einstellungen des Servers und vor allem auch ein dynamischer Prozess ist die Konfiguration des MPM-Preworkers.

Einleitend sollte man sich die Apache 2 Dokumentation zu diesem Thema genau durchlesen, hier ein Auszug:

Ein einzelner Steuerprozess (der Elternprozess) ist für den Start der Kindprozesse verantwortlich. Jeder Kindprozess erstellt eine feste Anzahl von Server-Threads, wie durch die ThreadsPerChild- Direktive angegeben, sowie einen "Listener-Thread", der auf Verbindungen wartet und diese an einen Server-Thread zur Bearbeitung weiterreicht, sobald sie eintreffen.

Der Apache versucht immer, einen Vorrat von freien oder unbeschäftigten Threads zu verwalten, die zur Bedienung hereinkommender Anfragen bereit stehen. Auf diese Weise brauchen Clients nicht auf die Erstellung eines neuen Threads oder Prozesses zu warten, bevor ihre Anfrage bedient werden kann.

Die Anzahl der Prozesse, die anfangs gestartet wird, wird mit der Direktive StartServers festgelegt. Dann, während des Betriebes, berechnet der Apache die Gesamtzahl der unbeschäftigten Threads und forkt oder beendet Prozesse, um diese Anzahl innerhalb der durch MinSpareThreads und MaxSpareThreads angegebenen Grenzen zu halten. Da dieser Prozess sehr selbstregulierend ist, ist es nur selten notwendig, die Voreinstellung dieser Direktiven zu ändern.

Die maximale Anzahl Clients, die gleichzeitig bedient werden kann (d.h. die maximale Gesamtzahl der Threads in allen Prozessen), wird mit der Direktive MaxClients festgelegt. Die maximale Anzahl der aktiven Kindprozesse ergibt sich aus MaxClients dividiert durch ThreadsPerChild.

Zwei Direktiven legen harte Limits für die Anzahl der aktiven Kindprozesse fest und können nur geändert werden, indem der Server komplett gestoppt und dann wieder neu gestartet wird. ServerLimit stellt die obere Grenze für die Anzahl der aktiven Kindprozesse dar und muss größer oder gleich dem Quotienten aus MaxClients und ThreadsPerChild sein.
ThreadLimit ist die obere Grenze für die Anzahl der Server-Threads und muss größer oder gleich ThreadsPerChild sein. Sofern für diese Direktiven keine Voreinstellungen verwendet werden, sollten sie vor allen anderen worker-Direktiven platziert werden.

Was soll uns das nun sagen? Nun, mithilfe der folgenden Ausführungen wird es hoffentlich klarer und hilft beim Optimieren der Prozess-Einstellungen.
Ich erkläre es an einem Beispiel:
ThreadLimit 60
ServerLimit 30
StartServers 2
MaxClients 1800
MinSpareThreads 30
MaxSpareThreads 60
ThreadsPerChild 60

Mit dieser Konfigurationen können 1800 Anfragen gleichzeitig bedient werden. Es werden beim Hochfahren 2 Apache-Instanzen gestartet, von denen jeder mindestens 30 und maximal 60 Kinder haben kann. Jeder Kindprozess kann maximal 60 Threads erstellen, wobei jeder Thread 60 Clients verwalten kann.
Die Rechnung der Gesamtkapazität ist 30*60 = 1800.

Teilen Sie demzufolge soviele Threads und Childs ein, wie Sie benötigen, dazu muss später bei größeren Clients auch das ServerLimit erhöht werden. Dieses gibt an wieviele Apache-Server maximal gestartet werden koennen (hier 30).

Schlagwörter: , , , ,

httpd.conf Performance Einstellungen

Einige der wichtigsten Einstellungen in Bezug auf Server-Performance (Apache) ist die Datei httpd.conf. In dieser Datei sind sämtliche Parameter einzustellen, die über die Art und Weise der Verarbeitung von Anfragen (Requests) entscheiden. Weiterlesen >

Schlagwörter: , ,

Eine SQL-Abfrage nicht mehrmals abfragen

Manchmal kommt es vor, dass man eine bestimmte SQL-Abfrage bzw. das Ergebnis dieser innerhalb eines Scripts mehrmals benötigt. Ein ResultSet kann allerdings nur einmal durchlaufen werden. Man müsste deshalb die gleiche Query weiter unten im Script noch einmal abfragen. Aber da diese Daten ja bereits geholt worden, ist eine solche Abfrage eigentlich eine Verschwendung von Performance. WIe gehts aber besser? Weiterlesen >

Schlagwörter: , , ,

Apache-Installation optimieren und selbst übersetzen

Es ist zwar recht einfach, sich eine fertige Binary vom Apache Server herunterzuladen oder sogar gleich XAMPP herunterzuladen, doch wie so oft, ist der einfache Weg nicht unbedingt der beste. Die Binary-Distributionen sind stets so ausgelegt, dass sie mit möglichst vielen Systemkonfigurationen funktionieren. Und Kompatibilität bedeutet, dass auf die besonderen Fähigkeiten ihres Server-Systems keine Rücksicht genommen werden kann. Deshalb sollte man bei größeren Projekten darauf achten, dass man den Source Code selbst übersetzt. Weiterlesen >

Schlagwörter: , , , ,

Funktionen oder iterative Programmierung?

Wie in allen Programmiersprachen, die Funktionen unterstützen, gilt auch in PHP, dass man keine Codeblöcke einfach von einem Script in ein anderes kopieren sollte. Ich höre Stimmen: "Aber ich brauche diesen Block doch in beiden Scripten".
Meine Antwort: "Richtig, dagegen ist auch nichts einzuwenden. Aber du brauchst den Code nicht 2 mal."

Dieser Dialog zielt darauf ab, dass es Funktionen gibt und diese sollte man auch nutzen – und am besten effektiv nutzen. Leider gibt es nämlich auch das Gegenteil zu den in diesem Artikel beschriebenen Entwicklern: solche, die fast vollständig ohne Funktionen auskommen und lieber iterativ von der ersten bis zur letzten Zeile vorgehen. Was ist nun besser? Weiterlesen >

Schlagwörter: , , , ,

Nicht mehr includen als nötig

Wenn man häufig genutzte Funktionen in eine extra Datei auslagert, die dann einfach per include() oder require() in alle anderen Scripte der Seite eingebunden werden kann, ist das eine feine Sache. Es gibt allerdings ein Problem mit einer solchen Include-Datei: Meistens werden für bestimmte PHP-Scripte nur einige Funktionen benötigt und nicht alle, die in der Funktionsdatei stehen. Weiterlesen >

Schlagwörter: , , ,