Парсинг чужих сайтов во имя добра)

[Jons]

Парсинг чужих сайтов во имя добра)

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

Задача 1
Человек вводит адрес своего сайта и нам нужно выдать "карту его сайта" для дальнейших действий.
Вопрос собственно в том как лучше эту самую карту чужого сайта можно сформировать в случае если у человека нет специализированных xml или еще каких-либо видов правильной карты сайта?
Топорное решение "в лоб" парсим страничку, ищем все <a href="{user_server}"> и так до тех пор пока... Но ведь очевидно что таким образом мы сможем пропарсить скажем 10-100-1000 страничный сайт... А как быть с гигантами? Да и к тому же сервису по идее нужно знать только о самых "главных" разделах вводимого сайта, то есть можно сократить задачу например до нахождения всех ^userdomain.ru/(.*)/$

Задача 2
Собственно работа со страницами пользовательских сайтов. Необходимо на странице искать совпадение по N регулярных выражений и N точных совпадений. Как это оптимально сделать и какие могут быть подводные камни?

Задача 3
Мониторинг аптайма сайтов. Каким образом лучше реализовать? Чем плохо если делать это pingом из операционной системы?
Скажем как лучше проверять ежеминутно 100 сайтов на предмет их доступности?

Any ideas? Надеюсь выразил мысли ясно

 

[Крот]

Задача 1

Быстро обойти ботом (в пределах того времени, пока вебмастер захочет ждать результатов) разумеется не получится. Если парсить разделы сайта по маскам, то эти маски тоже ведь нужно знать. Может быть такое разнообразие урлов, что свихнуться можно... Проще по-моему парсить выдачу гугля на проиндексированные страницы конкретного сайта и на их основе строить уже что-то типа карты. Доп. плюсом будет являться то, что эта информация действительно полезна вебмастеру, т.к. косвенно показывает отношение поисковика к сайту. Также можно пробовать искать sitemap.xml сайта, но в случае очень больших сайтов ты опять же наткнешься только на кучу архивов, которые абсолютно бесполезны.


Задача 2

А тут, по-моему, как-бы нет никаких подводных камней. Задача решается влоб и никак по-другому.


Задача 3

Смотря что ты понимаешь под аптаймом сайта. Сайт может лежать, например 503 ошибка, но при этом сервер будет пинговаться. Если ты хочешь мониторить именно аптайм сервера, то демон с пингами; если хочешь мониторить состояние сайта - совсем другая задача, гораздо более трудоёмкая, как мне кажется...

-~{}~ 22.10.09 12:01:

PS: Причем тут PHP&MySQL?

 

[С.]

Очень странное решение садиться за сервис для вебмастеров слабо представляя, как этот самый веб работает. Может начать с чего попроще? А тем делом и школу закончите.

 

[Jons]

Крот
Спасибо за совет про гугл по первой задаче, довольно интересно...
По 3ей сейчас и подразумеваем демоном, который будет ловить 200ый ответ.

С.
У вас школофобия.

 

[iceman]

вот не задача, у меня такие урлы, что будешь делать?
http://domain/apex/f?p=710:11:3651275569187396::NO:1111_USER_ID,P11_PREV_PAGE:4%2C10

 

[Фанат]

хехе, мне тот же вопрос пришел в голову, что и С.

 

[Alexandre]

Чем плохо если делать это pingом из операционной системы?

тем что сайт может лежать а пинг стоять! (протоколы разные)

Скажем как лучше проверять ежеминутно 100 сайтов на предмет их доступности?

открыть 20 или 50 потоков, определяется опытным путем и зависит от числа ядер и канала.
в моей практике - ведется статистика на "доступность сайтов и ширину каналов" и сперва мониторятся "быстрые" а потом "медленные" сайты. Только у меня немного иная задача: закачка контента, но применима и для твоей приктике.

кстати о пинге: сперва можно пропинговать, а потом проверить на доступность index.html ( образно), корень сайта или любую стр, которую укажет пользователь.

вообще, сервис должнен обладать соответствующими мощностями, возможно должна быть распределенная архитектура.