PHP Performance

Wer auf seiner Seite einen Login hat, verwaltet die Autentifizierung der User üblicherweise per Cookies oder Sessions. Letzteres ist dabei praktikabler, da Cookies deaktiviert werden können und Sessions dann immernoch über GET-Parameter an der URL die Autentifizierung gewährleisten. Wenn aber Sessions genutzt werden, werden die Daten der Session auch auf dem Server gespeichert. Wer hier nicht aufpasst, kann sich schnell seinen Server vollfrummeln. Deshalb gibt es in diesem Beitrag einige Tipps zur effektiven Verwaltung von Sessions. Weiterlesen >

Neben der reinen Programmierung kann vor allem die Konfiguration des Webservers und von PHP selbst eine bessere Performance bringen – vorausgesetzt man konfiguriert richtig. In diesem Beitrag möchte ich einige php.ini-Einstellungen vorstellen, die nur sehr selten nützlich sind und deshalb unnötig Speicher und Zeit schlucken. Weiterlesen >

Heute mal ein Beitrag, der nicht ganz so sehr auf Performance (aber auch) sondern auf Sicherheit abzielt. Ganz nebenbei hat das auch wirtschaftlich Sinn. Aus aktuellem Anlass bei einer meiner Seiten bin ich auf eine Idee gekommen, wie man URL-Manipulationen zwecks SQL-Injection effektiv verhindern kann. Getreu nach dem Motto "All incoming data is evil"… Weiterlesen >

Caching Technologien auf dem eigenen Server können eine Menge an Performance ausmachen. Solche Cache-Software wirbt mit teilweise über 400%iger Beschleunigung des Codes – was natürlich sehr attraktiv ist.
Und tatsächlich bringen diese Beschleuniger etwas. Weiterlesen >

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).