Сергей, может быть Вам подойдет и Ваша система. Наверное, она работает.
Просто аудитория Хабра состоит в том числе и из тех, кто еще еще только собирается написать свою систему кэширования. И было бы лучше, если бы они учились на более правильных примерах, чем Ваш. Чтобы они не набивали свои собственные шишки, а воспользовались уже готовыми решениями.
Как использовать более «правильные» подходы к кэшированию? Я бы советовал взять, например, библиотеку Котерова. Или посмотреть продвинутые 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++ в реализации самая большая проблема именно с этим, там жуткие шаблоны ;)
Просто аудитория Хабра состоит в том числе и из тех, кто еще еще только собирается написать свою систему кэширования. И было бы лучше, если бы они учились на более правильных примерах, чем Ваш. Чтобы они не набивали свои собственные шишки, а воспользовались уже готовыми решениями.
Как использовать более «правильные» подходы к кэшированию? Я бы советовал взять, например, библиотеку Котерова. Или посмотреть продвинутые frameworkи кэширования, например, в рельсах. Может, кто еще из Хабровчан расскажет о хороших примерах, я доступных примеров больше не знаю, к сожалению.
Так что нет, GIL не смущает.
Так что, даешь новую статью про улучшенную Вами же Вашу систему кэширования!
Если брать Red5/rtmpy/Milenia Grafter и другие open-source проекты: Red5 — тормозит и глючит (опыт реального использования под нагрузкой). С моей точки зрения это монстр, который может жить только в руках создателей. Rtmpy — на начальном этапе развития, у FMSPy есть общий код с ним, близкие проекты. Но путь Rtmpy меня не устраивает. Milenia как-то тихо загибается в непонятном пути развития.
RTMP — очень полезная технология, которая может иметь множество применений. Нужно только ее развитие. FMSPy — это не только сервер RTMP, это еще и протокол RTMP, который можно использовать в любом Twisted-приложении.
Из неопубликованного есть автоматически сгененированная документация по коду, ее можно и самому легко собрать — git clone, make docs
Если я правильно понял автора, то, что он предлагает является вырожденным случаем тэгирования кэшей. При этом некоторые утверждения в статье, как писали уже выше в комментариях, являются как минимум спорными.
Эффективность описанной системы кэширования должна быть низкой, если ничего не путаю по тексту, то при изменении любой таблицы сбрасываются все кэши, затрагивающие эту таблицу. Такой подход не может работать на реальном проекте. Изменение таблицы коментов на Хабре не должно приводить сбросу всех кэшей комментариев ко всем статьям. В крайнем случае — только к той статье, к которой был добавлен/удален/изменен комментарий.
Как раз задачи минимизации сброса кэшей является актуальной, кэши должны сбрасываться редко (они должны быть так устроены). Опять-таки, если я не путаюсь в мыслях автора, он предлагает перейти от сброса «всех вообще кэшей» при любом изменении к сбросу «всех кэшей, связанных с таблицей, при изменении таблицы». Ммм… это каменный век кэширования! Давайте двигаться вперед! :)
Nerezus, вы можете помочь! Если не непосредственно участием в разработке, то, например, организацией тестирования производительности. Мы (все вместе) смогли бы несомненно сделать его лучше.
Это делается на Python, потому что для меня так удобнее. Я не вижу недостатков такого решения (или знаю как такие недостатки обойти).
2. Не несет существенного, она очень-очень простая. Полторы страницы кода (Python). Научиться ей пользоваться и думать в её терминах сложнее, но реализация простая и эффективная.
По сути, twisted-приложение — это обычное питоновское приложение. Если есть python, есть возможность запускать процессы «в фоне» (есть шелл), есть возможность установить питоновский пакет (twisted), есть возможность забиндиться на порт и т.п., то приложение будет работать. Для этого нужен выделенный сервер или виртуальный выделенный сервер (т.е. наличие своего IP, шелла и т.п.). Рутовый доступ как таковой не нужен, если есть Python, все пакеты можно установить и в свой домашний каталог.
Самая большая проблема для статически типизированных языков — построение цепочки callbackов, на C++ в реализации самая большая проблема именно с этим, там жуткие шаблоны ;)