Xpoint
   [напомнить пароль]

Алгоритм подсчета TTL для фидов

Метки: [без меток]
[арх]
2007-03-13 19:11:59 [обр] Сергей Чернышев(39/589)[досье]

У меня есть скрипт, который собирает RSS-фиды из разных источников и кладет их в базу данных.

Моя задача состоит в том чтобы делать запросы к удаленным серверам как можно реже.

На данный момент я храню TTL задынный в фиде (мало кто его ставит) а также заголовок Last-modified и E-tag. Кроме того у меня есть минимальный TTL, чаще которого я не хочу ходить за одним и тем же фидом дабы не раздражать сервер.

Проблема состоит в том, что очень часто те кто выдает фиды не только TTL не прописыают, но и Last-modified/E-tag не выставляют, а некоторые даже динамически генерят контент фидов и когда там находятся баннеры, то приходится сначала фид пропарсить и только потом сверить guid-ы записей (которые тоже не всегда присутствуют).

Итого, мне хочется оптимизировать алгоритм и пытаться апроксимировать время следующего запроса к серверу на основе данных о том, с какой частотой в этом фиде появлялись записи раньше.

Так как я храню достаточно долгую историю фида, думаю, что у меня есть достаточно данных, но хотелось бы посмотреть на то как подобные задачи уже решались.

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

спустя 3 часа 57 минут [обр] Давид Мзареулян(31/1003)[досье]

Зависит от конкретной специфики фидов… Когда я обдумывал похожую штуку (для rss-ок блогов), я планировал такой алгоритм: после обновления фида (появления в нём новой записи) следующая проверка происходит через короткое время T (порядка минут), потом через 2T, потом через 4T и так далее до некоторого Tmax (порядка часов). Далее проверка производится один раз в этот самый Tmax — пока не появится следующая. Это позволяет оперативно ловить моменты, когда человек добрался до компьютера и, вероятно, напишет не один пост подряд. Но это только один из вариантов, заточенный под конкретную модель поведения автора блога.

А для дешёвой (по вычислению и хранению) оценки частоты обновления фида могу порекомендовать такой алгоритм: http://david-m.livejournal.com/729349.html

спустя 20 часов [обр] Сергей Чернышев(39/589)[досье]

Давид Мзареулян[досье]
Подумаю над вашим первым вариантом, хотя минуты меня не устраивают практически совсем.

Про ссылку на описание алгоритма, а не очень понял как алгоритм отлова часто-запрашивающих юзеров поможет мне в решении проблемы написания умного ридера. Пожалуйста объясните аналогию.

Опять же повторюсь - я знаю историю фида и с какой частотой тот обновлялся ранее и хочу использовать эту информацию для минимизации кол-ва запросов. Естественно, поймать обновление вовремя, тоже важно, но минимизировать кол-во запросов важнее - объемы будут исчисляться миллионами фидов и хоть я и собираюсь делать распределенный процесс, все равно траффик нужно будет оптимизировать.

Кстати, Давид, а вы не думали про анализ информации из пингеров?

спустя 2 часа 45 минут [обр] Давид Мзареулян(31/1003)[досье]
сообщение промодерировано
Про ссылку на описание алгоритма, а не очень понял как алгоритм отлова часто-запрашивающих юзеров поможет мне в решении проблемы написания умного ридера. Пожалуйста объясните аналогию.
Алгоритм позволяет дёшево определить среднюю частоту некоторых событий. Что это за событие — коннект с определённого IP или появление новой записи в определённом фиде — алгоритму совершенно не важно.
спустя 4 дня [обр] Сергей Чернышев(39/589)[досье]
Ну, я так и понял - просто меня смутило что задача противоположна описаной мной.
Powered by POEM™ Engine Copyright © 2002-2005