nicht angemeldet
Seltsame Skriptlaufzeit Messung
Hi,
Ich messe immer zur Probe mit microtime() wie lange das Skript zum Durchlaufen braucht. Jetzt habe ich aber schon öfter festgestellt, dass die Zeit viel höher ist, wenn mein Internetzugang gerade lahmt und der Server aber voll da und schnell ist. Also ein Skript, das im Durschnitt 0,3 Sekunden braucht, braucht jetzt plötzlich 1,2 obwohl der Server definitiv nicht lahmt sondern mein Inet Zugang.
Warum ist das bitte so? Die Skriptlaufzeit wird doch allein am Server berechnet erst die HTML Seite lädt dann bei mir eben langsamer, allerdings ist die Zeit da ja schon längst in der HTML Datei eingetragen.
Um Missverständnissen vorzubeugen: ich habe meinen Webspace bei einem Provider, der nicht im geringsten mit meinem Inet Anschluss zusammenhängt, also lahmt der nicht automatisch auch wenns bei mir lahmt und umgekehrt.
-
Hello,
jede Messung verfälscht das Ergebnis.
Wann und wie setzt Du denn die Messpunkte? Werden zwischendurch Bufferoperationen vorgenommen?
So wie Du das beschreibst, misst Du nur die Script-Lebensdauer aber nicht die Rechenzeit am Server.
Erzähl doch mal mehr.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Ich schreibe am Anfang des Scripts microtime() in eine Variable und am Ende ziehe ich dieses microtime von dem dann aktuellen ab.
Habe ich mal irgendwo gefunden das Skript und es funktioniert eigentlich auch.
Dazwischen werden jede Menge mysql queries durchgeführt und Sachen zugeschnitten und in Arrays geschrieben.-
Hello,
Ich schreibe am Anfang des Scripts microtime() in eine Variable und am Ende ziehe ich dieses microtime von dem dann aktuellen ab.
Habe ich mal irgendwo gefunden das Skript und es funktioniert eigentlich auch.
Dazwischen werden jede Menge mysql queries durchgeführt und Sachen zugeschnitten und in Arrays geschrieben.Und wann werden die Ergenisse an den Standard-Buffer ausgegeben?
Die Ausgaberoutine des Scriptes geht solange in eine idle-Funktion, wenn der Buffer noch nicht wieder geräumt ist, also der Client humpelt.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Was meinst du genau mit Standard Buffer? Wann ein print erfolgt? Am Ende des Skriptes.
-
Hello,
Was meinst du genau mit Standard Buffer? Wann ein print erfolgt? Am Ende des Skriptes.
Ja, der output-buffer wird durch Print(), echo und auch durch normales HTML beschrieben. Um eine genauere Ausgabe zu machen, müsste ich also etwas über den Aufbau Deines Scriptes wissen. Wird dann außer der Laufzeitangabe keine weitere Ausgabe an den Client geschickt?
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Ja, der output-buffer wird durch Print(), echo und auch durch normales HTML beschrieben. Um eine genauere Ausgabe zu machen, müsste ich also etwas über den Aufbau Deines Scriptes wissen. Wird dann außer der Laufzeitangabe keine weitere Ausgabe an den Client geschickt?
Dochdoch, das ganze HTML eben. Ich arbeite aber mit Templates, deshalb gibts nur ein print am Ende des Skriptes. Davor wird eben die Seite zusammengebaut :)
-
hallo,
so wie ich das sehe sieht das folgendermaßen aus:
scenario a)
startzeitpunkt wird gesetzt
[hier macht dein skript irgendwas]
dann schicke html an client
schreibe endzeitpunkt - startzeitpunkt.
exit;scenario b)
startzeitpunkt wird gesetzt
[hier macht dein skript irgendwas]
schreibe endzeitpunkt - startzeitpunkt.
dann schicke html an client
exit;das lustige daran ist, dass es egal ist und das hängt mit dem buffering zusammen.
Wegen performance gründen schreibt das betriebsystem / schreiben programme ihre daten nicht sofort auf die platte.
das ist wie wenn du dreckige wäsche hast und du wäscht ja auch nicht sofort eine socke wenn du die dreckig ist.
stell dir mal vor alle programme würden ständig gleich auf die platte schreiben.dein skript wird langsam, weil
du zwei unterschiedliche Filehandles verwendest, von denen beide gebuffert sind. STDOUT und dein timefile.
damit ein buffer aber auch vernünftig funktioniert, muss er eine bestimmte grösse haben, in dem falle timefile ist sehr wahrscheinlich grösser als deine zeit zeichenkette.-------
also gehen wir von einer schnellen verbindung aus:
du schickst bufferweise das html an den client.
das geht schnell, weil schnelle verbindung.
dann schreibst du gebuffert deine zeitstring.
dein programm kann jetzt aufhören und erst jetzt wird der buffer in dein timefile geschrieben, weil es sich bis jetzt ja nicht gelohnt hat.langsame verbindung:
dein skript wird nicht vorher aufhören das html an den client zu senden, bis dieser abbricht, oder dein skript fertig ist.
und hier kann dein skript die daten nicht so schnell rausschmeissen, weil langsame verbindung, oder packete gehen verloren.
aber auch hier wird erst am ende des skriptes der zeitstring buffer gelehrt in deine datei.deswegen dauert das länger.
gruss
--
no strict;
no warnings;
Selbstcode: (_*_) ^_^ ( . ) ( . ) :-(bla)-
Hallo!
Wegen performance gründen schreibt das betriebsystem / schreiben programme ihre daten nicht sofort auf die platte.
Was wird denn hier _überhaupt_ auf die Platte geschrieben?
stell dir mal vor alle programme würden ständig gleich auf die platte schreiben.
Beim Senden über das Netzwerk wird gepuffert, aber sonst...?
dein skript wird langsam, weil
du zwei unterschiedliche Filehandles verwendest, von denen beide gebuffert sind. STDOUT und dein timefile.was denn für ein "timefile"?
also gehen wir von einer schnellen verbindung aus:
du schickst bufferweise das html an den client.
das geht schnell, weil schnelle verbindung.
dann schreibst du gebuffert deine zeitstring.also das wäre mir neu, AFAIK werden die Variablen und Werte von PHP direkt in den RAM geschrieben.
Grüße
Andreas-
ok,
ich ging von einer falschen annahme aus: ich dachte er schreibt die zeit in ein log, konnte ja auch nur raten ohne code.aber hier sollte dich interessieren
http://perl.plover.com/FAQs/Buffering.html
ist zwar für perl, aber bei php verläufts vermutlich ähnlich[zitat] für perl
Instead, it reads and writes large chunks of data to a `buffer' in memory, and does I/O to the buffer; this is much faster than making a request to the operating system for every read or write.
[/zitat]gruss
--
no strict;
no warnings;
Selbstcode: (_*_) ^_^ ( . ) ( . ) :-(bla)-
Hello,
[zitat] für perl
Instead, it reads and writes large chunks of data to a `buffer' in memory, and does I/O to the buffer; this is much faster than making a request to the operating system for every read or write.
[/zitat]Dieser Buffer ist dann meistens als Ringbuffer aufgebaut. Solange Daten drinstehen, kann der Programmteil, der für die Ausgabe an den Client zuständig ist, Ausgaben machen. Die werden aber auch nicht byteweise gesendet, sondern in hübschen Quäntchen passend für das jeweilige Übertragungsprotokoll auf Hardwareebene.
Und solange die Ausgabe des Scriptes nicht in den Buffer passt, wartet das Runtime dann eben.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
-
-
-
-
-
Hallo Razor,
Ich schreibe am Anfang des Scripts microtime() in eine Variable und am Ende ziehe ich dieses microtime von dem dann aktuellen ab.
du weiß schon was microtime() zurückliefert, oder? Einfach Subtrahieren ist da nämlich nicht (außer natürlich der 1.Parameter steh auf true (was allerdings erst ab php5 geht)).
Grüße aus Nürnberg
Tobias--
Selfcode: sh:( fo:) ch:? rl:( br:< n4:& ie:% mo:| va:) de:] zu:) fl:( ss:| ls:[ js:|-
Ich weiß, ich sagte ja ich habe die Anleitung zu dem Skript wo gefunden, sind ja nur ein paar Zeilen, habs dann eingefügt, es läuft 100pro richtig.
So siehts aus am Ende ($starttime ist am Anfang gesetztes microtime()):
$microtimes = explode(" ", $starttime." ".microtime());
$runtime = ($microtimes[2] + $microtimes[3]) - ($microtimes[0] + $microtimes[1]);
$runtime = sprintf("%0.4f", $runtime);print $runtime
-
-
-