Hi,
Zitat:
Was mich wirklich interessiert, wie du an die ganzen Objekte und Module kommst?
Muss ich die alle manuell zuweisen ?Oder doch automatisch, wenn beim Scriptstart das Singletion gestartet wird (irgendwie unvorstellbar)?
|
Die Methode des Benchmarks basiert darauf, dass der Page-Controller implizit für den Benutzer bereits sehr viele Messpunkte aufnimmt, auf die du als Entwickler nicht achten musst. Man könnte also fast(!) von Aspektorientierung sprechen. Du siehst quasi sowohl den Aufbau des Objektbaums bis zum ersten
::transform() als auch das eigentliche Rendering genau so wie es hirarchisch auch passiert. Sprich ist die Schachtelung noch tiefer, wird das auch in der Ausgabe der Benchmark-Punkte berücksichtigt.
Dabei nutze ich die Klasse
benchmarkTimer als Singleton und starte/stoppe verschiedene Messpunkte wann immer ich es möchte. Den Bencharker rufe ich dabei so auf:
PHP-Code:
$bench = &Singleton::getInstance('benchmarkTimer');
$bench->start('Messpunkt A');
...
$bench->stop('Messpunkt A');
Ist am Ende der Seite (üblicherweise der index.php, wenn mit Bootstrapping gearbeitet wird) eine Ausgabe der Form
PHP-Code:
$bench = &Singleton::getInstance('benchmarkTimer');
echo $bench->createReport();
enthalten, wird der Report wir du ihn gesehen hast angezeigt. Die Einbindung des Benchmarkers erfolgt dabei für dich automatisch vom Page-Controller, der diesen initialisiert und später Messpunkte deiner Komponenten selbständig aufnimmt. Hört sich nach Magic an, ist es aber an sich garnicht. Die Magie ergibt sich eigentlich durch die Funktion des Page-Controllers, der aus deinen Templates einen Objekt-Baum aufbaut und den du im Benchmarker auch durch die Einrückungen sehen kannst.
Zitat:
|
In der Produktion lasse ich mir atm alle queries loggen, die länger als 10 Sekunden dauern. Und das ist mir zu wenig Info, da will und muss ich an der Ablaufverfolgung arbeiten.
|
Dann solltest du schnellstens eine sinnvolle Benchmark-Komponente einbauen, die du auch im Betrieb nutzen kannst.
Zitat:
Und was mich dabei wirklich brennend interessiert:
Entfernt ihr alle Debug- Ausgaben für das Produktiv- System oder laßt ihr die im quelltext stehen und arbeitet dann mit der Unterscheidung Produktions-/Entwicklungsumgebung?
Im 2. Falle würden mich Erfahrungswerte interessieren, inwieweit die Latenz der Seite durch Debugging/Logging unnütz leidet. Der Unterschied sollte doch marginal sein oder irre ich mich da?
|
Das APF selbst besitzt keine Unterscheidung zwischen DEV und LIVE, d.h. der Benchmarker ist immer integriert. Debugging sollte definitiv nur auf DEV-Umgebungen laufen, daher ist es IMHO ratsam "externe" Debugger wie NetBeans + xdebug zu nutzen. Alles andere würde deine Performance erheblich in den Keller ziehen. Hier ist insbesondere xdebug nicht ganz unschuldig dran, denn zu Debug-Zwecken müssen sehr viele Informationen gesammelt werden.
Was den Benchmark angeht, so kann ich nur sagen, dass das APF trotz "dauerhaft" integriertem Benchmarker trotzdem schneller als der Rest der Welt ist (siehe
Yii vs. APF :: Adventure PHP Framework (APF)).
Wenn du nun den Benchmarker bedingt einbaust, etwa so:
PHP-Code:
if(isset($_REQUEST['benchmarkreport']) && $_REQUEST['benchmarkreport'] == 'true'){
$bench = &Singleton::getInstance('benchmarkTimer');
echo $bench->createReport();
}
kannst du das auch im Live-Betrieb aktiviert lassen und im Fall von langsamen Antworttzeiten deiner Applikation nachschauen, woran es denn liegen kann. Setzt du dann z.B. in deiner Datenbank-Abstraktionsschicht entsprechende Punkte, siehst du sofort, wo es hakt.
Zitat:
|
edit: hab mir das apf mal runtergeladen, ich probiers bei Gelegenheit das benchmarking selbst aus
|
Klar. Wenn du dazu noch Fragen hast, immer her damit.
Viele Grüße,
Dr.E.