Андрей Смирнов smira

aptly работает только с пакетами, которые полностью скачены (иначе нет возможности поддерживать snapshot).

«Чтобы вытащить 5 пакетов из зеркала», можно сделать примерно так:

aptly repo create repo1
aptly mirror create -architectures="i386" -filter='pkg1 | pkg2 | pkg3' mirror1 ....
aptly mirror update mirror1
aptly repo import mirror1 repo1 'Name'

aptly выкачает только пакеты, которые удовлетворяют условиям фильтра, полный синтаксис здесь.

Если сравнивать брокеры сообщений — они все примерно похожи на AMQP. Если смотреть на другие варианты очередей (beanstalkd, Kafka, и т.п.) — это другие решения с другими характеристиками. ØMQ — обмен сообщениями без брокера.

Лучше смотреть на картинку «Deferred в квадрате», и рассматривать Deferred2 как отдельный поток, который начинается выделением ресурса (т.е. к моменту прихода на уровень callback2_1 ресурс уже выделен).

У Deferred есть метод .addBoth, который добавляет один и тот же обработчик на оба слота (callback/errback) на одном уровне. Это модель try...finally, который и используется для гарантированного освобождения ресурса при любом исходе.

Мой комментарий относился ни к скорости создания нитей, ни к красоте кода.

В общем случае, чистый код в нитях (без другой модели программирования, например Actor в Erlang) крайне труден в поддержке/разработке из-за наличия тех или иных синхронизаций, число которых для получения приемлемой скорости растет.

Я не готов сравнить их. EventMachine — это «Twised на Ruby».

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

Вообще говоря Ruby MRI на сегодня медленнее Python.

Может, кто из пробовавших оба расскажет?

Дело было примерно так — автор Tornado пытался понять Twisted, писал в список рассылки, спрашивал. Но так и не понял и сделал Tornado. Видимо, такова его ниша (Tornado) и такое «упрощенное» решение имеет право на существование.

Без обид. Просто другой взгляд на вещи.

Поэтому я думаю сравнение технологий без определения критериев и конкретных метрик бесмысленно.

Не за что! Видео с конференции я, к сожалению, не могу найти.

Да, пока прогресса нет, к сожалению. Буду рад любому, кто подберет проект — помогу и советом, и делом.

Уточню: гораздо меньший битрейт за счет использования хорошего кодека, и возможность экспортировать записанные видео в родную Фотогаллерею айФона — где появляется возможность тримить видео и загружать его на РС.
А так вообще на джейлбрекнутых айФонах можно пользоваться намного лучшим API по захвату видео, соотв. FPS (кадров в секунду) там всегда будет лучше пока Apple нормальный API не откроет.

Гораздо меньший битрейт за счет использования хорошего кодека

Нет, речь как раз идет о видео, но для iPhone 2G & 3G

Там мелкие багфиксы в разных точках, где что-то ломалось. Ничего серьезного.

wiz, нет еще… Если интересно, могу кинуть код лично. Публиковать еще не готов пока ;)

Спасибо большое, даешь AMQP в массы!

Мне кажется, что обязательно надо об этом написать!

На самом деле это не такой маленький список. Для работы Qik нужна в телефоне качественная камера, а для live неплохой канал: WiFi/3G/Edge. Поэтому поддержать совершенно любой телефон смысла нет, но мы постоянно занимаемся расширением перечня моделей телефонов, на которых Qik работает.

jailbreak-only :)

C Qpid не все так просто. Java-версия умеет 0-8.

Мне трудно сказать, я не эксперт в Erlangе, знаю, что там замечательный внутренний messaging. Чаще всего рано или поздно придется интегрироваться с другими системами, написанными на чем-то еще. И вот тогда «прослойка» в виде AMQP-брокера может очень даже пригодится.

P.S. RabbitMQ (AMQP-брокер) как раз написан на Erlang.

Присоединяюсь, пробовал и его и Qpid. Qpid проще в процессе прототипирования (проще запустить и управлять), а в продакшне уже Rabbit!

Сергей, может быть Вам подойдет и Ваша система. Наверное, она работает.

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

Как использовать более «правильные» подходы к кэшированию? Я бы советовал взять, например, библиотеку Котерова. Или посмотреть продвинутые frameworkи кэширования, например, в рельсах. Может, кто еще из Хабровчан расскажет о хороших примерах, я доступных примеров больше не знаю, к сожалению.

Сам сервер однопотоковый, это сильно упрощает дизайн и облегчает производительность (event-driven). RTMP как таковой с трудом можно разделить на нормальную многопоточную обработку, в отдельный поток можно вынести независимую задачу (например, перекодирование видео). План состоит в создании автоматически (или полуавтоматически) кластеризуемого решения. Тогда на одном сервере запускаем столько FMSPy, сколько там ядер. Используем столько серверов, сколько нам нужно. Все это работает как единый организм, распределяя нагрузку внутри себя так, чтобы все сервера были загружены примерно одинаково.

Так что нет, GIL не смущает.

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

Так что, даешь новую статью про улучшенную Вами же Вашу систему кэширования!

Если брать Wowza/FMS — все-таки есть уверенность, что нужно open-source решение, которое бы позволяло технологию вперед. У FMS/Wowza есть свои проблемы с надежностью и не всегда полной поддержкой.

Если брать Red5/rtmpy/Milenia Grafter и другие open-source проекты: Red5 — тормозит и глючит (опыт реального использования под нагрузкой). С моей точки зрения это монстр, который может жить только в руках создателей. Rtmpy — на начальном этапе развития, у FMSPy есть общий код с ним, близкие проекты. Но путь Rtmpy меня не устраивает. Milenia как-то тихо загибается в непонятном пути развития.

RTMP — очень полезная технология, которая может иметь множество применений. Нужно только ее развитие. FMSPy — это не только сервер RTMP, это еще и протокол RTMP, который можно использовать в любом Twisted-приложении.

Для разработчиков приложений для FMSPy (то есть по API FMSPy) или для разработчиков самого FMSPy?

Из неопубликованного есть автоматически сгененированная документация по коду, ее можно и самому легко собрать — git clone, make docs

1 (одна) шт. :)

Ну, наверное, это не совсем то, что должно входить в ядро FMSPy. Это типичная задача для приложения к FMSPy: мы получаем по RTMP потоковый звук от пользователя, на сервере проделываем микширование и выдаем (публикуем) в качестве стрима. В FMSPy должны быть все возможности для этого: захват живого стрима, публикация стрима. Микширование и кодирование/декодирование потока, наверное, будет выходить за рамки FMSPy, но для этого стоить использовать готовые возможности Python, например, интерфейс с GStreamer.

Тестируйте, пожалуйста, устанавливайте, пробуйте, ищите баги и т.п.! Все, что получится, пишите в трекер на fmspy.org/ в виде тикетов. (Чтобы создать тикет, надо зарегистрироваться). Спасибо!

Честно скажу, не было. Если есть идеи, как это реализовать, я был бы рад совместно работать над интеграцией!

Спасибо!

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

Эффективность описанной системы кэширования должна быть низкой, если ничего не путаю по тексту, то при изменении любой таблицы сбрасываются все кэши, затрагивающие эту таблицу. Такой подход не может работать на реальном проекте. Изменение таблицы коментов на Хабре не должно приводить сбросу всех кэшей комментариев ко всем статьям. В крайнем случае — только к той статье, к которой был добавлен/удален/изменен комментарий.

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

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

Nerezus, вы можете помочь! Если не непосредственно участием в разработке, то, например, организацией тестирования производительности. Мы (все вместе) смогли бы несомненно сделать его лучше.

Я не думаю, что разработка может быть быстрее на Java или каком-то еще языке программирования. Современные framework'и дают примерно равное время разработки (объем усилий).

Это делается на Python, потому что для меня так удобнее. Я не вижу недостатков такого решения (или знаю как такие недостатки обойти).

Ой как много… Но без Deferred нужно еще больше программистов!

Взаимно! :)

1. Таймаут нужен там, где он может произойти, ну, например, вызов connect(). Если он завершится ошибкой, надо в цепочку Deferred запустить Failure, т.е. обычное исключение. Таймаут не отличается от разрыва соединения и т.п. Twisted это умеет.
2. Не несет существенного, она очень-очень простая. Полторы страницы кода (Python). Научиться ей пользоваться и думать в её терминах сложнее, но реализация простая и эффективная.

И еще был чудесный баг, twistd не запускал процесс в фоне с --reactor=kqueue. Помогал ключик '-n' и уход в демона внешними средствами.

Там с kqueue надо было патчить порт py-kqueue, после этого счастье ;) А еще был баг в самом Twisted, но они это пофиксили в новых версиях.

По умолчанию Twisted биндится на все интерфейсы, возможно это у него не получается, и надо ему сказать выбирать конкретный адрес (интерфейс). Ну и на всякий случай не-рутовые приложения не могут получить порт ниже 1024.

Ох, не силён я в терминологиях хостинговых )

По сути, twisted-приложение — это обычное питоновское приложение. Если есть python, есть возможность запускать процессы «в фоне» (есть шелл), есть возможность установить питоновский пакет (twisted), есть возможность забиндиться на порт и т.п., то приложение будет работать. Для этого нужен выделенный сервер или виртуальный выделенный сервер (т.е. наличие своего IP, шелла и т.п.). Рутовый доступ как таковой не нужен, если есть Python, все пакеты можно установить и в свой домашний каталог.

Насчет Java ничего не знаю, к сожалению… Twisted, насколько я знаю, близок к тому, чтобы работать под Jython, т.е. в каком-то плане может быть доступно.

Самая большая проблема для статически типизированных языков — построение цепочки callbackов, на C++ в реализации самая большая проблема именно с этим, там жуткие шаблоны ;)