Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Спасибо! Для веб-приложений это одна из фундаметальных фитчий (а рельсы для RIA во-многом и сделаны)
Долго ждал поста на эту тему на хабре, я перешел с nodejs на rails. И использую sse с live для организации COMET'a. Но т.к. для того чтобы это работало нормально нужно добавить в конфиг
config.action_controller.perform_caching = false
и при каждом изменении даже JS перезагружать сервер (это очень сильно замедляет процесс разработки)
Кто-нибудь с этим сталкивался? Что делать в подобной ситуации? Я уже писал на stackoverflow
stackoverflow.com/questions/17778517/caching-js-with-config-cache-classes
Но там все молчат…
Долго ждал поста на эту тему на хабре, я перешел с nodejs на rails. И использую sse с live для организации COMET'a. Но т.к. для того чтобы это работало нормально нужно добавить в конфиг
config.action_controller.perform_caching = false
и при каждом изменении даже JS перезагружать сервер (это очень сильно замедляет процесс разработки)
Кто-нибудь с этим сталкивался? Что делать в подобной ситуации? Я уже писал на stackoverflow
stackoverflow.com/questions/17778517/caching-js-with-config-cache-classes
Но там все молчат…
Ну вы же наверное не меняете js прям на сервере и не разрабыватываете прям там, так ведь?
А все отлаживаете на локальной машине и потом через capistrano деплоите, да?
А все отлаживаете на локальной машине и потом через capistrano деплоите, да?
Я деплою на heroku, но это сейчас не важно.
Я же сервер запускаю локально и работающий SSE через live streaming мне тоже нужен локально.
И перезапускать мне нужно локальный сервер. (в данном случае puma)
Я же сервер запускаю локально и работающий SSE через live streaming мне тоже нужен локально.
И перезапускать мне нужно локальный сервер. (в данном случае puma)
puma не кеширует. перезапускать сервер не нужно. так что вариант один, вы что-то не то сделали с настройками development
Очень странно!
Вот development.rb: gist.github.com/Timopheym/6096257
Я был бы Вам очень благодарен, потому работать просто невозможно…
Вот development.rb: gist.github.com/Timopheym/6096257
Я был бы Вам очень благодарен, потому работать просто невозможно…
Всем спасибо, я нашел ответ, и отписался на stackoverflow.
Поправьте, пожалуйста, если я не прав.
1. Из коробки нормально(держа нагрузку) стриминг работать если и должен, то только на jruby/rubinius, где есть настоящие треды, причём если верить последнему выпуску rubynoname подкаста, то у jruby с puma всё не совсем гладко, а rubinius в продакшене и вовсе мало кто использует.
2. На mri для стриминга нужно выносить стримящий сервер отдельно от основного приложения, чтобы он был в отдельном процессе, который не будет принимать прочие http запросы. И даже так, непонятно будет ли он держать хоть какую-то нагрузку.
Было бы конечно очень интересно посмотреть на бенчмарки, если кто-то их делал.
Голосовал за «Никогда», хотя если бы был вариант «Возможно, когда-нибудь», то выбрал бы его.
Только вот если рельсы не могут предложить достойной альтернативы ноде, это не значит, что в руби мире нет ничего подобного. Ведь есть eventmachine, celluloid(тут может совсем не прав, про него лишь мельком слышал) и очень простой в использовании как минимум для простеньких задач faye, основанный на том же eventmachine.
1. Из коробки нормально(держа нагрузку) стриминг работать если и должен, то только на jruby/rubinius, где есть настоящие треды, причём если верить последнему выпуску rubynoname подкаста, то у jruby с puma всё не совсем гладко, а rubinius в продакшене и вовсе мало кто использует.
2. На mri для стриминга нужно выносить стримящий сервер отдельно от основного приложения, чтобы он был в отдельном процессе, который не будет принимать прочие http запросы. И даже так, непонятно будет ли он держать хоть какую-то нагрузку.
Было бы конечно очень интересно посмотреть на бенчмарки, если кто-то их делал.
Голосовал за «Никогда», хотя если бы был вариант «Возможно, когда-нибудь», то выбрал бы его.
Только вот если рельсы не могут предложить достойной альтернативы ноде, это не значит, что в руби мире нет ничего подобного. Ведь есть eventmachine, celluloid(тут может совсем не прав, про него лишь мельком слышал) и очень простой в использовании как минимум для простеньких задач faye, основанный на том же eventmachine.
На сколько я себе это представляю, пума запускает для каждого клиента, который требует стриминга, отдельный инстанс rails-приложения. Поэтому настоящие треды тут вроде не нужны, каждое приложение работает в однопоточном режиме, многопоточная только сама пума. Главное чтобы приложение было потокобезопасным, то есть все операции должны быть атомарными (но это уже тема отдельной статьи).
Отдельный инстанс не создается, создается отдельный поток.
Настоящие треды нужны, если много ruby-кода. Если же большую часть поток занят внешними операциями (io, сеть) то сойдут и MRI зеленые потоки.
Настоящие треды нужны, если много ruby-кода. Если же большую часть поток занят внешними операциями (io, сеть) то сойдут и MRI зеленые потоки.
Отдельный инстанс не создается, создается отдельный поток.
Настоящие треды нужны, если много ruby-кода.
По этим же соображениям и написал, что для стриминга под MRI скорее всего нужно запускать отдельный процесс веб-сервера пумы, чтобы получить хоть какую-то производительность, иначе все ресурсы должны быть заняты обработкой обычных http запросов.
В MRI начиная с 1.9 нет зелёных потоков.
Преподносится как какое-то чудо. В Sinatra это уже около трёх лет как есть, причём отдельный thread для каждого stream'а не создаётся, а засчёт использования
stream do stream закрывается сам.А как обеспечивается параллельность? или Вы про async_sinatra?
А откуда вообще параллельность в MRI? Почитайте про GIL.
async_sinatra вообще ни при чём. Как только вы послали что-то в сокет, текущий обработчик отдаёт управление eventmachine'е, которая передаёт управление следующему желающему, который тоже что-то посылает или принимает.
async_sinatra вообще ни при чём. Как только вы послали что-то в сокет, текущий обработчик отдаёт управление eventmachine'е, которая передаёт управление следующему желающему, который тоже что-то посылает или принимает.
Я Вам это же могу посоветовать почитать, т.к. Вы не правы. Кратко: MRI не выполняет одновременно более одного рубишного кода. Как только в поток заходит в C-extension или в IO операцию — MRI передает управление другому потоку.
Вот тут и проявляется параллельность.
Поэтому если в приложении медленный IO, то потоки в MRI имеют смысл.
Вот тут и проявляется параллельность.
Поэтому если в приложении медленный IO, то потоки в MRI имеют смысл.
Вы опять же ошибаетесь. Теперь как минимум уже в трёх вещах.
Первое — проверка на флаг прерывания исполнения проверяется после того, как C код вычислил и готов вернуть значение в Ruby код.
Второе — все операции IO в stdlib Ruby — блокирующие, и IO операция никак не отличается по поведению от случая с вызовом любого другого метода, написанного на C. Специально для решения этой проблемы и написан EventMachine, который, используя свой диспетчер переключает на следующего желающего при IO операциях. При этом вытесняющей многозадачностью EM не занимается, то есть он не может отнять управление у потока, как это делает Ruby диспетчер потоков.
Третье — параллельность и многопоточность — это далеко не одно и то же в MRI Ruby. Точка исполнения всегда одна, и если у вас исполняется какой-то Ruby код, или C код, который вызван из Ruby, то больше ровным счётом ничего в тот самый момент времени не исполняется в рамках процесса. Это собственно хорошо объясняет тот факт, что даже если запустить чтение файлов (например, STDIN, который теоретически может быть бесконечно быстр) в разных потоках, то нагрузка будет только на одно ядро процессора, и никак не затронет другие ядра.
Заметьте, тему процессов, которые из себя представляют совершенно другую вещь, мы здесь не затрагиваем.
Первое — проверка на флаг прерывания исполнения проверяется после того, как C код вычислил и готов вернуть значение в Ruby код.
Второе — все операции IO в stdlib Ruby — блокирующие, и IO операция никак не отличается по поведению от случая с вызовом любого другого метода, написанного на C. Специально для решения этой проблемы и написан EventMachine, который, используя свой диспетчер переключает на следующего желающего при IO операциях. При этом вытесняющей многозадачностью EM не занимается, то есть он не может отнять управление у потока, как это делает Ruby диспетчер потоков.
Третье — параллельность и многопоточность — это далеко не одно и то же в MRI Ruby. Точка исполнения всегда одна, и если у вас исполняется какой-то Ruby код, или C код, который вызван из Ruby, то больше ровным счётом ничего в тот самый момент времени не исполняется в рамках процесса. Это собственно хорошо объясняет тот факт, что даже если запустить чтение файлов (например, STDIN, который теоретически может быть бесконечно быстр) в разных потоках, то нагрузка будет только на одно ядро процессора, и никак не затронет другие ядра.
Заметьте, тему процессов, которые из себя представляют совершенно другую вещь, мы здесь не затрагиваем.
Вы заблуждаетесь:
Давайте разберемся с самого начала:
1. В MRI 1.9 применяются нативные threads. Каждый раз когда создается экземпляр класса Thread — создается нативный thread OS.
2. При выполнении ruby кода (или C-кода внутри ruby) блокируется GIL. Чтобы выполнялся только один thread.
3. IO операции: операции с файлами, сетевые операции — действительно блокируемые.
4. Но до входа в IO операции освобождается GIL (или как Вы называете флаг прерывания), благодаря этому спящие потоки получают управление.
5. Кастомные C-extensions (nokogiri, json parser, etc) которые напрямую не работают с структурами MRI также освобождают GIL
6. В EM совсем другой принцип — есть всего один поток, но все (в идеале) IO операции неблокируемые.
7. EM использует паттерн Reactor — используются средства OS (epoll,select,etc) для опроса дескрипторов, готовых для чтения/записи.
8. В этом случае ruby код должен быть как можно более быстрым, чтобы быстрей вернуть управление реактору.
9. В EM есть еще thread pools, но мы их не рассматриваем, т.к. являются workaround для блокируемых операций (типа клиента mysql).
Ваши заблуждения:
1. C-код (C-extendsions) который не работает с MRI структурами — может освобождать GIL и будет задействовано более одного ядра.
2. EM переключает не на следующего желающего — а на тот блок кода (callback), для дескриптора которого OS сообщает, что готовы данные для чтения, или запись завершена и тп.
Т.к. C-код как правило выполняется достаточно быстро — профит получается небольшой.
Вот ссылки для дальнейшего чтения:
merbist.com/2011/02/22/concurrency-in-ruby-explained/
stackoverflow.com/questions/1203565/native-threads-in-ruby-1-9-1-whats-in-it-for-me
yehudakatz.com/2010/08/14/threads-in-ruby-enough-already/
www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby/
Процессы тут совершенно ни причем, и мы не рассматриваем их.
Давайте разберемся с самого начала:
1. В MRI 1.9 применяются нативные threads. Каждый раз когда создается экземпляр класса Thread — создается нативный thread OS.
2. При выполнении ruby кода (или C-кода внутри ruby) блокируется GIL. Чтобы выполнялся только один thread.
3. IO операции: операции с файлами, сетевые операции — действительно блокируемые.
4. Но до входа в IO операции освобождается GIL (или как Вы называете флаг прерывания), благодаря этому спящие потоки получают управление.
5. Кастомные C-extensions (nokogiri, json parser, etc) которые напрямую не работают с структурами MRI также освобождают GIL
6. В EM совсем другой принцип — есть всего один поток, но все (в идеале) IO операции неблокируемые.
7. EM использует паттерн Reactor — используются средства OS (epoll,select,etc) для опроса дескрипторов, готовых для чтения/записи.
8. В этом случае ruby код должен быть как можно более быстрым, чтобы быстрей вернуть управление реактору.
9. В EM есть еще thread pools, но мы их не рассматриваем, т.к. являются workaround для блокируемых операций (типа клиента mysql).
Ваши заблуждения:
1. C-код (C-extendsions) который не работает с MRI структурами — может освобождать GIL и будет задействовано более одного ядра.
2. EM переключает не на следующего желающего — а на тот блок кода (callback), для дескриптора которого OS сообщает, что готовы данные для чтения, или запись завершена и тп.
Т.к. C-код как правило выполняется достаточно быстро — профит получается небольшой.
Вот ссылки для дальнейшего чтения:
merbist.com/2011/02/22/concurrency-in-ruby-explained/
stackoverflow.com/questions/1203565/native-threads-in-ruby-1-9-1-whats-in-it-for-me
yehudakatz.com/2010/08/14/threads-in-ruby-enough-already/
www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby/
Процессы тут совершенно ни причем, и мы не рассматриваем их.
В данном случае я не заблуждаюсь, а опустил детали. Да, действительно, GVL можно отпускать, но в контексте http серверов этого не происходит, так как nokogiri не участвует в процессе. В крайнем случае это может делать redcarpet, но чтобы кто-то из шаблонизаторов отпускал GVL я не слышал (в slim, haml и их подспудном tilt'е вообще нет C кода).
По поводу EM 1) не только callback'и на чтение, есть ещё события по таймеру. 2) EM не переключает на обработчик, запись по требованию которого была завершена, пока не дойдёт его очередь, в конец которой он был помещён при начале записи.
По поводу EM 1) не только callback'и на чтение, есть ещё события по таймеру. 2) EM не переключает на обработчик, запись по требованию которого была завершена, пока не дойдёт его очередь, в конец которой он был помещён при начале записи.
Вы «опускаете» очень важные детали — именно те детали, из-за которых у нас и завязалась дискуссия.
Другими словами, Вы пытаетесь вывернуться, и сами себе противоречите:
Выше Вы писали:
я разъяснил Вам ваше заблуждение — нагрузка может распределятся на разные ядра, это очень важная деталь, без которой MRI потоки (а тем более что они реализованы через native threads) теряют смысл.
Т.е. Вы же не будете отрицать, что в ~99% случаев web-приложениях используются внешние данные — запросы к БД, внешним источникам (IO операции) и тп? Причем, чаще всего эти операции выполняются дольше чем ruby-код. Именно здесь и идет выигрыш, и задействуются дополнительные ядра.
Да и с чего Вы взяли что в приложениях не применяются C-extensions наподобие nokogiri? JSON-parser/encoder'ы? посмотрите Yajl например. Но больше обратите внимание на IO операции.
Другими словами, Вы пытаетесь вывернуться, и сами себе противоречите:
Выше Вы писали:
Точка исполнения всегда одна, и если у вас исполняется какой-то Ruby код, или C код, который вызван из Ruby, то больше ровным счётом ничего в тот самый момент времени не исполняется в рамках процесса. Это собственно хорошо объясняет тот факт, что даже если запустить чтение файлов (например, STDIN, который теоретически может быть бесконечно быстр) в разных потоках, то нагрузка будет только на одно ядро процессора, и никак не затронет другие ядра.
я разъяснил Вам ваше заблуждение — нагрузка может распределятся на разные ядра, это очень важная деталь, без которой MRI потоки (а тем более что они реализованы через native threads) теряют смысл.
Т.е. Вы же не будете отрицать, что в ~99% случаев web-приложениях используются внешние данные — запросы к БД, внешним источникам (IO операции) и тп? Причем, чаще всего эти операции выполняются дольше чем ruby-код. Именно здесь и идет выигрыш, и задействуются дополнительные ядра.
Да и с чего Вы взяли что в приложениях не применяются C-extensions наподобие nokogiri? JSON-parser/encoder'ы? посмотрите Yajl например. Но больше обратите внимание на IO операции.
Причем тут sinatra и eventmachine. Вы путаете разные понятия. sinatra некоим образом не завязана на EM.
Какая eventmachine может быть, если sinatra запущена, например из под passenger?
Я использую в нагруженном проекте async_sinatra + em + fibers + thin и знаю о чем говорю.
Какая eventmachine может быть, если sinatra запущена, например из под passenger?
Я использую в нагруженном проекте async_sinatra + em + fibers + thin и знаю о чем говорю.
Sinatra не завязан на EM? Да ну?
Вы удивитесь, когда узнаете, что async_sinatra в этой связке лишний.
def stream(keep_open = false)
scheduler = env['async.callback'] ? EventMachine : Stream
Вы удивитесь, когда узнаете, что async_sinatra в этой связке лишний.
Хорошо, согласен. Скажем так: sinatra пытается использовать EM если запущена под EM сервером, но EM не обязателен
Если вернуться к первоначальному вопросу — то sinatra+em и rails+threads разные инструменты, которые нельзя сравнивать напрямую, именно поэтому он у меня и возник, т.к. Вы не озвучили, что имеете в виду именно EM.
Если вернуться к первоначальному вопросу — то sinatra+em и rails+threads разные инструменты, которые нельзя сравнивать напрямую, именно поэтому он у меня и возник, т.к. Вы не озвучили, что имеете в виду именно EM.
нееененекропост:
Это вам надо прочитать про GIL. yehudakatz.com/2010/08/14/threads-in-ruby-enough-already/
Другое дело, что в Rails до 4 версии был Rack::Lock.
Это вам надо прочитать про GIL. yehudakatz.com/2010/08/14/threads-in-ruby-enough-already/
Другое дело, что в Rails до 4 версии был Rack::Lock.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стриминг в Rails 4