TF
есть кто из кодеров готовых работать удаленно?
Size: a a a
2016 November 24
2016 November 28
MS
Можно собрать рубяшник в один исполняемый файл с помощью mruby http://mruby.org/docs/articles/executing-ruby-code-with-mruby.html
RK
вместе с гемами?
MS
попробую с гемами собрать -- отпишусь
MS
Наткнулся через видео с RubyConf 2016
MS
вечером буду смотреть
RK
чот оно все там не прод реди
С
Миша, по поводу тредов в рельсах. Рус всё правильно пояснил, я только сделаю акцент на двух вещах:
1. Страдает надёжность: нельзя отследить статус, нельзя ре-трай, если завалилась.
2. Если таких тредов насобирается много в единицу времени, то это либо утечка памяти (это в лучшем случае, если задача IO-intensive), либо ЦПУ вешаться будет и следующие запросы будут буксовать
1. Страдает надёжность: нельзя отследить статус, нельзя ре-трай, если завалилась.
2. Если таких тредов насобирается много в единицу времени, то это либо утечка памяти (это в лучшем случае, если задача IO-intensive), либо ЦПУ вешаться будет и следующие запросы будут буксовать
2016 November 29
RS
Миша, по поводу тредов в рельсах. Рус всё правильно пояснил, я только сделаю акцент на двух вещах:
1. Страдает надёжность: нельзя отследить статус, нельзя ре-трай, если завалилась.
2. Если таких тредов насобирается много в единицу времени, то это либо утечка памяти (это в лучшем случае, если задача IO-intensive), либо ЦПУ вешаться будет и следующие запросы будут буксовать
1. Страдает надёжность: нельзя отследить статус, нельзя ре-трай, если завалилась.
2. Если таких тредов насобирается много в единицу времени, то это либо утечка памяти (это в лучшем случае, если задача IO-intensive), либо ЦПУ вешаться будет и следующие запросы будут буксовать
👍
MS
Статус отследить можно. Ретранслятор тоже можно сделать. Ты хотел сказать что это не из коробки. Т.е. Новичку лучше положиться на существующие решения чтобы не отстрелить себе ногу.
MS
2. Неактуально для задачи отправки имейла при регистрации
MS
Насчёт расходования памяти в целом хороший довод. Я отдебажу этот момент на каком нибудь приложении.
MS
Посмотрим на прогрессию траты ресурсов
MS
>> Несмотря на то, что в данном методе не происходит запроса к бд, rails все равно резервирует соединения на протяжении каждого запроса. И если во время запроса будет не хватать соединений, то приложение будет ждать, пока не получит своего.
Блеск и нищета фреймворков
Блеск и нищета фреймворков
С
Rails 4 thread safety не имеет вообще никакого отношения к тому, что ты говоришь
С
>> Несмотря на то, что в данном методе не происходит запроса к бд, rails все равно резервирует соединения на протяжении каждого запроса. И если во время запроса будет не хватать соединений, то приложение будет ждать, пока не получит своего.
Блеск и нищета фреймворков
Блеск и нищета фреймворков
Волшебную кнопочку fork видал? Вперёд :)
С
Статус отследить можно. Ретранслятор тоже можно сделать. Ты хотел сказать что это не из коробки. Т.е. Новичку лучше положиться на существующие решения чтобы не отстрелить себе ногу.
Если можно отследить статус и сделать надёжный ретрай, значит ты это всё где-то будешь персистентно хранить. А значит ты просто из рельсового процесса сделаешь плохой сайдкик. А преимущества есть?
С
2. Неактуально для задачи отправки имейла при регистрации
Это как раз IO-intensive задача. ЦПУ брать не будет, а память — да.