Wie Inhalte die nur langsam geliefert werden sofort anzeigen?
-
Das scheint mir ziemlich browserspezifisch zu sein. Du könntest ja mal http://stackoverflow.com/questions/6089921/firefox-4-doesnt-render-partial-pages ausprobieren. Die zweite Antwort wirkt recht vielversprechend.
-
Hallo,
Dasd schrieb:
Das scheint mir ziemlich browserspezifisch zu sein.
Weiß ich nicht, aber ich werde mal versuchen verschiedene Browser zu probieren. Viele werden das aber nicht da in der Maschine nur Linux-Rechner verfügbar sind.
Dasd schrieb:
Du könntest ja mal http://stackoverflow.com/questions/6089921/firefox-4-doesnt-render-partial-pages ausprobieren. Die zweite Antwort wirkt recht vielversprechend.
Gerade diese Antwort sagt mir gar nichts. Was soll den Bitte in das <script>-Tag rein das hinter dem </html> kommt? Etwa ein JavaScript das per XMLHttpRequest die eigentlichen Ergebnisdaten holt und ins HTML-Gerüst einbaut? Dieses Script kann auch gleich am Anfang ins HTML eingebaut werden (da wo es korrekt hingehört). Die eigentlichen Ergebnisdaten kommen wohl bestimmt nicht pur hinter das abschließende </html>. Mal ganz davon abgesehen das ich alle ausgelieferten HTML-Seiten als valides XHTML 1.1 markiere und mir auch Mühe gebe das dem wirklich so ist.
Die Antwort vom svick am May 23 '11 at 17:53 entspricht zumindest eher meiner persönlichen subjektiven Einschätzung. Ich schätze ich werd noch mal Google benutzen und wenn das zu keinem Ergebnis führt mal versuchen bei den Programmierern nachzufragen.
Zumindest ist das Problem des Fragestellers mit meinem ziemlich identisch, Danke für diesen Hinweis.
Grüße
Erik
-
Die korrekte Loesung ist cronjob und die Daten cachen. Kann ja durchaus jede Minute 1 mal passieren.
Wenn das nicht geht, dann eben per ajax nachladen.
-
Hallo,
Shade Of Mine schrieb:
Die korrekte Loesung ist cronjob
Nein, die korrekte Lösung ist das Redering-Mantra von 1994 "show as much as you can as soon as you can", siehe http://blog.codinghorror.com/the-lost-art-of-progressive-html-rendering/.
Shade Of Mine schrieb:
und die Daten cachen. Kann ja durchaus jede Minute 1 mal passieren.
Viele der Jobs benötigen Parameter die absolut nicht vorhersagbar sind und deren theoretische Anzahl an Kombinationsmöglichkeiten die Größe von RAM auf diesem Planeten deutlich übersteigen dürfte.
Nebst dessen das ich noch einmal drauf hinweisen möchte das es sich um eine kleine Embedded-Schachtel mit wenig RAM und auch nur wenig CPU-Leistung handelt, spekulative Jobausführung ist da absolut nicht möglich.Shade Of Mine schrieb:
Wenn das nicht geht, dann eben per ajax nachladen.
Aber auch AJAX hilft über dieses Problem nur bedingt hinweg oder erfordert eine hohe Komplexität und Arbeitslast (sowohl im Browser als auch im HTTP-Server), siehe mein Posting vom 16.07.
Ich hab heute ein paar Dinge bezüglich Firefox herausgefunden die ich morgen mal testen will, vielleicht komme ich ja so doch zu einer Lösung.
Grüße
Erik
-
erik.vikinger schrieb:
Hallo,
Shade Of Mine schrieb:
Die korrekte Loesung ist cronjob
Nein, die korrekte Lösung ist das Redering-Mantra von 1994 "show as much as you can as soon as you can", siehe http://blog.codinghorror.com/the-lost-art-of-progressive-html-rendering/.
Nein. Das ist etwas ganz anderes.
Shade Of Mine schrieb:
Wenn das nicht geht, dann eben per ajax nachladen.
Aber auch AJAX hilft über dieses Problem nur bedingt hinweg oder erfordert eine hohe Komplexität und Arbeitslast (sowohl im Browser als auch im HTTP-Server), siehe mein Posting vom 16.07.
Nein, ist trivial.
Welche Probleme hast du denn damit?Es darf ja ruhig laenger dauern, das tut doch nicht weh - du zeigst solange einen Ladebalken an. Du kannst ueber mehrere Requests so granular wie du willst laden.
Du machst dir das alles viel komplexer als es ist.
-
Hallo,
Shade Of Mine schrieb:
erik.vikinger schrieb:
"show as much as you can as soon as you can"
Nein. Das ist etwas ganz anderes.
Natürlich sind die Art der Informationsgewinnung und die Art der Informationsdarstellung zwei verschiedene Dinge aber mein Problem liegt an der Darstellung der Informationen durch den Browser und nicht an der Art der Informationsgewinnung in meiner Embedded-Schachtel.
Shade Of Mine schrieb:
Nein, ist trivial.
Welche Probleme hast du denn damit?Schon allein das überhaupt mehrere TCP-Verbingungen benötigt werden um alle Ergebnisse eines zusammenhängenden Jobs zum Browser zu transportieren macht AJAX sicher nicht mehr trivial. Und das nicht nur weil dann mein HTTP-Server die Fähigkeit benötigt mehrere TCP-Verbindungen also HTTP-Requests einem einzelnen/spezifischen Job zuzuordnen sondern weil dann die Ergebnis-Daten auch mal in der Embedded-Schachtel gepuffert werden müssen weil z.B. zwischen zwei Teilergebnissen der Browser noch nicht den nächsten XMLHttpRequest abgesetzt hat. Oder was ist wenn sich mal zwei XMLHttpRequest-Zugriffe auf den selben Job überlappen? Mag sein das sowas unter normalen Umständen nicht passiert aber mein HTTP-Server wird auf jeden Fall auch mit so einer Situation anständig fertig werden müssen.
Shade Of Mine schrieb:
Du machst dir das alles viel komplexer als es ist.
Ich bin der Meinung das meine derzeitige Lösung die einfachst mögliche ist. Der Browser baut eine einzelne TCP-Verbindung mit einem einzelnen HTTP-Request auf und meine Embedded-Schachtel sendet über diese eine TCP-Verbindung die Daten so schnell wie sie eben entstehen. Das einzigste was an diesem Szenario ein Problem darstellt ist das der Browser diese Daten nicht sofort darstellt sondern wartet bis alles da ist, entgegen dem nun 20 Jahre alten HTML-Redering-Mantra.
Mein HTTP-Server besteht momentan aus gut 15kBytes C-Code, das umfasst sämtliches HTTP-Parsing und auch das Zerlegen von URI-Queries in fertige Häppchen so das die eigentlichen Handler (die für die einzelnen URLs zuständig sind) alles mundgerecht serviert bekommen und dort höchstens noch die Job-Spezifischen Auswertungen drin sind. Dazu kommen noch knapp 10kBytes C-Code für die Generierung des HTML-Basisgerüsts inklusive des Menüs das in jede HTML-Seite eingebunden wird. Die eigentlichen Handler liefern nur noch den eigentlichen Content und manche davon sind weniger als 3kBytes C-Code und das trotz dessen das dort z.B. eine HTML-Tabelle mit einer variablen Anzahl an Zeilen für die dynamisch ermittelten Daten generiert wird. Wenn ein Job mal länger braucht wird das alles per Call-Backs realisiert und diese Call-Back-Funktionen bekommen immer den TCP-Socket-Descriptor als Parameter und reichen diesen Descriptor entweder zum nächsten Teil-Job weiter oder beenden die TCP-Verbindung falls der Job als ganzes beendet ist. Die überwiegend meisten dieser Call-Back-Funktionen sind kaum 50 Zeilen.
Ich bin wirklich der Meinung das es kaum noch einfacher geht aber wenn jemand eine Lösung mit AJAX kennt die ebenso simpel in meiner Embedded-Schachtel umgesetzt werden kann und möglichst auch keinen größeren Speicherbedarf (z.B. wegen zusätzlicher TCP-Sockets (die ja auch nach dem Ende einer TCP-Verbindung immer noch eine Weile am Leben sind) oder Pufferplatz für die Ergebnis-Daten) verursacht dann würde ich das gerne hier lesen. Ich stehe alternativen Ideen durchaus aufgeschlossen gegenüber, mein Problem sind die arg begrenzten Ressourcen auf der Embedded-Schachtel.
Ich hab hier keinen fetten Apache mit PHP und MySQL Backends auf X GHz-Multicore mit X GBytes RAM, sondern ich hab 50 MHz-Singelcore mit 4 MByte RAM und dieses System soll hauptberuflich eine Maschine in Echtzeit steuern, der HTTP-Server ist da nur ein Nebenbei-Hobby.
Grüße
Erik
-
Versuch doch mal die zu übertragende Datenmenge zu reduzieren. Also z.B: eine Komrpimierung mit gzip, deflate zu implementieren. Gerade Text lässt sich doch wahnsinnig gut komprimieren. Je nach Netzwergeschwindigkeit und Datenmenge kann sich das richtig lohnen.
-
Ansonsten könntest du noch versuchen Chunked-Encoding zu implementieren.
-
erik.vikinger schrieb:
Shade Of Mine schrieb:
Nein, ist trivial.
Welche Probleme hast du denn damit?Schon allein das überhaupt mehrere TCP-Verbingungen benötigt werden um alle Ergebnisse eines zusammenhängenden Jobs zum Browser zu transportieren macht AJAX sicher nicht mehr trivial. Und das nicht nur weil dann mein HTTP-Server die Fähigkeit benötigt mehrere TCP-Verbindungen also HTTP-Requests einem einzelnen/spezifischen Job zuzuordnen sondern weil dann die Ergebnis-Daten auch mal in der Embedded-Schachtel gepuffert werden müssen weil z.B. zwischen zwei Teilergebnissen der Browser noch nicht den nächsten XMLHttpRequest abgesetzt hat. Oder was ist wenn sich mal zwei XMLHttpRequest-Zugriffe auf den selben Job überlappen? Mag sein das sowas unter normalen Umständen nicht passiert aber mein HTTP-Server wird auf jeden Fall auch mit so einer Situation anständig fertig werden müssen.
Ich verstehe das Problem auch nicht.
Erster Request an den Server liefert eine vollständiges, statisches HTML, was sich überhaupt nicht für die Daten interessiert.
Ist die Seite geladen, wird der zweite (Ajax-)Request abgesetzt, der reine Daten anfordert.
-
Jockelx schrieb:
Ich verstehe das Problem auch nicht.
Erster Request an den Server liefert eine vollständiges, statisches HTML, was sich überhaupt nicht für die Daten interessiert.
Ist die Seite geladen, wird der zweite (Ajax-)Request abgesetzt, der reine Daten anfordert.Exakt.
Das HTML dass auf den ersten Request gesendet wird kann dann schöne Ladeanimationen enthalten und je nachdem wie granular man es machen will lädt man jede Information die man Anzeigen will per eigenen ajax request oder alle zusammen in einem.Das ist trivial und das ist der Standardweg. Der wird auf Millionen von Webseiten eingesetzt. Es gibt ganze JavaScript Libraries die dieses Verhalten umsetzen.
Wie gesagt: hier wird viel zu kompliziert gedacht. Die Aufgabenstellung ist trivial. Die Lösung ist noch viel simpler. Man kann nämlich in dem ajax request sogar ein HTML fragment returnen und muss nicht mal irgendwas in JS postprozessen.