Skip Evans wrote:
I'm doing some maintenance work on a site that allows members to keep
a personal library of podcasts.
One thing the site does it every time the personal list of casts is
viewed, it goes out and gets the most current episode information for
each cast in the user's list, but this slows the display of the page
down quite a bit, not too bad for 6 or 8 casts, but if the user's
start adding many more than that it gets noticably slower.
My idea is a cron job that runs in the background that checks to see
when the last time a cast was updated with episode data, and if a
preconfigured amount of time has lapsed, it reads the XML file and
udpates the DB.
Having never dealt with podcasts before, I'm feeling a bit like I'm
flying blind, so the issues I'm wondering about are:
1) Some podcasts are updated weekly, others daily, etc, so updating a
weekly podcast every few hours would be overkill.
A well-formed feed should have a TTL value that defines how often the
feed should be checked.
2) Reading the XML file from the source feed is time consuming. If the
site ends up with thousands of casts, this could pretty much kill the
cron job.
Make sure you make use of the If-Modified-Since HTTP header when
requesting the feed. Make and store a hash of the feed contents (before
parsing) and use that to see if the feed has changed. Add using the TTL
value (if there is one) and that will ensure you only parse the feed
when it changes.
I'm wondering if anyone on the list has dealt with this kind of thing
and what kind of strategies were employed.
That's basically it. I'm assuming that you're only storing the data for
each feed once even if several users are subscribed to it.
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
