fyi: 63+ Tipps für Performance in PHP-Scripts

Das Kompilieren von PHP dauert ja im Vergleich zu den Datenbankabfragen gar nichts. Diese ganzen Tips sind ja wohl echt nicht so wichtig. Außerdem ist zB if-elseif etc ca 30% schneller als switch.

Bei einer durchschnittlichen if-Abzweigungen mit 10 verschiedenen Möglichkeiten dauern 1 Million Ausführungen max 0,2 Sekunden (natürlich vom Server abhängig). Könnt ja ausrechnen wie viel ihr durch solche Aktionen bei einem durchschnittlichen Projekt spart und wie viel Zeit ihr deswegen investieren müsst.
 
holzmensch hat gesagt.:
Das Kompilieren von PHP dauert ja im Vergleich zu den Datenbankabfragen gar nichts. Diese ganzen Tips sind ja wohl echt nicht so wichtig. Außerdem ist zB if-elseif etc ca 30% schneller als switch.

Bei einer durchschnittlichen if-Abzweigungen mit 10 verschiedenen Möglichkeiten dauern 1 Million Ausführungen max 0,2 Sekunden (natürlich vom Server abhängig). Könnt ja ausrechnen wie viel ihr durch solche Aktionen bei einem durchschnittlichen Projekt spart und wie viel Zeit ihr deswegen investieren müsst.
Zum Vergrößern anklicken....

Erstmal danke für die Gedanken, die du dir gemacht hast. Ich habe bereits ein paar der Punkte getestet und bislang sieht es tatsächlich danach aus, das man nicht wirklich sehr viel spart.

Was ich allerdings anmerken möchte zu deinem Kommentar mit dem Compile. Wenn der Vorgang sowieso immer der gleiche bleibt, wozu dann noch mal ausführen und nicht statt dessen das einmalige Ergebnis verwenden?

Was ich damit eigentlich erreichen wollte: Sensibilität für das Thema und evtl. mal bessere Tipps, als die bereits bekannten Urban-Legends. Was bringt wirklich Performance.

Ich habe da ein paar Punkte, die ich noch nirgends gesehen habe:

- PHP abspecken (nur die Extensions einbinden, die wirklich gebraucht werden)
=> geringerer Speicherverbraucht
=> kürzerer Startup im PHP-Lifecycle
- Verwenden von Unix-Sockets statt TCP/IP bei der Verbindung zur DB
- Verwenden von Kompression beim Zugriff auf externe Ressourcen
=> Bringt das was? Was ist mit dem Overhead?
 
Zu dem Kommentar:
habe nicht ganz verstanden was du damit sagen wolltest.

Zu den anderen Sachen:
Ich weiß ja nicht was man so für PHP Scripte hat und ob man damit die Welt berechnen will. PHP ist auf keinen Fall der Flaschenhals außer man macht irgendwelchen wirklich codetechnsichen Fehler wie eine for-Schleife über die Anzahl eines Arrays ohne die Anzahl vorher in einer Variablen abzuspeichern oder multiple Datenbankabfragen für mehrere IDs und nicht alles in einer Abfrage.

Alles andere ist Quatsch! Vielleicht ein kleiner Denkanstoß:
Wir nehmen an das PHP-Script wird 10 Sekunden lang ausgeführt, wenn man das jetzt wie in dem Artikel beschrieben optimiert, kommt man vielleicht auf 7 Sekunden oä. Das lohnt sich überhaupt nicht, wenn man von 10s auf Millisekunden reduzieren könnte, ok. Ich meine wenn das Script eine Stunde lang ausgeführt wird, dann ist PHP auf jedenfall das Falsche für den Zweck.
 
holzmensch hat gesagt.:
Alles andere ist Quatsch! Vielleicht ein kleiner Denkanstoß:
Wir nehmen an das PHP-Script wird 10 Sekunden lang ausgeführt, wenn man das jetzt wie in dem Artikel beschrieben optimiert, kommt man vielleicht auf 7 Sekunden oä. Das lohnt sich überhaupt nicht, wenn man von 10s auf Millisekunden reduzieren könnte, ok. Ich meine wenn das Script eine Stunde lang ausgeführt wird, dann ist PHP auf jedenfall das Falsche für den Zweck.
Zum Vergrößern anklicken....
Na, von 10 auf 7 Sekunden ist es schon ordentlich!
Auch wenn der Nutzer es nicht sieht (Cronjob), spart es Serverleistung und man verhindert, dass irgendwann später hinzugefügte Teile nicht erneut Zeit draufpacken.
 
