вопрос сравнения многопроцессорной и витой

1

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

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

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

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

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

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

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

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

-Tom

Теги:
multiprocessing
twisted

2 ответа

2

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

Concurrency: либо витая, либо многопроцессорная обработка выполняет работу по одновременной обработке заданий на выборку/разборку. Я не уверен, где же происходит ваше предположение о "Twisted overhead". Напротив, многопроцессорный путь может повлечь за собой дополнительные накладные расходы, так как должен быть создан (относительно тяжелый) OS-процесс. Способы обработки Twisteds concurrency гораздо более легкие.

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

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

1

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню