Zur Navigation

PHP Skript-Geschwindigkeit optimieren

1 C)-(iLL@

Hallo liebe Leute,

ich bin gerade dabei mir den Kopf zu zerbrechen, wie ich meine Skripte auf eine bessere Geschwindigkeit bringen kann. Ein Artikel, den ich hier gelesen habe, enthält viele Tips, aber so wirklich glücklich werde ich nicht. Da ist z.B. die Rede von Cache-Methoden, doch diese scheinen mir für mein Vorhaben ungeeignet. Auch will ich nicht anfangen, Pear-Klassen einzubinden, denn ich hab mein eigenes Repository.

Mir geht es darum, ein OOP-System mit verknüpften Objekten zu optimieren. Momentan läuft es so ab, dass die Instanzen der Objekte in der Session gespeichert werden und beim Erzeugen der Session per Referenz an die Konstruktor-Methoden der Objekte übergeben werden (sie werden also per Referenz auf einer Objektvariable gespeichert).

Beispiel:

require_once 'class.foo.php';
require_once 'class.bar.php';

session_start();
if (!isset($_SESSION['session_id']) || $_SESSION['session_id'] != session_id()) {
  $_SESSION['foo'] = new Foo();
  $foo =& $_SESSION['foo'];
  $_SESSION['bar'] = new Bar(& $foo);
  $bar =& $_SESSION['bar'];
  $_SESSION['session_id'] = session_id();
} else {
  $foo =& $_SESSION['foo'];
  $bar =& $_SESSION['bar'];
  $bar->init(); //irgendwelche Initialisierungen
}

class.bar.php:

class Bar {
  var $foo; //link auf Foo
  function Bar(& $foo) {
    $this->foo =& $foo;  
    $this->init();  
  }
  
  function init() {
     //Initialisierungen
  }
}

Gibt es an einem solchen System etwas auszusetzen? Ich meine, ist es dumm $foo auf dem Objekt $bar zu behalten?

Welche Optimierungsmethoden benutzt Ihr sonst so?

Für Anregungen, Ideen und alles dankbar,
Rudy

09.03.2006 16:14 | geändert: 09.03.2006 16:15

3 C)-(iLL@

ließe sich da vielleicht ein Benchmark erstellen?
Das ist ja das diabolische - ich habe manchmal zwischendurch 2-3 Sekunden Lags beim Laden, aber der Benchmark zeigt 0,0x bis 0,2x Sekunden an.

Ich weiß einfach nicht woran es liegt, ich bin alles durchgegangen. Die Links werde ich mir ansehen, danke.

btw. habe ich die References in den Konstruktoren rausgenommen und durch global Deklarationen ersetzt - das hat auch schon etwas gebracht (glaube ich jedenfalls).

ich arbeite zwar schon lange mit PHP OOP aber das Projekt ist bisher nie so groß geworden wie jetzt (>20 Session Classes, zahlreiche Konstantendateien, alles aus DB...) - da zählt jede gesparte ms.

Edit: Danke, ich hab mir die Seiten durchgeschaut. Der erste Link sind Kindersachen :) aber beim 2. habe ich interessantes entdeckt:
Zitat von blog.antikoerperchen.de

Wenn man die Normalisierung übertreibt, erzielt man aber einen negativen Effekt auf die Geschwindigkeit. Bei der Normalisierung sollte man also einen Kompromiss eingehen; eine gewisse Redundanz ist akzeptabel.
Na ja, irgendwie fühle ich mich da etwas betroffen, ich werd mal versuchen, Tabellen, die oft aufgerufen werden (z.B. die URLs) etwas redundanter zu gestalten, um einen Join zu verhindern.
Zitat von blog.antikoerperchen.de
mysql_unbuffered_query führt dazu – wie es der Name vermuten lässt – dazu, dass die SQL-Abfragen nicht zwischengespeichert werden. Das spart zum einen Speicher (insbesondere bei langen Ergebnissen), zum anderen kann man die Ergebnisse direkt in PHP weiterverarbeiten, während die Abfrage eigentlich noch läuft. Andernfalls muss man warten, bis MySQL die Query abgeschlossen hat.
Das ließe sich auch noch an der ein- oder anderen Stelle einsetzen. Hoffen wir das Beste ;)

09.03.2006 22:33 | geändert: 09.03.2006 23:09

4 Jörg

Na ja, irgendwie fühle ich mich da etwas betroffen, ich werd mal versuchen, Tabellen, die oft aufgerufen werden (z.B. die URLs) etwas redundanter zu gestalten, um einen Join zu verhindern.

Ja, solche Redundanzen, die JOINs vermeiden, können dann gut für die Performance sein, wenn es wesentlich mehr SELECT als INSERT und UPDATE Queries gibt, d.h. man optimiert die Geschwindigkeit der Lesezugriffe auf Kosten der Geschwindigkeit bei Änderungen, die aber seltener vorkommen

10.03.2006 11:27

5 C)-(iLL@

man optimiert die Geschwindigkeit der Lesezugriffe auf Kosten der Geschwindigkeit bei Änderungen, die aber seltener vorkommen
Ja, der Punkt ist, dass die URLs mehrsprachig sind, d.h. aus der URL kann die Sprache ermittelt werden. Dementsprechend gibt es eine Tabelle mit den mehrsprachigen URL-Teilen, und eine Tabelle mit den damit verknüpften Daten. Die verknüpften Daten sind 1:n mit den URL-Teilen. Ich könnte das dahingehend gestalten, dass statt den zwei Tabellen eine redundantere Tabelle geschrieben wird. Dieser Select-Zugriff erfolgt nämlich bei jedem Seitenaufruf, sofern die URL sich ändert.

Vielen Dank inzwischen.

10.03.2006 12:00

6 C)-(iLL@

Ich hab den Übeltäter gefunden - es waren tatsächlich die URLs. Der Primary Key bestand aus 3 Feldern, beim Select wurde gejoint und von der Haupttabelle nur auf 2 der Primary-Key Felder eingegrenzt. Ich habe beide Tabellen zu einer zusammengefasst und siehe da - keine Lags mehr. Toll, Danke - mir fällt ein Stein vom Herzen!

Edit / PS: Das von mir angesprochene Linken der Objekte hat keine merkbaren Auswirkungen auf die Geschwindigkeit gezeigt - nachdem der 'böse' Join weg war, laufen beide Versionen gleich gut. Da mir das erste System gefällt, weil nicht ständig 'global'-Deklarationen gemacht werden müssen, behalte ich das bei. Nur zur Info :)

10.03.2006 16:50 | geändert: 10.03.2006 17:03

Beitrag schreiben (als Gast)

Beim Verfassen des Beitrages bitte die Forenregeln beachten.





[BBCode-Hilfe]