Ответ 1

• Использовать кеш HTTP. Отправляйте заголовки Etag и LastModified. Признать ответ 304 Not modified. Таким образом, вы можете сэкономить много полосы пропускания. Кроме того, некоторые скрипты распознают заголовок LastModified и возвращают только частичное содержимое (т.е. Только два или три новых элемента вместо 30 или около того).

• Не проводите опрос RSS из сервисов, поддерживающих RPC Ping (или другой сервис PUSH, например PubSubHubbub). То есть если вы получаете оповещения PUSH от службы, вам не нужно проводить опрос данных в стандартном интервале - делать это один раз в день, чтобы проверить, работает ли механизм или нет (ping можно отключить, перенастроить, повредить и т.д.). Таким образом, вы можете получать RSS только при получении уведомлений не каждый час или около того.

• Проверьте заголовок TTL (в RSS) или кеш-памяти (Expires в ATOM) и не извлекайте, пока ресурс не истечет.

• Попробуйте адаптироваться к частоте новых элементов в каждом отдельном RSS-канале. Если на прошлой неделе было только два обновления в определенном фиде, не отправляйте его более одного раза в день. AFAIR Google Reader делает это.

• Уменьшите скорость в ночное время или в другое время, когда трафик на вашем сайте низкий.

• Наконец, делайте это один раз в час.;)

Ответ 2

Google FeedFetcher утверждает, что опрос rss-канала немного меньше одного раза в час.

От: http://code.google.com/apis/ajaxfeeds/documentation/

Частота сканирования скачка

Поскольку API-интерфейс AJAX Feed API использует Feedfetcher, данные фида из API фида AJAX могут не всегда обновляться. Поисковый робот Google (Feedfetcher) извлекает каналы с большинства сайтов менее одного раза в час. Некоторые часто обновляемые сайты могут обновляться чаще.

Ответ 3

Хорошо, я собираюсь пойти туда, проигнорировав сообщения, которые говорят "Google говорит, что мы делаем", и говорим: так часто, как вам реально нужно.

RSS, чтобы вы были в курсе событий. Если фид публикует 10 предметов в час, но только показывает пять, вы пропустите пять из этих предметов, и фид не будет служить своей цели. Вы могли бы вообще не ударить его.

Конечно, вы не можете забивать сервер запросами, но если они публикуют достаточно, чтобы вы запрашивали один раз в минуту, я не вижу, как это необоснованно соответствовать этой скорости.

Ответ 4

Один раз в час, если вы хотите просто пойти по правилу большого пальца (но ссылка объясняет некоторые лучшие варианты).

Ответ 5

Однажды час - это частота, которую я слышал.

Ответ 6

Rss имеет в нем параметр ttl, так что вам следует только опросить, когда истекает срок действия TTL.

Но я думаю, если они не ставят один в своей проблеме, и вы должны опросить что-то вроде одного часа

Ответ 7

Это не полный ответ, но обратите внимание на push-оповещения.

В блоге RSS указано, что наилучшая практика задает weblogs.com об измененных блогах.

Существует также некоторый, er, hubbub, pubsub, способ подписаться на push-оповещения, которые имеют некоторый импульс.

Ответ 8

Я отмечаю, что twitter использует (пользовательские) заголовки X-RateLimit-Remaining и X-RateLimit-Limit (в ответе HTTP), чтобы указать максимальное количество разрешенных опросов для фидов Atom. Как-то жаль, что они не использовали стандартное поле Expires (которому было установлено 30 лет в прошлом: P). Я думаю, их реклама Cache-Control: no-cache также исключает общее время истечения срока годности, определенное в RFC 2616 (раздел 13.2. *). Еще более жаль, что Atom, похоже, не предоставляет стандартизованного способа рассказать, как часто предлагается опросить фид.