Gaat RSS ten onder aan eigen succes?

Gaat RSS ten onder aan eigen succes?

Doordat RSS feeds steeds bekender wordt bij de gewone websurfer en de media, begint het verwachte bandbreedte-probleem een realiteit te worden. Hoe groot is het probleem en wat is de oplossing?

Statistieken van websites als Boing Boing laten zien dat er een terechte zorg is over de bandbreedte die feeds gebruiken.

Mogelijke oplossingen voor dit probleem zijn programma?s als RSScache (feed caching proxy) en KnowNow (even-driven syndication).

Bron:
Slashdot: Is RSS Doomed by Popularity?

Via:
PCM Web


Delen



Er zijn 12 reacties op dit artikel

  • P2P lijkt mij de oplossing...

    geplaatst op
  • Het wordt tijd dat RSS-readers leren omgaan met compressie-algoritmes. Alle benodigde technieken bestaan al jaren. Halen ze geen rss.xml binnen, maar een rss.zip. Scheelt al snel 70-90% in grootte. Koppel dat aan de caching-methode zoals RSScache die oppert, en het probleem is al goeddeels opgelost.

    geplaatst op
  • De oplossing is redelijk simpel. Je geeft iedereen een id in de feed mee. Vervolgens check je op de server of er nieuwe artikelen zijn since de laatste upload. Indien ja geef je alleen de nieuwe content. Indien nee geef je geen content terug.

    Dit voorkomt veel onnodig gebruik van bandbreedte.

    geplaatst op
  • U begint met de vraag: Gaat RSS ten onder aan eigen succes? Dat problemen kunnen ontstaan ben ik met u eens, maar u laat wel een aantal vragen onbeantwoord:

    Hoeveel individuele lezers moeten (vrijwel) gelijktijdig gebruik maken van 1 RSS-stream om problemen te veroorzaken (bij een gemiddelde bandbreedte)?

    Lost het probleem (deels) zichzelf niet op doordat er niet alleen aan de vraagkant ontwikkelingen zijn, maar ook aan de aanbodkant?

    Zijn er al voorbeelden op de Nederlandse RSS-markt bekend, die problemen hebben ondervonden met hun bandbreedte?

    geplaatst op
  • Het HTTP protocol heeft 2 headertags die uitstekend voorzien in het bandbreedte probleem.

    De Last-modified en de ETag. De nieuwsbod van alhetnieuws gebruikt deze twee tags om te bepalen of een feed nieuwe content bevat of niet, immers met meer dan 200 feeds elke 15 minuten controleren zou de bot onnodig veel bandbreedte verbruiken.

    Het idee is simpel: Sla beide tags op (in een database) en vergelijk deze wanneer je de feed opnieuw download. Zijn de waarden hetzelfde, dan kan na het inlezen van de header (circa 100 bytes) de verbinding direct verbroken worden.

    In sommige gevallen worden feeds dynamisch gegenereerd op het moment van opvragen. Dit is de slechtste manier van serveren; bij elke 'feedview' moet de server opnieuw aan het werk om de feed te genereren, door de dynamische content wordt het door een browser of bot niet gecached en de server geeft bovenstaande twee headers niet mee.

    Het is veel beter om een statische file alleen maar te updaten, wanneer er een nieuw item wordt toegevoegd. De webserver zorgt dan wel voor de juiste header.

    geplaatst op
  • @vincent

    Bij statische files ga je uit van een paradigma dat iedereen dezelfde content wil zien. Als ik een auto zoek bij autotrader ben ik alleen geinteresseerd in een specifiek merk, jaartal, prijs. Bij amazon geldt hetzelfde.

    Statische files zijn leuk maar een oud paradigma.

    geplaatst op
  • Jurjen, het heeft niet zozeer te maken met het aantal gelijktijdige gebruikers alswel met het totale aantal lezers en de frequentie waarmee ze de server raadplegen. Scobleizer heeft daar een aardig stuk over geschreven: A theory on why RSS traffic is growing out of control.

    Op je tweede vraag kan ik met ja antwoorden en daarvoor zijn door een aantal anderen hier al oplossingen aangedragen.

    Vwb je derde vraag, die zou je eigenlijk eens moeten voorleggen aan nu.nl. Volgens InfoCaster heeft nu.nl op dit moment 7.000 lezers en het zou me niet verbazen als ze daarmee de grootste zijn in Nederland. Sander, kun jij daar wellicht iets meer over zeggen?

    geplaatst op
  • @paul

    Het overgrote deel van alle feeds op internet geven slechts één of een paar categorieën weer. Weblogs hebben hoogstens twee verschillende feeds (artikelen / comments). Nieuwssites enkele (nieuws / sport / vrije tijd / etc).

    Al deze files kunnen gemakkelijk statisch zijn en alleen maar (automatisch) ge-update worden als er iets dient te veranderen aan de feed.

    Met een serverside script kun je óók aan de echte dynamische feeds (op basis van voorkeuren) de juiste headers mee geven, zodat aggregators kunnen cachen.

    geplaatst op
  • Kunnen (sommige) feedreaders overweg met cookies? Ik zou dat liever gebruiken dan elke gebruiker een uniek id om alleen de nieuwe berichten te tonen.

    Ik zou ook de feedreader makers vragen om tenminste compressie te ondersteunen (gzip) want dit scheelt vaak 80% en wordt door sites/script talen zeer goed ondersteund.

    In mijn logfiles zie ik dat MagpieRSS/YahooFeedSeeker HTTP1.0 gebruiken, maar dat Bloglines/FeedDemon/Feedreader/Feedster/RssReader/SharpReader wel HTTP1.1 gebuiken dus eigenlijk gzip zouden moeten ondersteunen. Helaas maken ze daar geen gebruik van!

    geplaatst op
  • @vincent. natuurlijk is het zo dat nu veel sites maar een feed geven omdat de tools die zij gebruiken dat alleen ondersteunt. Als je echter weer veel feeds hebt gaat het voordeel van webfeeds weer voor een groot deel verloren daar er vaak voor de gebruiker niet relevante informatie wordt doorgegeven.

    Een ander voordeel van id is statestieken. Je kunt direct zien hoeveel unieke gebruikers er zijn en waarop zij klikken. Als je nog een stap verder gaat kun je de feed daarop aanpassen. Of ga ik nu te ver...:-)

    geplaatst op
  • @Marco

    Bedankt voor het snelle antwoord.

    geplaatst op
  • Glenn Fleishman heeft een artikel (Throttling RSS Seems to Work) geschreven over het beperken van rss bandwidth. Ook geeft hij tips om het gebruik daadwerkelijk te beperken.
    I built a simple program running via Apache that throttles RSS downloads: a given IP and user agent combination can only request a given RSS feed file if it's changed since they last retrieved it.

    geplaatst op

Plaats zelf een reactie

Log in zodat je (in het vervolg) nóg sneller kunt reageren

Vul jouw naam in.
Vul jouw e-mailadres in. Vul een geldig e-mailadres in.
Vul jouw reactie in.

Herhaal de tekens die je ziet in de afbeelding hieronder


Let op: je reactie blijft voor altijd staan. We verwijderen deze dus later niet als je op zoek bent naar een nieuwe werkgever (of schoonmoeder). Reacties die beledigend zijn of zelfpromotioneel daarentegen, verwijderen we maar al te graag. Door te reageren ga je akkoord met onze voorwaarden.