Если сравнивать брокеры сообщений — они все примерно похожи на AMQP. Если смотреть на другие варианты очередей (beanstalkd, Kafka, и т.п.) — это другие решения с другими характеристиками. ØMQ — обмен сообщениями без брокера.
Лучше смотреть на картинку «Deferred в квадрате», и рассматривать Deferred2 как отдельный поток, который начинается выделением ресурса (т.е. к моменту прихода на уровень callback2_1 ресурс уже выделен).
У Deferred есть метод .addBoth, который добавляет один и тот же обработчик на оба слота (callback/errback) на одном уровне. Это модель try...finally, который и используется для гарантированного освобождения ресурса при любом исходе.
Мой комментарий относился ни к скорости создания нитей, ни к красоте кода.
В общем случае, чистый код в нитях (без другой модели программирования, например Actor в Erlang) крайне труден в поддержке/разработке из-за наличия тех или иных синхронизаций, число которых для получения приемлемой скорости растет.
Дело было примерно так — автор Tornado пытался понять Twisted, писал в список рассылки, спрашивал. Но так и не понял и сделал Tornado. Видимо, такова его ниша (Tornado) и такое «упрощенное» решение имеет право на существование.
Без обид. Просто другой взгляд на вещи.
Поэтому я думаю сравнение технологий без определения критериев и конкретных метрик бесмысленно.
Уточню: гораздо меньший битрейт за счет использования хорошего кодека, и возможность экспортировать записанные видео в родную Фотогаллерею айФона — где появляется возможность тримить видео и загружать его на РС.
А так вообще на джейлбрекнутых айФонах можно пользоваться намного лучшим API по захвату видео, соотв. FPS (кадров в секунду) там всегда будет лучше пока Apple нормальный API не откроет.
На самом деле это не такой маленький список. Для работы Qik нужна в телефоне качественная камера, а для live неплохой канал: WiFi/3G/Edge. Поэтому поддержать совершенно любой телефон смысла нет, но мы постоянно занимаемся расширением перечня моделей телефонов, на которых Qik работает.
Мне трудно сказать, я не эксперт в Erlangе, знаю, что там замечательный внутренний messaging. Чаще всего рано или поздно придется интегрироваться с другими системами, написанными на чем-то еще. И вот тогда «прослойка» в виде AMQP-брокера может очень даже пригодится.
P.S. RabbitMQ (AMQP-брокер) как раз написан на Erlang.
Сергей, может быть Вам подойдет и Ваша система. Наверное, она работает.
Просто аудитория Хабра состоит в том числе и из тех, кто еще еще только собирается написать свою систему кэширования. И было бы лучше, если бы они учились на более правильных примерах, чем Ваш. Чтобы они не набивали свои собственные шишки, а воспользовались уже готовыми решениями.
Как использовать более «правильные» подходы к кэшированию? Я бы советовал взять, например, библиотеку Котерова. Или посмотреть продвинутые frameworkи кэширования, например, в рельсах. Может, кто еще из Хабровчан расскажет о хороших примерах, я доступных примеров больше не знаю, к сожалению.
Сам сервер однопотоковый, это сильно упрощает дизайн и облегчает производительность (event-driven). RTMP как таковой с трудом можно разделить на нормальную многопоточную обработку, в отдельный поток можно вынести независимую задачу (например, перекодирование видео). План состоит в создании автоматически (или полуавтоматически) кластеризуемого решения. Тогда на одном сервере запускаем столько FMSPy, сколько там ядер. Используем столько серверов, сколько нам нужно. Все это работает как единый организм, распределяя нагрузку внутри себя так, чтобы все сервера были загружены примерно одинаково.
Сергей, я не претендую на авторство в вопросе тэгирования. Скорее, это мы с Димой Котеровым почти независимо пришли. Я лишь хочу сказать, что надо пробовать что-то лучшее сегодня уже. Гораздо проще начинать с хорошего, когда оно уже опробовано кем-то и описано.
Так что, даешь новую статью про улучшенную Вами же Вашу систему кэширования!
Если брать Wowza/FMS — все-таки есть уверенность, что нужно open-source решение, которое бы позволяло технологию вперед. У FMS/Wowza есть свои проблемы с надежностью и не всегда полной поддержкой.
Если брать Red5/rtmpy/Milenia Grafter и другие open-source проекты: Red5 — тормозит и глючит (опыт реального использования под нагрузкой). С моей точки зрения это монстр, который может жить только в руках создателей. Rtmpy — на начальном этапе развития, у FMSPy есть общий код с ним, близкие проекты. Но путь Rtmpy меня не устраивает. Milenia как-то тихо загибается в непонятном пути развития.
RTMP — очень полезная технология, которая может иметь множество применений. Нужно только ее развитие. FMSPy — это не только сервер RTMP, это еще и протокол RTMP, который можно использовать в любом Twisted-приложении.
Ну, наверное, это не совсем то, что должно входить в ядро FMSPy. Это типичная задача для приложения к FMSPy: мы получаем по RTMP потоковый звук от пользователя, на сервере проделываем микширование и выдаем (публикуем) в качестве стрима. В FMSPy должны быть все возможности для этого: захват живого стрима, публикация стрима. Микширование и кодирование/декодирование потока, наверное, будет выходить за рамки FMSPy, но для этого стоить использовать готовые возможности Python, например, интерфейс с GStreamer.
Тестируйте, пожалуйста, устанавливайте, пробуйте, ищите баги и т.п.! Все, что получится, пишите в трекер на fmspy.org/ в виде тикетов. (Чтобы создать тикет, надо зарегистрироваться). Спасибо!
Если я правильно понял автора, то, что он предлагает является вырожденным случаем тэгирования кэшей. При этом некоторые утверждения в статье, как писали уже выше в комментариях, являются как минимум спорными.
Эффективность описанной системы кэширования должна быть низкой, если ничего не путаю по тексту, то при изменении любой таблицы сбрасываются все кэши, затрагивающие эту таблицу. Такой подход не может работать на реальном проекте. Изменение таблицы коментов на Хабре не должно приводить сбросу всех кэшей комментариев ко всем статьям. В крайнем случае — только к той статье, к которой был добавлен/удален/изменен комментарий.
Как раз задачи минимизации сброса кэшей является актуальной, кэши должны сбрасываться редко (они должны быть так устроены). Опять-таки, если я не путаюсь в мыслях автора, он предлагает перейти от сброса «всех вообще кэшей» при любом изменении к сбросу «всех кэшей, связанных с таблицей, при изменении таблицы». Ммм… это каменный век кэширования! Давайте двигаться вперед! :)
Пока не допишем, ясно не будет. Целью является сопоставимая или лучшая производительность. Хотя непосредственно оптимизация в планах отложена на чуть более поздний этап оп времени.
Nerezus, вы можете помочь! Если не непосредственно участием в разработке, то, например, организацией тестирования производительности. Мы (все вместе) смогли бы несомненно сделать его лучше.
Я не думаю, что разработка может быть быстрее на Java или каком-то еще языке программирования. Современные framework'и дают примерно равное время разработки (объем усилий).
Это делается на Python, потому что для меня так удобнее. Я не вижу недостатков такого решения (или знаю как такие недостатки обойти).
1. Таймаут нужен там, где он может произойти, ну, например, вызов connect(). Если он завершится ошибкой, надо в цепочку Deferred запустить Failure, т.е. обычное исключение. Таймаут не отличается от разрыва соединения и т.п. Twisted это умеет.
2. Не несет существенного, она очень-очень простая. Полторы страницы кода (Python). Научиться ей пользоваться и думать в её терминах сложнее, но реализация простая и эффективная.
По умолчанию Twisted биндится на все интерфейсы, возможно это у него не получается, и надо ему сказать выбирать конкретный адрес (интерфейс). Ну и на всякий случай не-рутовые приложения не могут получить порт ниже 1024.
По сути, twisted-приложение — это обычное питоновское приложение. Если есть python, есть возможность запускать процессы «в фоне» (есть шелл), есть возможность установить питоновский пакет (twisted), есть возможность забиндиться на порт и т.п., то приложение будет работать. Для этого нужен выделенный сервер или виртуальный выделенный сервер (т.е. наличие своего IP, шелла и т.п.). Рутовый доступ как таковой не нужен, если есть Python, все пакеты можно установить и в свой домашний каталог.
Насчет Java ничего не знаю, к сожалению… Twisted, насколько я знаю, близок к тому, чтобы работать под Jython, т.е. в каком-то плане может быть доступно.
Самая большая проблема для статически типизированных языков — построение цепочки callbackов, на C++ в реализации самая большая проблема именно с этим, там жуткие шаблоны ;)