PHP Performance steigern

Hallo Thomas,

was hast du denn bisher versucht? Mit fallen sonst auch nur die üblichen Verdächtigen ein:

• Sauberes Programmieren


• Datenbankabfragen optimieren


• Datenbank-Caching


• Objekt-Caching


• View based caching


• Bytecode-Cache


• magic-Methods vermeiden


• include_path optimieren


• absolute statt relative Pfade


• autoloading statt require_once / include_once

Und bitte: Finger weg von Mikrooptimierungen

-Stricte Gleicheit etc. verwenden
-Strings bei mehrmaliger Verwendung zusammenfasse ( $test = \'bar\'.$foo.\'bar\')
-Sparsamm mit Arrays umgehen

Versucht und nutzen tu ich vieles.
Mit dem Bytecode Cache meinst du APC oder?

Was ich euren Aufzählungen noch hinzufüge würde wäre:

• Bit-Operation bevorzugen


• Schnelles Filesystem (wenn möglich)


• Effektive Datentypen


• Speicherschonend Arbeiten


• Sinnvolles einsetzten von Schleifen


• Effektive Aufgabenverteilung (Im Vergleich zu PHP sind Datenbank dafür gemacht Datensätze zu verwalten / sortieren / filtern)

Richtig gut fand ich das Kompilieren von Klassen. Im Vergleich zu einfachen include Anweisungen sind sie bis zu ~44% schneller. Nur Unterstützt das kein Hosting Paket da braucht man schon einen eigenen Server mit vollem Root zugriff.


Und wie gesagt, ich suche nach wie vor nach weiteren effektiven Möglichkeiten.

Ultima schrieb:
Mit dem Bytecode Cache meinst du APC oder?

Ja es gibt neben dem APC noch ein paar andere wie den eAccelerator, ein großer Unterschied ist das nicht (der APC bringt allerdings auch einen user-Cache mit).

Was ich euren Aufzählungen noch hinzufüge würde wäre:

Ultima schrieb:
Bit-Operation bevorzugen

Von Bit-Operatoren würde ich i.d.R. abraten. Das ist eine Mikro-Ooptimierung, deren Effekt sich zumeist in nicht merkbaren Bereichen abspielt, während der Code gleichzeitig schwieriger zu lesen und damit schwieriger zu warten wird.

Ultima schrieb:
Effektive Datentypen

Was sind für dich effektive Datentypen und wo liegt ihr Vorteil?

Ultima schrieb:
Richtig gut fand ich das Kompilieren von Klassen. Im Vergleich zu einfachen include Anweisungen sind sie bis zu ~44% schneller. Nur Unterstützt das kein Hosting Paket da braucht man schon einen eigenen Server mit vollem Root zugriff.

Kompilierte Klassen in PHP? Hast du da einen Link?

UFOMelkor schrieb:
Von Bit-Operatoren würde ich i.d.R. abraten. Das ist eine Mikro-Ooptimierung, deren Effekt sich zumeist in nicht merkbaren Bereichen abspielt, während der Code gleichzeitig schwieriger zu lesen und damit schwieriger zu warten wird.

Mal ein Beispiel, hier ein Prüfung auf gerade oder ungerade Zahl.
for ($n=0;$n<120;$n+=1) {
if($n%2==0) echo \'gearde\';
else echo \'ungearde\';
}
Nun mit Bit Operatoren:
for ($n=0;$n<120;$n++) {
if($n&1) echo \'ungearde\';
else echo \'gearde\';
}
Der Rechenaufwand beim ersten Beispiel ist im Vergleich zum 2. wesentlich höher und bei entsprechenden Einsatz auch spürbar. Und das mit der Lesbarkeit ist schon richtig aber irgendwo auch eine Sache der Gewohnheit.

UFOMelkor schrieb:
Was sind für dich effektive Datentypen und wo liegt ihr Vorteil?

PHP erkennt die Datentypen weitgehend automatisch, ich sehe es aber oft das Zahlen als Zeichenketten angelegt werden. Und vor jeder Rechenoperation ein Typecast ist schon überflüssig. Effektiv war vielleicht etwas falsch Formuliert.

UFOMelkor schrieb:
Kompilierte Klassen in PHP? Hast du da einen Link?

Klar

de3.php.net/manual/de/book.bcompiler.php

Da PHP ja recht häufig im Verbindung mit MySQL verwendet wird, will ich hier mal auf die Möglichkeiten hinweisen, das sich einige Berechnungen direkt mit MySQL im Query durchführen lassen.

Man muss sich nicht erst die DB-Werte holen, um sie mit PHP weiter zu verarbeiten, es geht auch direkt in der Abfrage an die Datenbank.

Da steckt enormes Performance-Potential drin, und es ist nicht besonders schwer, mit MySQL-Funktionen und Left/Right-Joins, einiges an Code und Prozessorlast einzusparen.

Mehr dazu gibt es hier:

dev.mysql.com/doc/refman/5.1/de/functions.html

Das sieht ja hier schon richtig gut aus.

Matthias, ich stimme dir völlig zu. Die Datenbanken müssen ordentliche Querys abgefragt werden.
Wer mit Joins nicht so gut klar kommt kann bereits mit einer bestimmten Abfrage von DB Spalten enorm punkten. So mancher speichert ne 1:1 kopie des Tables in einem object.

Statt
SELECT * FROM bigtable
besser
SELECT a.id, a.title
...diese Bauart mit Joins und alles ist gut.
Mit so Kleinigkeiten holt man eine Menge Performance aus dem System, ohne sich endlos zu verbasteln(kosteneffizient).

Hin und wieder sollte man den Profiler über den Code laden. Schnell sind "ich dreh mich doof und 3 mal im Kreis"- Funktionen ermittelt.

gelegentlich "static" verwenden hilft.

..ich denke so laufen die Php-Anwendungen rund.

die grössten Zeitfresser sind die Responses, die machen ca. die Hälfte eines Zyklus aus!!

Danke für eure Hinweise, aber es geht mir nur um PHP.

Statische Klassen/Variablen verstopfen den Speicher da sie grundsätzlich geladen werden und überall sichtbar sind. Von daher sollte man den Einsatz nach Möglichkeit vermeiden.

Ultima schrieb:
for ($n=0;$n<120;$n+=1) {
if($n%2==0) echo \'gearde\';
else echo \'ungearde\';
}
Nun mit Bit Operatoren:
for ($n=0;$n<120;$n++) {
if($n&1) echo \'ungearde\';
else echo \'gerade\';
}

Gegen das $n++ hätte ich nichts, das stört meinen Lesefluss nicht. Wenn mir aber jemand ein $n&1 vorlegen würde ...
Die Sache ist die: Solange man nicht gerade 5 Millionen solcher Operationen hat, wirkt es sich nicht merkbar aus.

Ultima schrieb:

Klar

de3.php.net/manual/de/book.bcompiler.php

Hab das jetzt nur kurz überflogen, aber macht die Erweiterung nicht im Grunde das gleiche wie APC & co?

romacron schrieb:
gelegentlich "static" verwenden hilft.

Ultima schrieb:
Statische Klassen/Variablen verstopfen den Speicher da sie grundsätzlich geladen werden und überall sichtbar sind. Von daher sollte man den Einsatz nach Möglichkeit vermeiden.

AFAIK sind statische Methoden sind tatsächlich ungefähr 4 mal so schnell wie nicht statische Methoden (auf verschiedenen Seiten gelesen, nicht überprüft).
Allerdings untergraben sie die OOP:

Robert C. Martin, Clean Code schrieb:
Im Allgemeinen sollten Sie nicht-statische Methoden den statischen vorziehen. Im Zweifelsfall sollten Sie eine Funktion als nicht-statisch deklarieren. Wenn eine Funktion wirklich statisch sein soll, sollten Sie dafür sorgen, dass sie sich bei keiner Gelegenheit polymorph verhalten soll.

romacron schrieb:

Hin und wieder sollte man den Profiler über den Code laden. Schnell sind "ich dreh mich doof und 3 mal im Kreis"- Funktionen ermittelt.

Das möchte ich nochmal hervorheben. Die xdebug extension eignet sich hier sehr gut.

Ansonsten fehlt noch das optimieren von Bedingungen:

if (slowCondition() || fastCondition()) {
//vermeiden
}

if (fastCondition() || slowCondition()) {
//bevorzugen
}


UFOMelkor schrieb:
Hab das jetzt nur kurz überflogen, aber macht die Erweiterung nicht im Grunde das gleiche wie APC & co?

Im Prinzip schon, nur packt APC alle Bytecodes (Datei) in den gemeinsamen Cache plus die User Variablen. Der BCompiler wandelt dir die Klassen Definitionen direkt in Bytecode um und speichert sie im FS, die man dann wieder inkludieren kann.

APC soll ja dem PHP6 Core hinzugefügt werden, von daher ist es wohl sinnvoller sich mit APC auseinander zu setzten. PHP6 ist ja schon zu ~70% fertig gestellt (wenn ich mich nicht verlesen habe).

Schöne Grüße
Thomas


PS: Ich bin mir sicher das Heiko & Matthias auch noch ein paar gute Tipps auf Lager haben. :schwein: