Nochmals feeds lesen mithilfe von AJAX

[pto]

Hallo, ich habe noch mal eine Frage zu AJAX. Ich verweise auf meine Frage vor einem Monat:

http://forum.de.selfhtml.org/archiv/2014/5/t217355/#m1492858

Ich frage inzwischen meine feeds per js ab, aber dennoch bekomme ich manchmal ein memory-timeout und eine weiße Seite. Ich wollte mich auf den Bereich Ajax vortasten und fragen, ob mir dabei google ajax feed api eine Hilfe sein könnte? Wie sind Eure Erfahrungen.Ich glaube, es wäre für mich mit meinen jetzigen beschränkten Kenntnissen dennoch kein PRobem für mich, in einen cache zu schreiben, aber die Kommunikation mithilfe von Ajax ist mir noch ein Buch mit sieben Siegeln. Jetzt bekomme ich manchmal ja nicht erst beim refreshen sondern gleich beim ersten Aufruf ein timeout, nützt mir da Ajax etwas (wird dann zuerst auf den alten Cache zugegriffen?) Fragen über Fragen...

Gruß
pto

[Jörg Reinholz]

Hallo, ich habe noch mal eine Frage zu AJAX. Ich verweise auf meine Frage vor einem Monat:

http://forum.de.selfhtml.org/archiv/2014/5/t217355/#m1492858

Ich frage inzwischen meine feeds per js ab,

Definiere mal "meine" feeds. Erzeugst Du die selbst? Dann wäre das ein Ansatz. Ich weiß nicht, warum CMS, welche quasistatische Seiten erzeugen, den "teuren" Vorgang des Erzeugen des Feeds bzw. auch der Sitmap bei jedem Abruf ausführen, statt die Dinger statisch abzulegen...

Ich sehe die Verwendung von Ajax hier nicht als kluge Lösung an. Meinen "Feedreader" habe ich so gestrickt:

Web (Feeds der Anbieter) <-> PHP <-> Cache der generierten HTML-Sniplets <-> PHP <-> Apache <-> Browser.

Wird also ein Feed abgerufen und verarbeitet, so landet das Resultat der Verarbeitung als HTML-Stückchen im Cache - und zwar als Datei. Bei einem späteren Abruf wird der Cache für jeden Feed auf Gültigkeit untersucht, wenn noch gültig in die Webseite eingebaut, also ausgeliefert, wenn nicht neu abgerufen und verarbeitet. Klappt das Abrufen nicht, dann wird (so vorhanden) weiter die alte, in meinem Cache gespeicherte Version gesendet.

So sieht das dann bei mir aus...

Jörg Reinholz

[pto]

Web (Feeds der Anbieter) <-> PHP <-> Cache der generierten HTML-Sniplets <-> PHP <-> Apache <-> Browser.

Wird also ein Feed abgerufen und verarbeitet, so landet das Resultat der Verarbeitung als HTML-Stückchen im Cache - und zwar als Datei. Bei einem späteren Abruf wird der Cache für jeden Feed auf Gültigkeit untersucht, wenn noch gültig in die Webseite eingebaut, also ausgeliefert, wenn nicht neu abgerufen und verarbeitet. Klappt das Abrufen nicht, dann wird (so vorhanden) weiter die alte, in meinem Cache gespeicherte Version gesendet.

So sieht das dann bei mir aus...

Jörg Reinholz

Vielen Dank für die ANtwort. Ich habe ja (zunächst ohne css-, php-Kenntnisse usw.)so eine ähnliche Seite gebaut - mehr als Arbeitshilfe für Nachrichtenkollegen und für mich selbst, habe erst magpie und später einen anderen feedreader eingebaut, jetzt in einer js-Version.

Was mich interessiert: Ich habe keine Vorstellung davon, wie dieses Abgleichen des caches (noch aktuell?) funktioniert. Denn wie findet dieser Abgleich statt, ohne alle feeds einfach noch mal abzufragen - und das ist doch das, was so lange dauert. Ich hatte an cronjobs gedacht, die aber mein Provider nicht anbietet.

Also: Abgleich "im Hintergrund" ohne Komplett-Aktualisierung (bei mir z. Zt. durch refresh alle 5 Minuten). Wenn Du mir da auf die Sprünge helfen könntest?

So sieht es bei mir z. Z. aus:
aktuell laufende "alte" Version

Das ist der Relaunch-Zwischenstand:
Relaunch-Versuch

Dank und Gruß
Peter

[Auge]

Hallo

Ich habe ja (zunächst ohne css-, php-Kenntnisse usw.)so eine ähnliche Seite gebaut - mehr als Arbeitshilfe für Nachrichtenkollegen und für mich selbst, habe erst magpie und später einen anderen feedreader eingebaut, jetzt in einer js-Version.

Was mich interessiert: Ich habe keine Vorstellung davon, wie dieses Abgleichen des caches (noch aktuell?) funktioniert. Denn wie findet dieser Abgleich statt, ohne alle feeds einfach noch mal abzufragen …

Genau so. Entweder du fragst alle x Minuten stumpf alle deine Quellen ab und speicherst sie auf dem Server zwischen. Vom Browser aus holst du dir dann die bei dir vorliegenden Feeds. Oder du fragst gleich vom Browser aus die Originalquellen ohne den Umweg über den eigenen Server ab.

… und das ist doch das, was so lange dauert.

Nun ja, es dauert halt je nach Datenmenge eine gewisse Zeit, Daten zu holen.

Ich hatte an cronjobs gedacht, die aber mein Provider nicht anbietet.

Es gibt externe Anbieter für Cronjobs. Ob man die nutzen will, hängt von der Sicherheit und Zuverlässigkeit ab.

Tschö, Auge

[pto]

Ich habe keine Vorstellung davon, wie dieses Abgleichen des caches (noch aktuell?) funktioniert. Denn wie findet dieser Abgleich statt, ohne alle feeds einfach noch mal abzufragen …

Genau so. Entweder du fragst alle x Minuten stumpf alle deine Quellen ab und speicherst sie auf dem Server zwischen. Vom Browser aus holst du dir dann die bei dir vorliegenden Feeds. Oder du fragst gleich vom Browser aus die Originalquellen ohne den Umweg über den eigenen Server ab.

… und das ist doch das, was so lange dauert.

Nun ja, es dauert halt je nach Datenmenge eine gewisse Zeit, Daten zu holen.

Ja, dennoch fällt mir auf, dass zum Beispiel die Seite des Kollegen Reinholz http://www.fastix.org/news.php sofort da ist, während meine ein Timeout kriegt. Vor allem sehe ich dann den Sinn des Caches überhaupt nicht ein... Dann würde es ja nun mal solange dauern, wie es halt dauert und man kann nur die Datenmenge reduzieren (weniger feeds, weniger items)...

[Jörg Reinholz]

Web (Feeds der Anbieter) <-> PHP <-> Cache der generierten HTML-Sniplets <-> PHP <-> Apache <-> Browser.

Was mich interessiert: Ich habe keine Vorstellung davon, wie dieses Abgleichen des caches (noch aktuell?) funktioniert. Denn wie findet dieser Abgleich statt, ohne alle feeds einfach noch mal abzufragen - und das ist doch das, was so lange dauert.

Das ist doch ganz einfach: Ich frage das Dateisystem wie alt denn das gecachte HTML-Sniplet ist.

Ist es älter als die definierte cachetime: dann
   versuche ich neue Daten zu holen
   Falls das nicht klappt: dann
       hole ich den Dateiinhalt (Sniplet) in den Speicher
       Falls das nicht klappt (nicht vorhanden...):
             Erzeuge ich für den Speicher ein leeres Sniplet
       ENDIF
   ENDIF
   baue das HTML-Sniplet und setze mit dem Speichern das Änderungsdatum
   behalte das neue Sniplet im Speicher
ELSE
   hole ich den Dateiinhalt in den Speicher
ENDIF

[pto]

Das ist doch ganz einfach: Ich frage das Dateisystem wie alt denn das gecachte HTML-Sniplet ist.

Ist es älter als die definierte cachetime: dann
   versuche ich neue Daten zu holen
   Falls das nicht klappt: dann
       hole ich den Dateiinhalt (Sniplet) in den Speicher
       Falls das nicht klappt (nicht vorhanden...):
             Erzeuge ich für den Speicher ein leeres Sniplet
       ENDIF
   ENDIF
   baue das HTML-Sniplet und setze mit dem Speichern das Änderungsdatum
   behalte das neue Sniplet im Speicher
ELSE
   hole ich den Dateiinhalt in den Speicher
ENDIF

Danke erstmal für die Hinweise. filemtime kenne ich zwar, aber wie so ein Sniplet aussieht, muss in mir erstmal einverleiben.

Dann müsste ja aber das ERSTE Aufrufen der Seite z. B. am Morgen oder wenn die Seite länger nicht aufgerufen wurde, trotzdem genauso lange dauern wie bisher, weil die cachetime ja auf jeden Fall überschritten wurde (also wieder Ladezeit zu lang - memory timeout!) Oder habe ich da was übersehen? oder falsch verstanden...

Gruß
pto

[Jörg Reinholz]

Danke erstmal für die Hinweise. filemtime kenne ich zwar, aber wie so ein Sniplet aussieht, muss in mir erstmal einverleiben.

Das jeweilige Stückchen HTML, dass aus einem Feet erzeugt wird. Will ja nicht jeder Benutzer die gleichen Feeds sehen. Also muss des Cachens wegen das Abholen (und das Umwandeln gleich mit) vom Ausliefern getrennt werden.

Jörg Reinholz

[pto]

Danke erstmal für die Hinweise. filemtime kenne ich zwar, aber wie so ein Sniplet aussieht, muss in mir erstmal einverleiben.

Das jeweilige Stückchen HTML, dass aus einem Feet erzeugt wird. Will ja nicht jeder Benutzer die gleichen Feeds sehen. Also muss des Cachens wegen das Abholen (und das Umwandeln gleich mit) vom Ausliefern getrennt werden.

Jörg Reinholz

Das verstehe ich, aber noch mal die Frage:
Dann müsste ja aber das ERSTE Aufrufen der Seite z. B. am Morgen oder wenn die Seite länger nicht aufgerufen wurde, trotzdem genauso lange dauern wie bisher, weil die cachetime ja auf jeden Fall überschritten wurde (also wieder Ladezeit zu lang - memory timeout!) Oder habe ich da was übersehen? oder falsch verstanden...

Gruß
pto

[Jörg Reinholz]

Das verstehe ich, aber noch mal die Frage:
Dann müsste ja aber das ERSTE Aufrufen der Seite z. B. am Morgen oder wenn die Seite länger nicht aufgerufen wurde, trotzdem genauso lange dauern wie bisher, weil die cachetime ja auf jeden Fall überschritten wurde (also wieder Ladezeit zu lang - memory timeout!) Oder habe ich da was übersehen? oder falsch verstanden...

Erstmal: Nein. Beim allerersten Aufruf gibt es im Fehlerfall bei mir lediglich ein leeres Sniplet, also keine Inhalte aus dem Feed, dessen Abruf nicht geklappt hat. Bei jedem späteren misslungenem Versuch den früheren Zustand. Das von mir gesetzte Zeitlimit ist die Zeit, in der gar nicht erst versucht wird den Server nach dem aktuellen Feed zu fragen (Noch nicht mal eine Header-Anfrage wird da gemacht).

Was meinst nun:  Memory Limit überschritten oder Timeout?
Wenn Timeout:

Timeout beim Abholen?
Timeout beim selbst Aussenden?

Klar, wenn Du 50 Feeds abholst, von denen 10 je eine Minute brauchen, dann brauchst Du schon deshalb 10 Minuten für das Erstellen Deiner Seite... jedenfalls so lange Du Dir nichts einfallen lässt um das Abholen zu parallelisieren. Das geht mit einem kleinen Trick sehr wohl.

Wenn das Abrufen der Feeds also dauernd in Timeouts endet, dann musst Du Dir in paar Gedanken mehr machen. Du kannst die Feeds tatsächlich von einem Cronjob abholen und damit im Hintergrund einen eigenen Cache füttern lassen. Bedenke aber was die Betreiber der Server dazu sagen werden wenn aller paar Sekunden bei denen ein Request aufschlägt und die dann merken, dass der vorsorglich erfolgt, also deren Server (aus deren Sicht: sinnlos) belastet wird, nämlich ohne dass hierbei ein Request eines Browsers bedient wird.

Gerade die, deren Antwortzeiten länger dauern, werden wohl diese unnütze Last loswerden wollen und mit einem kleinen Eintrag in der .htaccess sind die Dich los.

Kaum zu erreichen ist, dass die mich (oder einen anderen) anrufen, damit ich (oder der andere) deren CMS so umstricke dass der Feed (wie auch die sitmap) "quasistatisch" bereit gestellt und ggf. auch gekürzt wird. Ja. Ich habe sogar schon Volltext-Feeds gesehen, die zeitlich "bis an die Anfänge des Internets" zurück reichten und dann auch noch durch Datenbankabfragen erzeugt wurden.

Über die sonstige Umgebung wissen wir nichts. Wenn Du ein lokales Netzwerk hast, dann kann man natürlich die Feeds auch via einen Webcache wie dem Proxyserver Squid abholen und browserseitig mit JS verarbeiten. Letzteres wirst Du wohl mit "Ajax" meinen. Wobei ich mich dann frage, warum nicht gleich einer der gängigen Feedreader genommen wird statt das Rad selbst neu zu erfinden.

Jörg Reinholz