Symfony2

Почему именно этот?

Вообще хотелось бы услышать за и против nodejs.

А движок tinyogg не свободный?

Свободный на джанге.
http://svn.savannah.gnu.org/viewvc/youogg/COPYING?revision=19&root=tinyogg&vi...

Но у меня очень другая задача.

В смысле - другая?

Тебе интересны детали проекта? Я их пока не могу раскрывать.
И сам код загрузки/показа видео - мне не нужен. Это «несколько строк» кода.
Мне интересна эффективность фрэймворка в плане использования ресурсов при интенсивной загрузки видео.

Tinyogg не расчитан на highload.

ну дык apache-benchmaker и тому подобные впомощь

Как с помощью ab тестировать загрузку файлов?
Плюс я поэтому и спрашиваю, что каждый фрэймворк тестировать самому - нужно много времени. Хотя теоретическая часть тоже интересна.

в общем мое нубское мнение по этому поводу: питоно-фреймворки (фласк например) пошустрее будут чем нода (шустрее их только ц++, но на нем сложнее писать), но для статики (сами же видюшки будут в статике, да?) нжыныкс — 100%

Ну про статику тут вопросов у меня нет.

Просто один товарищ утверждает, что nodejs будет для этого лучше, т.к. file uploading будет асинхронным, а в питон-фрэймворках соответственно весь процесс будет блокироваться и жрать ресурсы.

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

однако на сферическом хеллоу-ворлде в вакууме фласк соснул, хм... -_-

flask   -- Requests per second:    777.10 [#/sec] (mean)
node.js -- Requests per second:    4342.73 [#/sec] (mean)

о! фласк отъел всего 11 метров памяти, а нода аж 42. и это на одном потоке

микробенчмарк такой микробенчмарк.

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

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

Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем server-side JS и node.js, ведь мы уже знаем JS.

(c) si14

всё равно сливает фласк :3

Requests per second:    2051.84 [#/sec] (mean)

это фласк + uwsgi + nginx, в 2 воркера, у nginx тоже 2 воркера (у него самого на чисто статике 15268.09 [#/sec])

AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ @ gentoo ~amd64

а как у фласк отключить логирование успешных запросов? а то мне кажется что без него чуть быстрее было бы

Бери питон (flask) + gevent. Дешево и сердито.

есть один момент: под node.js очень хилая инфраструктура, в смысле нету всех тех 100500 удобных питонячьих библиотек, да и ECMA держит язык в ежовых рукавицах; в крупном проекте получится содержание своих костылей и хаков около 99%.

так что django, pyramid или flask+sqlalchemy всяко будут более девелопер-френдли

если под Ноду не писать, оно никогда змея не осилит. Так шо пусть лучше пишет...

фреймворк не так важен, как кажется.

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

>раздача горячего контента

Что это такое?

На все остальное я расчитываю.

Твой стартап не взлетит, забей.

>>раздача горячего контента

Что это такое?

это когда пара лямов хомячков ломанулись одновременно смотреть что-нибудь популярное

На все остальное я расчитываю.

и какую нагрузку ты расчитываешь в перспективе держать?

>и какую нагрузку ты расчитываешь в перспективе держать?

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

>ибо есть куча первичных проблем, которые посадят тебя на пятую точку раньше, чем начнешь утыкаться в веб-фреймворк, как то:

Если 100 человек с медленным интернетом будут загружать видео-ролики одновременно, то джанга например сожрет X гигобайт оперативки. Вот почему это важный вопрос. Вобще для загрузки видео пока остановился на gevent.

Ролики вообще хорошо бы отдавать с отдельного сервера.

Твой вывод о том что ролики будут на этом же сервере - ложен.

Тогда причем здесь фреймворк?

Я не знаю как ты делаешь эти выводы, но объясню подробнее
Загружаться они будут на один сервер, а раздаваться с другого.
Так понятно?

зачем джанге отдавать статику пропуская через себя?

Не зачем. Где там написано, что джанга будет отдавать статику?

ога, туплю. аплод на джанге

Так тебя сейчас больше волнует нагрузка на логику, а не на саму отдачу видео?

вобщем. делайте на эрланге, ибо надежно, ынтырпрайзно, расширяемо :3

С раздачей статики и так все понятно. N серверов с nginx и все.

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

Python: - Django - Pyramid - Flask (микро) - Tornado (асинхронный)

Ruby: - Ruby On Rails - Sinatra (micro) - EventMachine (асинхронный)

Node.js: - Express

Java: - Play! Framework - Grails - Spring Framework

Хотя, если хочется поиграться с асинхронными фреймворками, никто не заставляет. Но для фронтенда таки не плохо было бы взять Rails или Django.

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

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

Mongrel2 уже предлагали?

хм...

>> ибо есть куча первичных проблем, которые посадят тебя на пятую точку раньше, чем начнешь утыкаться в веб-фреймворк, как то:

Если 100 человек с медленным интернетом будут загружать видео-ролики одновременно, то джанга например сожрет X гигобайт оперативки. Вот почему это важный вопрос. Вобще для загрузки видео пока остановился на gevent.

зачем вообще для прёма аплоадов использовать джангу? смотри в сторону простых проверенных решений вплоть до ftp-серверов и будь готов допиливать nginx/apache/etc

С раздачей статики и так все понятно. N серверов с nginx и все.

тут-то тебя и ждёт первый сурпрыз при реальной нагрузке

>Нам не нужен Erlang. Мы выбираем server-side JS и node.js, ведь мы уже знаем JS.

Манифест быдлокодеров?

>зачем вообще для прёма аплоадов использовать джангу? смотри в сторону простых проверенных решений вплоть до ftp-серверов и будь готов допиливать nginx/apache/etc

Можно поподробнее, как ты предлагаешь например использовать ftp для этого?

тут-то тебя и ждёт первый сурпрыз при реальной нагрузке

Можно узнать, что за сюрприз?

>> зачем вообще для прёма аплоадов использовать джангу? смотри в сторону простых проверенных решений вплоть до ftp-серверов и будь готов допиливать nginx/apache/etc

Можно поподробнее, как ты предлагаешь например использовать ftp для этого?

по прямому назначению - заливка файлов по ftp

тут-то тебя и ждёт первый сурпрыз при реальной нагрузке

Можно узнать, что за сюрприз?

зависит от нагрузки и железа - ты же ничего так и не написал...

либастрал подсказывает, что закончится исходищий какнал от сервера в 2 гигабита

у тебя буджет на это всё есть?

>по прямому назначению - заливка файлов по ftp

Нет, мне интересно как ты предлагаешь такое реализовать. Вот пользователь зашел на сайт, открыл страницу загрузки.
Незбудь еще, что данные надо в базу записать. Авторизация и т.п.

зависит от нагрузки и железа - ты же ничего так и не написал...

Можно сказать, что никакого железа пока нет. Я стараюсь построить легко масштабируемую архитектуру, чтобы - увеличилась нагрузка - добавил сервер бд/статики - и все. Зачем на определенное железо завязываться?

либастрал подсказывает, что закончится исходищий какнал от сервера в 2 гигабита

И в чем сюрприз? Размер канала как раз достаточно хорошо прогнозируем.

у тебя буджет на это всё есть?

Есть.

>> у тебя буджет на это всё есть?

Есть.

ну дык давай осваивать статью консалтинговых услуг в кабаке, а не на лоре!

> питон-фрэймворках соответственно весь процесс будет блокироваться и жрать ресурсы

фоновые таски спускают в твистед, основной движ в джанге