Fork me on GitHub
5/6/2011

Слияние

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

Добавляйте в закладки:

1/11/2010

Mongrel2

Если бы не Александр Соловьев, то я бы прошел мимо Mongrel2. А всё потому, что первый Mongrel был Ruby-специфичным инструментом и никогда особо меня не интересовал.

Другое дело Mongrel2. Во-первых, он написан на C. Во-вторых, он не привязан ни к какому из языков. В-третьих, он использует ZeroMQ как транспорт.

По сути, Mongrel2 это балансирующий прокси, который парсит http и отдает запросы в виде сообщений в ZeroMQ и так же получает ответы.

Mongrel2 интересен несколькими моментами.

Быстрый. Все операции по парсингу http (сам Mongrel2) и передачи сообщений (ZeroMQ) берет на себя быстрый C-код.

Не привязан к языкам По сути, всё что вам нужно, чтобы начать работать с mongrel - это биндинг к ZeroMQ, которые есть для всех более-менее мажорных языков. Так что используя любой язык для работы с Mongrel (Erlang, Python, Ruby, Lua), вы уже получаете распарсенный запрос, причем с гарантией, что не получите специфичных для данного языка багов.

Асинхронные сообщения Это самая интересная фишка Mongrel2 и тут стоит остановиться чуть подробнее.

Дело в том, что современные балансировщики нагрузки работают как сервисы «переднего края», принимающие запросы, и как «командные центры», которые опеределяют, какому бэкенду следует отправить данный запрос. Как следствие, при добавлении бэкенда нужно донастраивать балансировщик.

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

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

Бэкенд является демоном, который подписывается на определенные сообщения в ZeroMQ, при получении обрабатывает и по готовности ответа шлет другое сообщение, на которое уже подписан Mongrel2. Если говорить о WSGI, то нужен коннектор между Mongrel2/ZeroMQ и WSGI-приложением (он вроде бы есть, и даже не в единственном экземпляре, но код OMG-OMG).

Итог. У Mongrel2 интересная концепция и он обещает быть весьма полезным на практике. Я бы не рискнул сейчас его ставить в продакшн, но вот поиграться — вполне.

P.S. А еще у Mongrel2 конфиг в SQLite :)

28/10/2010

В очередь

Enqueue it. Yury Yurevich - oDesk corp. - @yurevich.

Эти слайды изначально были подготовлены для доклада в формате Печа Куча для PyCon UA, 24 октября 2010 года.

Web application like a tennis game

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

But what if task doesn't fit?

Но что если задание не "влезает" в цикл запрос-ответ. Например, вам нужно отправить несколько сотен писем, или послать твит, а твиттер перегружен, вариантов множество

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

Light weight

Естественно, вначале хочется чего-то очень простого, без дополнительных сервисов и зависимостей, например, чтобы использовалось основное хранилище данных приложения.

Плохая новость…

I don't know such

Я таких инструментов не знаю.

Хорошая новость в том, что я знаю, где отложеннные задания и очереди уже есть…

Google AppEngine

Это Google App Engine

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

Middle weight

Если рассматривать что-то более серьезное, что требует внешнего хранилища…

pyres

То в этой категории мне очень нравится pyres. Он прост и незатейлив, но покрывает весь необходимый функционал. Он как любимая отвёртка, которая просится к вам в руку.

pyres: redis backend

Pyres использует Redis как хранилище заданий и очередей. Я думаю, вы уже всё знаете о Redis благодаря великолепным докладам Эндрю Годвина, Саймона Виллисона и Александра Соловьева.

pyres: web interface

У pyres отличный веб-интефейс в котором вы видите работающих worker'ов, актуальные очереди, задания с ошибками. Вы можете сделать retry таким заданиям или удалить их. И конечно это WSGI, так что проблем с интеграцией с существуещим приложением не будет.

pyres: compact

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

Pyres действительно хорош и в 90% вам просто не нужны те фичи, которых нет.

Heavy weight

Конечно, существуют и более функциональные системы, где всё по-взрослому.

Celery

И, конечно, первую скрипку на этой сцене играет Celery. В нем много всего: много бэкендов, много фич, много документации и, как следствие, много кода.

Celery: backends

Celery по умолчанию поддерживает AMQP-бэкенд и рекомендует использовать RabbitMQ. Но через специальный адаптер работает и с redis (мой выбор), ZeroMQ и многими другими.

Celery: features

У Celery есть очень интересные возможности: он позволяет не только выполнять отложенные задания, но планировать их выполнение и выполнять их периодически; умеет работать с веб-хуками, так что он не ограничивает клиентов толкьо Python; он умеет ограничивать частоту выполнения заданий; ему можно настроить повтор определенных заданий; группировать задания в "тасксеты" и хранить результаты выполнения используя различные бэкенды.

Celery: features

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

Appendix

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

Enough bicycles!

Друзья, я прошу вас использовать, развивать, рекламировать, пропагандировать уже существующие решения. Они действительно хороши. Хватит наколенных поделок и велосипедов!

Thanks

Спасибо за внимание. Если у вас есть вопросы или комментарии к слайдам — воспользуйтесь FriendFeed ;)

Credits

Спасибо Flickr и Creative Commons за великолепные фото.

26/10/2010

PyCon в Украине: результат

20/9/2010

PyCon в Украине!

17/7/2010

Мельком о Buildout

27/6/2010

MarginCon '10

23/5/2010

Впечатление от DevPoint

15/4/2010

Генераторы статических блогов

5/3/2010

Полезные библиотеки для Django

Все статьи