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

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

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

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

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

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

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

Матф

Ответы на вопрос(3)

Ваш ответ на вопрос