Schrittweise Ausgabe von Daten (whois - lange Scriptlaufzeit)

dwex

dwex

Erfahrenes Mitglied
Hallo Leute,

lange frage ich es mich schon wie man das hin bekommt, dass wenn man z.B. viele whoisserver abruft die Ergebnisse immer teilweise auf den Bildschirm bekommt.
Also 1. Domain geprüft --> Ergebnis 1 in Tabelle (auf Bildschirm) dann 2. Domain geprüft --> Ergebnis 1 und 2 in Tabelle ausgegben usw.
Bisher war ich der Meinung das dies nicht funktioniert und es wurde ja in der Vergangenheit auch diskutiert - ohne Ergebnis.

So jetzt bin ich auf die Seite http://www.whois.de/de/ gestossen - die machen das genau so wie ich das bräuchte. Macht mal eine Suche und beim Dropdown "alle Domains" auswählen und schaut euch das Ergebnis an.

Hat jemand eine Idee wie man das realisieren könnte (mit der schrittweisen Ausgabe).

Vielen Dank im voraus.
 
Ein Blick in den Quelltext zeigt, warum die scheinbare Tabelle partiell geladen wird: Es sind einfach voneinander unabhängige Tables, die je eine Reihe repräsentieren. Gekoppelt mit einer Vermischung der Verarbeitungs- und Ausgabeschicht (EVA wird hier nicht funktionieren), kann das pseudoartig so festgehalten werden:
Code: 
Initialisierung
  > oberen HTML-Bereich ausgeben
Lese Informationen zu 1tem Datensatz
  > Gib aus
Lese Informationen zu 2tem Datensatz
  > Gib aus
Lese Informationen zu 3tem Datensatz
  > Gib aus
...
Abschließen
  > unteren HTML-Bereich ausgeben

Des Weiteren bestünde noch die Möglichkeit, via Javascript einzelne Funktionen sequentiell zu schalten, die dann via HTTP-Request an den Server entsprechend immer einen Datensatz abholen.
 
Ja selbst wenn es nur einzelen Zeilen sind.
Wie funktioniert die Ausgabe.
Wenn ich ein Script habe und z.b. zwischen 2 echo-Befehlen eine Pause einfüge dann wird ja auch nicht der erste echo gleich und der zweite echo nach der Pause ausgegeben sondern alle beide nach der Pause.
Das ist eigentlich das was mich so verwirrt.
 
Muss mich entschuldigen, habe es unter verschiedenen Bedingungen erneut getestet, und es hat zu dem von dir ungewünschten Ergebnis geführt.
Es handelt sich hierbei um eine scheinbar fehlerhafte Implementierung der Output Control Direktiven und Funktionen, beziehungsweise um eine nicht ganz so nachvollziehbare Abhandlung des Scripts. Bevor ich jedoch falsche Tatsachen äußere, gibt es hier einen Bugreport.
Im CLI Modus konnte ich es leider noch nicht testen, aber auch da wird von Problemen gesprochen.
Das Verhalten ist sehr seltsam, denn in anderen Applikationen hat es bisher (scheinbar) kein solches Problem gegeben. Eventuell funktioniert es mit einer PHP Version < 5.0?

Alternative für den Moment: Andere Sprache, Javascript oder anderweitig dynamisches Nachladen ermöglichen.
 
Könnte es nicht auch eine Verbindung von flush(); und Javascript sein!?

-die "Bitte warten"-Zeile wird geflushed
-die Domain wird geprüft
-wenn das Ergebnis vorliegt wird das Ergebnis zusammen mit einem Javascript-Funktionsaufruf geflushed
-die Javascript-Funktion setzt den Display-Style der "Bitte warten"-Zeile auf "none" und die Zeile verschwindet
 
Aus der Feststellung heraus, dass folgendes Konstrukt nicht funktioniert, wird dies leider auch keine Lösung darstellen:
PHP: 
<?php
ini_set( "output_buffering", "1" );
ob_implicit_flush( true );
while (ob_get_level()) {
    ob_end_flush();
}

for ( $i = 0; $i < 10; ++$i ) {
    echo 0x80000000 . "\n";
    flush();
    usleep( 500000 );
}
 
Sollte der Code prinzipell nicht funktionieren oder funktioniert er nur bei dir nicht?
Also bei mir lokal geht es und auf meinem Server auch....
 
Unter folgenden Konfigurationen funktioniert es trotz gesetzter ini-Direktiven nicht:
  • Windows Vista Business, Apache 2.0, PHP 5.2.1
  • SuSE Linux 10.0, Apache 2.0, PHP 5.2.2
  • Linux Fedora (fc8), Apache 2.2, PHP 5.3

Da ich früher jedoch schon ein ähnliches Konstrukt benötigt hatte, als mein localhost noch auf 4.4 lief, vermute ich, dass es am PHP 5 liegt, oder einfach an der zu geringen Datenmenge, die PHP trotz implizitem Flush nicht ausgeben möchte. Bestätigen kann ich diese Vermutung leider nicht.
Seltsamerweise gibt [phpf]readfile[/phpf] die Daten scheinbar sofort aus, kann aber auch nur eine Täuschung sein - Jedenfalls ließe das weiterhin vermuten, dass eine bestimmte Datenmenge im Puffer sein muss, bis PHP wirklich flusht.
 
Der Inhalt wird als „chunked“ ausgeliefert. Hier ein Beispiel mit fester Chunk-Größe, die jedoch auch variieren kann:
PHP: 
$chunkSize = 128;
header('Transfer-Encoding: chunked');
$chunks = str_split($content, $chunkSize);

foreach( $chunks as $chunk ) {
	// chunk-size
	echo dechex(strlen($chunk)) . "\r\n";
	// chunk-data
	echo $chunk . "\r\n";
	flush();
	usleep(500000);
}
// last-chunk
echo "0" . "\r\n";
// trailer
//echo "" . "\r\n";  // trailer
echo "\r\n";
exit;
Die Ausgabe darf dafür allerdings nicht gepuffert werden (vgl. auch [post=1538600]maeTimmaes Beispielcode[/post]). Falls eine leere Seite angezeigt oder es zu einem Fehler kommt, müsstest die header()-Anweisung mal herausgenommen werden, um eine ausgegebene Fehlermeldung zu Gesicht zu bekommen.
 
Danke für den Vorschlag, Markus. Dieser funktioniert bei mir unter dem Suse-System, jedoch nicht auf Vista. Habe selbst nochmal meinen Versuch aufgenommen und die auszugebenden Datenmengen vergrößert.
Nochmal zum Nachvollziehen:
PHP: 
<?php
ini_set( "output_buffering", "1" );
ob_implicit_flush( true );
while (ob_get_level()) {
    ob_end_flush();
}

for ( $i = 0; $i < 200; ++$i ) {
    echo "$i. " . md5( (String) rand( 0, 1000 ) ) . "\n";
    flush();
    usleep( 50000 );
}
Zur Ausführung habe ich den Zend Debugger benutzt, der nach etwa jeder (geschätzt durch manuelles Stoppen des Debuggers) 30ten Schleife die entsprechenden Zeilen ausgab, was seltsamerweise sehr gut zu einer Buffergröße von 1024kb passt: 1024 / (32 [md5] + 1 [\n]) = ~31.
Zum Verschwörungstheoretiker möchte ich nicht verkommen, jedoch scheint PHP von Natur aus 1kb zurückzuhalten bis entweder zum nächsten Ausgabeintervall, oder bis das Script abgearbeitet ist und der GC aufräumt.
Leider konnte ich in der entsprechenden ini keine Angaben dieser Art feststellen, und wie der kleine Test zeigt, ist auch nichts dynamisch verändert worden.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück