RSS updaten alleen wanneer nodig

[Verwijderd]

Omdat dit een serversided probleem is (en ik geen trap onder mijn kont van NMe wil ) stel ik bij deze mijn vraag in deze rubriek.

Het zit als volgt: ik haal rss feeds om de 5 uur binnen op mijn website en cache deze op de server in xml bestanden. Dit werkt allemaal prima.

Het gebeurt echter wel eens dat de content van sommige websites onveranderd is gebleven in die 5 uur, de rss is dan ook logischerwijs onveranderd. In die omstandigheden is het dan zonde om een rss feed weg te schrijven naar de server, terwijl de content exact hetzelfde is gebleven, je verliest dan toch voor niets een stukje datalimiet.

Kortom: rss updaten alleen wanneer nodig.

Om dit 'probleem' te verhelpen, bedacht ik om gewoon de opgehaalde content te vergelijken met de bestaande content, mocht er geen verschil tussen bestaan, dan wordt er ook niks weggeschreven! Ik heb hier gelukkig genoeg voorbeelden van kunnen vinden op internet, dus daar zal ik jullie niet mee lastigvallen

Maaarrrrrr, het valt me ook op, dat sommige websites toch hun rss feed updaten terwijl er qua content niets veranderd is... (ik vermoed dat dit automatisch gebeurt in sommige CMS). Het enige wat dan wel verandert is de <lastbuilddate>... terwijl alles voor de rest precies hetzelfde is. Probleem: dit bestand wordt tòch weggeschreven op de server omdat het toch niet helemaal hetzelfde is met het opgeslagen cache bestand... nietwaar?

Tja, hoe los je dàt dan op?

Zou het misschien een idee zijn om de content ook op bestandsgrootte te vergelijken? Maar ik neem aan dat enige verandering van <lastbuilddate> toch ook een *minieme* afwijking in bestandsgrootte oplevert, waardoor vergelijken op bestandsgrootte ook niet zal werken...

[mithras]

Wat zijn de kosten voor het wegschrijven van de feed? Want je zal toch a) de feed moeten ophalen van de url en b) hem moeten vergelijken met je cache. Als de vergelijking meer kost (of niet significant minder) dan het overschrijven van je cache, waarom wil je dit dan?

Mocht het overschrijven van de cache wel veel meer kosten dan het maken van een vergelijking: is het optimaliseren van je schrijven niet een betere investering?

[matthijsln]

Verwijderd schreef op donderdag 28 april 2011 @ 18:54:
Het gebeurt echter wel eens dat de content van sommige websites onveranderd is gebleven in die 5 uur, de rss is dan ook logischerwijs onveranderd. In die omstandigheden is het dan zonde om een rss feed weg te schrijven naar de server, terwijl de content exact hetzelfde is gebleven, je verliest dan toch voor niets een stukje datalimiet.

edit:
Als je enige probleem is dat het zonde is van je datalimiet, vraag ik me af wat nou eigenlijk het probleem is.

Trouwens, als je op een slimme manier wilt gaan vergelijken of het wel echt veranderd is, heb je de rss feed toch al binnen gehaald - en dus data verbruikt?

Het enige wat uberhaupt een probleem zou kunnen zijn is performance maar het lijkt me toch niet dat je er veel van merkt qua load.

[ Voor 26% gewijzigd door matthijsln op 28-04-2011 19:18 ]

[Verwijderd]

Jullie hebben een punt, derhalve had ik probleem ook tussen aanhalingstekens geschreven. Maar je moet je realiseren, als je 4 keer op een dag iets van 10 rss bestanden updatet (mogelijk in de toekomst zelfs meer), en dat gedurende een gehele maand... dan bespaart zo een controle je toch het één en ander aan het einde van de rit.

[krvabo]

Het enige wat ik me kan bedenken zijn de Modified-header (Maar die kan wellicht / allicht veranderen als ze hem auto-rebuilden) en als het ondersteunt wordt de ETag. Dat laatste is nogal afhankelijk van de aanbieder en er is een grote kans dat die niet wordt aangemaakt.

Anders zul je toch op een of andere manier de content moeten ophalen. Erna kun je wel het bestand hashen (uitgezonderd de 'builddate' tag) en kijken of ie overeenkomt met de hash van de vorige keer. Je verbruikt dan wel dataverkeer, maar het gaat verder niet je systeem in.

[matthijsln]

Inderdaad is het gebruik maken HTTP caching een goede optie, maar ik vermoed dat niet veel rss feeds dit ondersteunen.

[mace]

Verwijderd schreef op donderdag 28 april 2011 @ 19:16:
Jullie hebben een punt, derhalve had ik probleem ook tussen aanhalingstekens geschreven. Maar je moet je realiseren, als je 4 keer op een dag iets van 10 rss bestanden updatet (mogelijk in de toekomst zelfs meer), en dat gedurende een gehele maand... dan bespaart zo een controle je toch het één en ander aan het einde van de rit.

Ïk begrijp het toch niet helemaal. Je moet immers de feed binnenhalen om hem te controleren en dat kost dan toch de data? Dan maakt het verder niks uit of je de XML nou wel of niet vervangt toch? Of haal je hem soms nog een keer binnen na controle?

[ Voor 5% gewijzigd door mace op 28-04-2011 19:23 ]

[Verwijderd]

mace schreef op donderdag 28 april 2011 @ 19:22:
[...]

Ïk begrijp het toch niet helemaal. Je moet immers de feed binnenhalen om hem te controleren en dat kost toch data? Dan maakt het verder niks uit of je de XML nou wel of niet vervangt toch?

Dat klopt, het kan een verkeerde veronderstelling zijn van mijn kant, maar het wegschrijven van hetgeen dat binnengehaald is.. kost toch ook wat aan datalimiet?

[matthijsln]

Verwijderd schreef op donderdag 28 april 2011 @ 19:24:
[...]
Dat klopt, het kan een verkeerde veronderstelling zijn van mijn kant, maar het wegschrijven van hetgeen dat binnengehaald is.. kost toch ook wat aan datalimiet?

Normaal niet. Waarom zou dat zo zijn? Je slaat het neem ik aan op op dezelfde server die de rss feed heeft binnengehaald.

[RobIII]

Los van dat alles; waar hebben we het nou over Paar Kb'tjes, hooguit paar Mb per maand. Of je hebt el-cheapo-hosting-duppie-eerste-rang of je maakt je zorgen om niks. Beetje limiet begint pas bij Gb's te tellen. Elke seconde die je hier in steekt is al duurder dan je probleem. En meten == weten. Voordat je hier meer tijd in steekt; meet eens wat een enkele "run" kost, of een hele dag aan "runs" (als ik het goed begrijp kun je gewoon de filesize van de gecachete bestanden bij elkaar optellen) en vermenigvuldig dat met de juiste factoren en kijk dan eens waar we het over hebben.

Hadden we het nou over tientallen feeds die elke x minuten opgehaald werden dan was 't wellicht andere koek (en dan nog...).

Verder zie ik niet hoe je nou denkt dat "het wegschrijven van hetgeen dat binnengehaald is" wat "aan datalimiet" kan kosten.

/edit: Als je zaken gaat ophalen uit de feed (dus feedX bevat itemA, itemB etc. en je gaat vervolgens voor itemA en itemB weer een request doen) dan zou 't wellicht al iets anders liggen. In dat geval kun je natuurlijk, bij wijze van, de url's van itemA, itemB etc als "key" gebruiken en aan de hand daarvan + gewijzigde datum van dat item alsnog besluiten of je een item opnieuw moet ophalen of niet.

[ Voor 54% gewijzigd door RobIII op 28-04-2011 20:45 ]

[Verwijderd]

Excuus mensen, ik heb er te snel over nagedacht, het is inderdaad zoals jullie zeggen ietwat verspilling van de tijd, ik had de aanname gemaakt dat het wegschrijven van een feed óók datalimiet kost, maar dat is flauwekul natuurlijk als ik er achteraf over nadenk.. niettemin zou het toch 'mooi' zijn geweest, als een feed pas gecachet zou worden, als daar daadwerkelijk aanleiding toe was, maar goed, de moeite niet waard dus.

Topic mag op slot, hartelijk dank voor jullie antwoorden!

[RobIII]

Verwijderd schreef op donderdag 28 april 2011 @ 23:24:
Topic mag op slot, hartelijk dank voor jullie antwoorden!

Een slotje is niet nodig op een topic als je je oplossing hebt. Zie daarvoor ook onze faq betreffende topiceinde.

[Gomez12]

Verwijderd schreef op donderdag 28 april 2011 @ 23:24:
Excuus mensen, ik heb er te snel over nagedacht, het is inderdaad zoals jullie zeggen ietwat verspilling van de tijd, ik had de aanname gemaakt dat het wegschrijven van een feed óók datalimiet kost, maar dat is flauwekul natuurlijk als ik er achteraf over nadenk.. niettemin zou het toch 'mooi' zijn geweest, als een feed pas gecachet zou worden, als daar daadwerkelijk aanleiding toe was, maar goed, de moeite niet waard dus.

Wat je (voor de volgende keer) wel kan overwegen is om een standaard script oid te pakken wat gewoon dit ondersteund ipv zelf het wiel opnieuw willen uitvinden.

RSS-imports zijn nou niet echt rocket science die je zelf helemaal handmatig moet uitpluizen en uitvogelen, dat is gewoon een redelijk gestandaardiseerd protocol waar al tig aggregators ed voor geschreven zijn.