Naja, war vielleicht ein schlechtes Beispiel dafür was ich sagen wollte. Diese 10 Sekunden würden dann durch irgendwelche Datenbankabfragen und externe Zugriffe akkumuliert werden. Das rationales PHP-Script, dass nur Berechnungen oä hat und so lange dauert, will ich sehen - wie gesagt, rational! ;)
 
Ich hatte mal eins mit 5 Sekunden, welches HTML von einer anderen Seite geparst (diese hatte keine API) und in die Datenbank eingefügt hat.
Da hat z.B. das [phpf]unset[/phpf] eines sehr großen Arrays eine große Zeitverminderung erbracht!
 
Wie ich schon sagte Datenbankverbindungen und externe Zugriffe akkumulieren den Großteil. Außerdem verliert man bei solchen Geschichten die Performance eher an die Parselogik (welchen Algorithmus man benutzt etc) anstatt an Sachen wie if vs. switch. Hast du das Script noch, kannst du den mal profilen? Würde mich persönlich interessieren, was da denn tatsächlich 5s gedauert hat.

Nicht dass man mich falsch versteht: es ist aufjedenfall empfehlenswert gleich performant zu programmieren, es macht aber ökonomisch überhaupt keinen Sinn seine Zeit in sowas zu investieren, wenn es anders schneller geht und man ggf 1ms verliert. Dabei sollte die Wartbarkeit und Übersicht in Betracht gezogen werden.

Habe letztens an einem Script mit einer SOAP Schnittstelle gearbeitet. Der Zugriff auf diese dauerte >98%, Rest war meine PHP-Logik mit Objekten und Vererbung etc (1500 Zeilen).
 
holzmensch hat gesagt.:
Zu dem Kommentar:
habe nicht ganz verstanden was du damit sagen wolltest.
Zum Vergrößern anklicken....

Du hast geschrieben, dass das Kompilieren der PHP-Scripts ein Klacks im Gegensatz zu Datenbank-Abfragen ist. Womit du absolut Recht hast (in den meisten Fällen wird das so sein).

Dennoch muss man einer Maschine nicht mehr zumuten als nötig. Um den Compile-Vorgang zu übergehen, gibt es Opcode-Caches. Mehr wollte ich damit eigentlich nicht sagen.

holzmensch hat gesagt.:
Zu den anderen Sachen:
Ich weiß ja nicht was man so für PHP Scripte hat und ob man damit die Welt berechnen will. PHP ist auf keinen Fall der Flaschenhals außer man macht irgendwelchen wirklich codetechnsichen Fehler wie eine for-Schleife über die Anzahl eines Arrays ohne die Anzahl vorher in einer Variablen abzuspeichern oder multiple Datenbankabfragen für mehrere IDs und nicht alles in einer Abfrage.
Zum Vergrößern anklicken....

Absolut! Und genau das möchte ich für die Nachwelt festhalten. Nicht jeder weiß, das man konstante Werte als Abbruchbedingung einer for-Schleife verwenden sollte. Und nicht jeder hat eine Idee, das man mehrere Id's gleichzeitig an die DB senden kann, um die Ergebnisse in einem Rutsch abzuholen (danke übrigens für diese Idee, wird auf die Liste genommen).

Mir geht es also darum, ein Kompendium zu basteln, aus dem sich jeder das rausholen kann, was er noch nicht weiß.


holzmensch hat gesagt.:
Habe letztens an einem Script mit einer SOAP Schnittstelle gearbeitet. Der Zugriff auf diese dauerte >98%, Rest war meine PHP-Logik mit Objekten und Vererbung etc (1500 Zeilen).
Zum Vergrößern anklicken....

Und auch hier gibt es Optimierungsmöglichkeiten (Proxy, anderes Transport-Protokoll, etc. pp). Genau diese Dinge sind es, die mich interessieren.
 
Zuletzt bearbeitet:
"Und auch hier gibt es Optimierungsmöglichkeiten (Proxy, anderes Transport-Protokoll, etc. pp). Genau diese Dinge sind es, die mich interessieren. "

Das sind auch die Optimeirungen, die wirklich interessant sind 8wie ich ebreits erwähnte). Aber ob sich das eine generelle Liste zusammenfassen lässt? Für DB-Abfragen gibts ja schon sowas in der Art.
 
Ich denke diese Effekte sind sehr von dem zu optimirenden Projekt abhängig, allerdings gibt es einige wirklich interessante Optimierungsansätze für PHP. Ich weiß zwar nicht in wie weit diese Praktikabel sind aber sowohl folgender Vorschlag: "If you have very time consuming functions in your code, consider writing them as C extensions" als auch der Ansatz von Facebook PHP in C++ zu übersetzen (https://github.com/facebook/hiphop-php)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück