Асинхронное порождение процессов: вопрос дизайна - сельдерей или витая - PullRequest
6 голосов
/ 08 января 2011

Все: я ищу вход / руководство / и идеи дизайна. Моя цель - найти простой, но надежный способ извлечь полезную нагрузку XML из HTTP POST (без проблем с этой частью), проанализировать ее и запустить относительно долгоживущий процесс асинхронно.

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

Мне очень нравится стек Celery / Django для этого использования: он очень интуитивно понятен и имеет все встроенные средства для выполнения именно того, что мне нужно. Я пошел по этому пути с усердием, но вскоре обнаружил, что мой маленький облачный сервер ОЗУ объемом 512 МБ имел только 100 МБ свободной памяти, и я почувствовал, что у меня возникли проблемы, когда я начал работать со всеми своими процессами, работающими в полном наклоне. Также у него есть несколько движущихся частей: RabbitMQ, MySQL, cerleryd, ligthttpd и контейнер django.

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

В качестве альтернативы я рассматриваю возможность использования витой для управления процессами, а также перспективного брокера для удаленных систем, если они понадобятся. Но, по крайней мере, для меня, хотя витая система великолепна, я чувствую, что подписываюсь на многое, идущее по этому пути: написание протоколов, управление обратными вызовами, отслеживание состояний заданий и т. Д. Преимущества здесь довольно очевидны - отличная производительность гораздо меньше движущихся частей и меньший объем памяти (примечание: мне нужно проверить часть памяти). Я сильно склонен к Python из-за этого - это гораздо приятнее для меня, чем альтернативы:)

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

Матф

Ответы [ 3 ]

5 голосов
/ 08 января 2011

В моей системе RabbitMQ, работающий с довольно разумными значениями по умолчанию, использует около 2 МБ ОЗУ.Celeryd использует немного больше, но не чрезмерное количество.

По моему мнению, издержки RabbitMQ и сельдерея в значительной степени незначительны по сравнению с остальной частью стека.Если вы обрабатываете задания, выполнение которых займет несколько минут, именно эти задания будут перегружать ваш 512 МБ сервер при увеличении трафика, а не RabbitMQ.Начиная с RabbitMQ и Celery, по крайней мере, вы будете хорошо настроены для горизонтального масштабирования этих заданий, так что вы определенно на правильном пути.

Конечно, вы можете написать свой собственный контроль заданий в Twisted,но я не вижу, чтобы это принесло вам много пользы.Twisted имеет довольно хорошую производительность, но я бы не ожидал, что он превзойдет RabbitMQ настолько, чтобы оправдать время и потенциал для появления ошибок и архитектурных ограничений.В основном, это не то место, чтобы беспокоиться об оптимизации.Потратьте время, которое вы бы потратили на переписывание RabbitMQ, и постарайтесь сократить эти три минуты работы на 20% или около того.Или просто потратить лишние 20 долларов в месяц и удвоить свои возможности.

0 голосов
/ 29 июля 2014

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

Тип «Список» очень полезен: http://www.redis.io/commands/rpoplpush

Таким образом, вы можете использовать Шаблон надежной очереди для отправки работы ипроцесс, который блокирует / ждет, пока у него не появится новая работа (новое сообщение, поступающее в очередь.

, вы можете использовать несколько рабочих в одной очереди.

У Redis недостаточно памятиследите за количеством ожидающих сообщений, это увеличит объем памяти, используемой Redis.

0 голосов
/ 08 января 2011

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

Идея состоит в том, чтобы веб-сервер работал постоянно (здесь не требуется очень мощная машина).Однако работа выполняется этими клиентами-заказчиками, которые являются более мощными машинами, которые можно запускать и останавливать по желанию.Очередь заданий также будет находиться на том же компьютере, что и веб-приложение.Когда задание вставляется в очередь, процесс, запускающий клиентов задания, запускается в действие и запускает первого клиента.Используя балансировщик нагрузки, который может запускать новые серверы по мере увеличения нагрузки, мне не нужно беспокоиться об управлении количеством серверов, работающих для обработки заданий в очереди.Если через некоторое время в очереди не будет заданий, все клиенты заданий могут быть прерваны.

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

...