hi,
mir ist aufgefallen das in verschiedenen blogs im footer folgendes
angezeigt wird:
diese seite wurde in 0.7s aufgerufen
wie kann ich das mit php ermitteln?
gruß
yavuz
yonthebeach@googlemail.com wrote:
> hi,
>
> mir ist aufgefallen das in verschiedenen blogs im footer folgendes
> angezeigt wird:
>
> diese seite wurde in 0.7s aufgerufen
>
> wie kann ich das mit php ermitteln?
Siehe Handbuch zu microtime(), der Rest sind Mathematikgrundlagen.
gruß, Frank
"yonthebeach@googlemail.com" schrieb:
>hi,
>
>mir ist aufgefallen das in verschiedenen blogs im footer folgendes
>angezeigt wird:
>
>diese seite wurde in 0.7s aufgerufen
>
>wie kann ich das mit php ermitteln?
>
>gruß
>yavuz
Einfach am Anfang mit microtime() die Zeit nehmen, am Ende nochmal und
dann von einander anziehen.
Fertig ist die Aufbauzeit.
--
MfG. Timon R.
ICQ: 290982206
Webdesign & CM-Systeme: http://zaeda.net
Dein Wegweiser durchs Netz: http://zoomtheweb.de
"yonthebeach@googlemail.com" schrieb:
>hi,
>
>mir ist aufgefallen das in verschiedenen blogs im footer folgendes
>angezeigt wird:
>
>diese seite wurde in 0.7s aufgerufen
>
>wie kann ich das mit php ermitteln?
>
>gruß
>yavuz
Einfach am Anfang mit microtime() die Zeit nehmen, am Ende nochmal und
dann von einander anziehen.
Fertig ist die Aufbauzeit.
--
MfG. Timon R.
ICQ: 290982206
Webdesign & CM-Systeme: http://zaeda.net
Dein Wegweiser durchs Netz: http://zoomtheweb.de
--
MfG. Timon R.
ICQ: 290982206
Webdesign & CM-Systeme: http://zaeda.net
Dein Wegweiser durchs Netz: http://zoomtheweb.de
Hi Unbekannte(r)
yonthebeach@googlemail.com wrote:
^-- googlemail hat's wohl nicht drauf mit NG-Postings?
> mir ist aufgefallen das in verschiedenen blogs im footer folgendes
> angezeigt wird:
> diese seite wurde in 0.7s aufgerufen
> wie kann ich das mit php ermitteln?
microtime(true) ist die gefragte Funktion inkl. korrektem Parameter.
Diese Erweiterung in PHP 5.0.0 erleichtert die Arbeit zur Zeitmessung
ungemein.
Aber kannst du mir erklären, weshalb diese Funktion für den Nutzer
relevant sein soll? Mich interessiert diese Angabe erst, wenn ich so
lange nicht warten möchte. Und dann ist's eh zu spät und ich werde die
Ausgabe nie erkennen.
Für's debugging jedoch ist in jedem Fall interessant! Man möchte ja
wissen, wo man seine Ressourcen verbratet. :-)
HTH, Johannes
Johannes Vogel schrieb:
[microtime]
> Für's debugging jedoch ist in jedem Fall interessant! Man möchte ja
> wissen, wo man seine Ressourcen verbratet. :-)
Für das Profiling gibt es aber bessere Methoden, wie z.b.:
http://www.php.net/apd
Hat man das nicht zur Verfügung, kann man sich auch über
register_tick_function ein Profiling bauen und muß so nicht, wie mit
microtime, den funktionierenden Code manipulieren.
Gruß,
Torsten
Torsten Zühlsdorff wrote:
>>Für's debugging jedoch ist in jedem Fall interessant! Man möchte ja
>>wissen, wo man seine Ressourcen verbratet. :-)
>
>
> Für das Profiling gibt es aber bessere Methoden, wie z.b.:
> http://www.php.net/apd
Installation
APD is currently available as a PECL extension from
http://pecl.php.net/package/apd. Make sure you have installed the CGI
version of PHP and it is available in your current path along with the
phpize script.
Die Krätze kommt mir nicht ins Haus
Ganz abgesehen davon sieht es nicht so aus, als würde apd noch gepflegt:
http://pecl.php.net/package/apd
> Hat man das nicht zur Verfügung, kann man sich auch über
> register_tick_function ein Profiling bauen und muß so nicht, wie mit
> microtime, den funktionierenden Code manipulieren.
register_tick_function() should not be used with threaded webserver
modules. Ticks are not working in ZTS mode and may crash your webserver.
Also das überzeugt mich alles nicht Torsten. Einen Versuch hast du noch.
gruß, Frank
Frank Schenk schrieb:
>>> Für's debugging jedoch ist in jedem Fall interessant! Man möchte ja
>>> wissen, wo man seine Ressourcen verbratet. :-)
>>
>> Für das Profiling gibt es aber bessere Methoden, wie z.b.:
>> http://www.php.net/apd
>
> Installation
>
> APD is currently available as a PECL extension from
> http://pecl.php.net/package/apd. Make sure you have installed the CGI
> version of PHP and it is available in your current path along with the
> phpize script.
>
> Die Krätze kommt mir nicht ins Haus
Niemand zwingt dich dazu. Ich habe es genau deswegen auch nicht :P
>> Hat man das nicht zur Verfügung, kann man sich auch über
>> register_tick_function ein Profiling bauen und muß so nicht, wie mit
>> microtime, den funktionierenden Code manipulieren.
>
> register_tick_function() should not be used with threaded webserver
> modules. Ticks are not working in ZTS mode and may crash your webserver.
>
> Also das überzeugt mich alles nicht Torsten. Einen Versuch hast du noch.
Das ist hinnehmbar. Man testet ja auf Testrechnern und dort hat man die
absolute Macht. Und bisher konnte ich noch keine Probleme feststellen.
Ist im übrigen auch eine gute Debugging Methode. Spart man etliche LOC
Debugging-Code, da man sich auch so einen Trace ganz nach belieben
aufzeichnen lassen kann.
Leider ist die restliche Auswahl nicht allzu groß. Ich kann dir noch
xDebug anbietet:
www.xdebug.org
Letztlich habe ich die Vorschläge nur aus einen Grund gemacht: Es ist
ein Fehler zum "profilen" im Quellcode herumzuschreiben. Man wurstelt
nicht in stabilen Code herum, um zu sehen, ob da irgendwo ein
Performance-Flaschenhals ist.
Die genannten Methoden, ermöglichen eben dieses vorgehen. Jeder weitere
Vorschlag, benötigt Codemanipulationen.
Gruß,
Torsten
Hi Torsten
Torsten Zühlsdorff wrote:
> Das ist hinnehmbar. Man testet ja auf Testrechnern und dort hat man die
> absolute Macht. Und bisher konnte ich noch keine Probleme feststellen.
> Ist im übrigen auch eine gute Debugging Methode. Spart man etliche LOC
> Debugging-Code, da man sich auch so einen Trace ganz nach belieben
> aufzeichnen lassen kann.
Problem: Manchmal muss man mal kurz was auf dem Produktiv-Maschine
testen, weil einfach die Umgebung nicht exakt dieselbe ist oder ne
schnelle Lösung herhalten muss. Und das bedingt dann eben kurze und
kleine Eingriffe, wofür microtime(true) für mich noch immer erste Wahl
ist. Ein tic und ein toc und schon weiss ich Bescheid! (Siehe Matlab)
> Leider ist die restliche Auswahl nicht allzu groß. Ich kann dir noch
> xDebug anbietet:
> www.xdebug.org
> Letztlich habe ich die Vorschläge nur aus einen Grund gemacht: Es ist
> ein Fehler zum "profilen" im Quellcode herumzuschreiben. Man wurstelt
> nicht in stabilen Code herum, um zu sehen, ob da irgendwo ein
> Performance-Flaschenhals ist.
Ich möchte nicht wissen, ob's unter profiling-Bedingungen sauber läuft,
sondern ob der funktionierende Code sauber läuft. Die Frage lautet: Was
möchte ich messen und was messe ich. Anders geht's per Definition nicht.
> Die genannten Methoden, ermöglichen eben dieses vorgehen. Jeder weitere
> Vorschlag, benötigt Codemanipulationen.
Die genannten Methoden sind praktisch, wenn ich herausfinden möchte, wo
was besonders langsam ist. Aber wie langsam es ist, lässt sich eben
nicht eruieren, weil noch zusätzliche Operationen ausgeführt werden müssen.
Johannes
Johannes Vogel schrieb:
>>Das ist hinnehmbar. Man testet ja auf Testrechnern und dort hat man die
>>absolute Macht. Und bisher konnte ich noch keine Probleme feststellen.
>>Ist im übrigen auch eine gute Debugging Methode. Spart man etliche LOC
>>Debugging-Code, da man sich auch so einen Trace ganz nach belieben
>>aufzeichnen lassen kann.
>
> Problem: Manchmal muss man mal kurz was auf dem Produktiv-Maschine
> testen, weil einfach die Umgebung nicht exakt dieselbe ist oder ne
> schnelle Lösung herhalten muss. Und das bedingt dann eben kurze und
> kleine Eingriffe, wofür microtime(true) für mich noch immer erste Wahl
> ist. Ein tic und ein toc und schon weiss ich Bescheid! (Siehe Matlab)
So ein Vorgehen kann schnell nach hinten los gehen. Das ist typisch
"quick and dirty" und sollte nicht verteidigt werden. Natürlich ist so
ein Vorgehen "weit verbreitet" (rein subjektiv), aber was soll man dazu
sagen? Ein falsches Zeichen und du hast deine Produktiv-Umgebung
unbrauchbar gemacht und fertig. Das ist nicht mal eine Sekunde lang
duldbar ;)
>>Leider ist die restliche Auswahl nicht allzu groß. Ich kann dir noch
>>xDebug anbietet:
>>www.xdebug.org
>>Letztlich habe ich die Vorschläge nur aus einen Grund gemacht: Es ist
>>ein Fehler zum "profilen" im Quellcode herumzuschreiben. Man wurstelt
>>nicht in stabilen Code herum, um zu sehen, ob da irgendwo ein
>>Performance-Flaschenhals ist.
>
> Ich möchte nicht wissen, ob's unter profiling-Bedingungen sauber läuft,
> sondern ob der funktionierende Code sauber läuft. Die Frage lautet: Was
> möchte ich messen und was messe ich. Anders geht's per Definition nicht.
Das ist richtig. Aber beim Profiling geht es daraum, herauszufinden, was
wieviel Ressourcen verbraucht. Sei es HEAP oder einfach nur Zeit. Oder
wie häufig etwas ausgerufen wird.
Ansonsten: sauberer Code läuft für gewöhnlich auch sauber. ;)
>>Die genannten Methoden, ermöglichen eben dieses vorgehen. Jeder weitere
>>Vorschlag, benötigt Codemanipulationen.
>
> Die genannten Methoden sind praktisch, wenn ich herausfinden möchte, wo
> was besonders langsam ist. Aber wie langsam es ist, lässt sich eben
> nicht eruieren, weil noch zusätzliche Operationen ausgeführt werden müssen.
Das möchtest du näher erläutern. Du hast mit diesen Methoden eine
Auflistung der Aufrufe, des Speicherverbraues, des Zeitverbrauches und
vieles mehr. Durch das Profiling siehst du das ganze auch im Verhältnis
zur ganzen Applikation usw. Was fehlt dir?
Gruß,
Torsten
Hi Torsten
Grundsätzlich gibt's dazu nicht mehr viel zu sagen. :-)
Torsten Zühlsdorff wrote:
> Ansonsten: sauberer Code läuft für gewöhnlich auch sauber. ;)
:-D <-- *auslach*
Johannes
Johannes Vogel schrieb:
> Grundsätzlich gibt's dazu nicht mehr viel zu sagen. :-)
>>Ansonsten: sauberer Code läuft für gewöhnlich auch sauber. ;)
>
> :-D <-- *auslach*
Es ist Freitag. Da darf man das :D
Gruß,
Torsten