вопрос сравнения многопроцессорной и витой - PullRequest
1 голос
/ 31 июля 2010

Возникла ситуация, когда я собираюсь разбирать сайты. у каждого сайта должен быть свой собственный "парсер" и, возможно, свой собственный способ работы с файлами cookie и т. д.

Я пытаюсь понять, что было бы лучшим выбором.

Выбор I: Я могу создать многопроцессорную функцию, в которой приложение (masterspawn) получает URL-адрес ввода и, в свою очередь, охватывает процесс / функцию в приложении masterspawn, которое затем обрабатывает все настройки / выборки / синтаксический анализ страницы / URL.

При таком подходе будет запущено одно главное приложение, и оно, в свою очередь, создаст несколько экземпляров внутренней функции. Должно быть быстро, да / нет?

Выбор II: Я мог бы создать сервер типа «Twisted», который по сути делал бы то же самое, что и Вариант I. Разница в том, что использование «Twisted» также накладывало бы некоторые издержки. Я пытаюсь оценить Twisted с точки зрения того, что он является «Сервером», но он мне не нужен для получения URL-адреса.

Выбор III: Я мог бы использовать скрап. Я склонен не идти по этому пути, так как я не хочу / не должен использовать накладные расходы, которые, как представляется, имеет место скрапинг. Как я уже говорил, каждому из целевых URL-адресов нужна своя функция разбора, а также работа с файлами cookie ...

Моя цель в основном состоит в том, чтобы "архитектурное" решение было распределено по нескольким блокам, где каждый клиентский ящик взаимодействует с главным сервером, который выделяет URL для анализа.

спасибо за любые комментарии к этому ..

-Tom

Ответы [ 2 ]

2 голосов
/ 01 августа 2010

В этом вопросе есть два аспекта: параллелизм и распределение.

Параллельный режим: Twisted или многопроцессорная обработка будут выполнять работу по одновременной обработке заданий извлечения / анализа. Я не уверен, однако, откуда взялась ваша предпосылка «Скрученных накладных расходов». Напротив, многопроцессорный путь потребовал бы гораздо больше затрат, так как пришлось бы порождать (относительно тяжелый) процесс ОС. Способ обработки параллелизма в Twisteds гораздо более легкий.

Распределение: многопроцессорная обработка не будет распределять ваши задания выборки / разбора по разным блокам. Twisted может сделать это, например. используя средства построения протокола AMP.

Я не могу комментировать скрап, никогда не использовав его.

1 голос
/ 01 августа 2010

Для этого конкретного вопроса я бы выбрал многопроцессорность - он прост в использовании и понятен. Вам не нужно особенно скручивать, так зачем взяться за дополнительное осложнение.

Еще один вариант, который вы можете рассмотреть: использовать очередь сообщений. Имейте главные перетаскиваемые URL-адреса в очередь (например, beanstalkd , resque , 0mq ), и рабочие процессы собирают URL-адреса и обрабатывают их. Вы получите как параллелизм, так и распределение: вы можете запускать рабочих на любом количестве машин.

...