php.ini Performance Tuning

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.

register_globals = Off
Register_Globals ist ja glücklicherweise seit PHP 4.2.0 standardmäßig deaktiviert. Wenn diese Einstellung auf On steht, kann man auf alle superglobalen, assoziativen Arrayeinträge ($_POST, $_GET, $_REQUEST, $_SESSION, $_COOKIE, $_SERVER usw.) auch als Variable zugreifen. $_SERVER[‘PHP_SELF’] hat dann den gleichen Inhalt wie $PHP_SELF. Und gerade das ist ein Sicherheitsrisiko, wenn Variablen nicht ordnungsgemäß initialisiert werden. Deswegen sollte dieser Parameter immer auf Off stehen. Wenn eure eigenen oder Fremdscripte danach nicht mehr funktionieren, empfiehlt es sich, sie lieber umzuschreiben als register_globals auf On zu lassen!
Und ganz nebenbei frisst es natürlich Speicher, um jetzt mal wieder in die Performance-Richtung umzulenken, denn jeder Arrayeintrag muss in eine zusätzliche Variable geladen werden.

expose_php = Off
Diese Einstellung fügt – wenn sie auf On steht – jedem HTTP-Response einen Headereintrag hinzu, dass die Seite mit PHP erstellt wurde. Das ist unnötig, denn eure User interessiert das sowieso nicht. Es interessiert aber sehr wohl Hacker, denn je mehr die über die Infrastruktur einer Seite wissen, desto einfacher wird es. Und aus Performancesicht muss der hinzugefügte Headereintrag natürlich mit zum Client übertragen werden. Also besser auf Off stellen.

register_argc_argv = Off
Diese Einstellung ist nur nützlich, wenn man PHP über die Kommandozeile aufruft und dort Parameter mitgeben möchte (wie in C sind diese dann eben in argv und die Anzahl der Parameter in argc). Wer dies nicht tut, kann register_argc_argv getrost deaktivieren, da dann weniger Speicher belegt wird.

always_populate_raw_post_data = Off
Wenn diese Einstellung aktiviert ist, dann wird $HTTP_RAW_POST_DATA gefüllt. Ich habe das bisher nie benötigt. Man sollte aber mal bei den eigesetzten Fremdscripten schauen, ob die diese Variable einsetzen. WordPress tut dies beispielsweise, ist aber so schlau (weil es ja auf möglichst vielen Serverkonfigurationen laufen soll), sich nicht darauf zu verlassen, denn wenn always_populate_raw_post_data auf Off steht, kann man trotzdem den Input-Stream abfragen und hat dann die gleichen Daten:

if(!isset($HTTP_RAW_POST_DATA)) {
  $HTTP_RAW_POST_DATA = file_get_contents( 'php://input' );
}

Es sei hier kurz erwähnt, wie einfach uns PHP die Arbeit mit Streams macht, denn da kann man die einfach wie Dateien behandeln – toll, wenn man das mal mit Java vergleicht…
In Konsequenz kann always_populate_raw_post_data immer deaktiviert werden und lieber obiges Snippet mit eingebaut werden. Denn sonst zieht man mal den Server um o.Ä. und plötzlich geht nix mehr. Ist also auch eine zusätzliche Sicherheit.

Bitte stellt diese Einstellungen aber nicht einfach um und gut ist, sondern testet nach dem Umstellen euer Projekt und aktiviert am besten auch das PHP Error-Log und stellt Error-Reporting auf E_ALL, damit ihr seht, ob irgendwas schief läuft. Optimal wäre dafür natürlich ein eigener Entwicklungsserver – jedenfalls ist es nicht empfehlenswert, ohne Test die Einstellungen zu ändern.
Wenn noch jemand andere Kniffe in der php.ini (hinsichtlich Performance oder sicherheit) kennt, würde ich mich über Kommentare freuen.

Jan hat 152 Beiträge geschrieben

9 Kommentare zu “php.ini Performance Tuning

  1. SeeeD sagt:

    Interessanter Artikel, leider fehlt hier eine Angabe welchen Performancegewinn man dadurch hat.
    Ist dieser Spürbar oder eher vernachlässigbar?

    Weiß jemand vielleicht noch mehr Punkte die man editieren kann?
    Habe nie großartiges in der ini gemacht. Immer nur kleinigkeiten.

  2. Xandi sagt:

    Naja kommt immer auf die Größe der Seite an und die Belastung des Servers.. die meisten Kniffe dürften nicht 10% weniger belastung bringen – speziell so Sachen wie register_argc_argv.. aber kleinvieh macht auch mist.

  3. Jan sagt:

    Ganz genau. Diese Dinge sind nicht “spürbar” im Sinne dessen, dass die Webseite dann doppelt so schnell aufgerufen wird. Sie sind aber spürbar, wenn viele Leute gleichzeitig zugreifen. Zumal die meisten Tipps hier eher den Speicherverbrauch senken als die Geschwindigkeit zu erhöhen.

    Und: Selbst wenn die Änderungen den Speicherverbrauch nur um 1% senken würden, warum sollte man sie nicht durchführen? Denn der Arbeitsaufwand beträgt unter 5 Minuten, dafür ist mir jeder noch so kleine Performancegewinn recht.

  4. SeeeD sagt:

    Also es gab hier sehr viele Tips, welche die Performance beim Endanwender nach oben bringt 🙂
    Ich habe mir das aber auch gedacht, dass es sich hier um nicht Spürbare Werte handelt.
    Es spricht in dem Sinne aber auch nichts dagegen den Server zu entlasten und dadurch ein bisschen mehr Rechenleistung zuzuweisen. Arbeitsaufwand sind ja nicht mal annähernd 5 Minuten 😉

  5. Wishu sagt:

    Bei meinem Imagehoster hat es schon mal gut geklappt. Laut lori (Firefox Add-on) brauchte die Seite vorher 1,6-2,1 Sekunden. Nach den Optimierungen nur noch 1,0-1,4 Sekunden (Jeweils 10 Mal aktualisiert). Also es ist kein Monsterunterschied, aber doch schon ein gutes Stück. Wenn man die größte Spanne nimmt, kann man gut von mehr als doppelt so schnell sprechen.

    Gruß
    Wishu

Eine Antwort schreiben

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert mit *

You may use these HTML tags and attributes: <a href=""> <blockquote cite=""> <pre lang=""> <b> <strong> <i> <em>