Ruby on Rails 3: потоковая передача данных через Rails клиенту

Похоже, это недоступно в Rails 3

https://rails.lighthouseapp.com/projects/8994/tickets/2546-render-text-proc

Похоже, это сработало для меня в моем контроллере:

self.response_body =  proc{ |response, output|
  output.write "Hello world"
}

Назначьте response_body объект, который отвечает на #each:

class Streamer
  def each
    10_000_000.times do |i|
      yield "This is line #{i}\n"
    end
  end
end

self.response_body = Streamer.new

Если вы используете 1.9.x или гем Backports, вы можете написать это более компактно, используя Enumerator.new:

self.response_body = Enumerator.new do |y|
  10_000_000.times do |i|
    y << "This is line #{i}\n"
  end
end

Обратите внимание, что время и возможность сброса данных зависит от обработчика Rack и используемого базового сервера. Я подтвердил, что Mongrel, например, будет передавать данные, но другие пользователи сообщают, что, например, WEBrick буферизует их до тех пор, пока ответ не будет закрыт. Невозможно заставить ответ сбрасываться.

В Rails 3.0.x есть несколько дополнительных ошибок:

• В режиме разработки выполнение таких действий, как доступ к классам модели из перечисления, может быть проблематичным из-за плохого взаимодействия с перезагрузкой класса. Это открытая ошибка в Rails 3.0.x.

• Ошибка во взаимодействии между Rack и Rails приводит к тому, что #each вызывается дважды для каждого запроса. Это еще одна открытая ошибка. Вы можете обойти это с помощью следующего патча обезьяны:

  class Rack::Response
    def close
      @body.close if @body.respond_to?(:close)
    end
  end
  

Обе проблемы исправлены в Rails 3.1, где потоковая передача HTTP является важной функцией.

Обратите внимание, что другое распространенное предложение, self.response_body = proc {|response, output| ...}, работает в Rails 3.0.x, но устарело (и больше не будет передавать данные) в 3.1. Назначение объекта, который отвечает на #each, работает во всех версиях Rails 3.

Благодаря всем сообщениям выше, вот полностью рабочий код для потоковой передачи больших CSV. Этот код:

1. Не требует никаких дополнительных драгоценных камней.
2. Использует Model.find_each(), чтобы не раздувать память всеми соответствующими объектами.
3. Было протестировано на rails 3.2.5, ruby ​​1.9.3 и heroku с использованием единорога с одним динамометром.
4. Добавляет GC.start через каждые 500 строк, чтобы не взорвать разрешенную память динамометра heroku.
5. Возможно, вам придется настроить GC.start в зависимости от объема памяти вашей модели. Я успешно использовал это для потоковой передачи моделей 105K в csv размером 9,7 МБ без каких-либо проблем.

Метод контроллера:

def csv_export
  respond_to do |format|
    format.csv {
      @filename = "responses-#{Date.today.to_s(:db)}.csv"
      self.response.headers["Content-Type"] ||= 'text/csv'
      self.response.headers["Content-Disposition"] = "attachment; filename=#{@filename}"
      self.response.headers['Last-Modified'] = Time.now.ctime.to_s

      self.response_body = Enumerator.new do |y|
        i = 0
        Model.find_each do |m|
          if i == 0
            y << Model.csv_header.to_csv
          end
          y << sr.csv_array.to_csv
          i = i+1
          GC.start if i%500==0
        end
      end
    }
  end
end

config/unicorn.rb

# Set to 3 instead of 4 as per http://michaelvanrooijen.com/articles/2011/06/01-more-concurrency-on-a-single-heroku-dyno-with-the-new-celadon-cedar-stack/
worker_processes 3

# Change timeout to 120s to allow downloading of large streamed CSVs on slow networks
timeout 120

#Enable streaming
port = ENV["PORT"].to_i
listen port, :tcp_nopush => false

Model.rb

  def self.csv_header
    ["ID", "Route", "username"]
  end

  def csv_array
    [id, route, username]
  end

Если вы назначаете response_body объект, который отвечает на метод #each, и он буферизуется до тех пор, пока ответ не будет закрыт, попробуйте в контроллере действия:

self.response.headers['Last-Modified'] = Time.now.to_s

Для справки: в rails >= 3.1 есть простой способ потоковой передачи данных путем назначения объекта, который отвечает методу #each на ответ контроллера.

Здесь все объясняется: http://blog.sparqcode.com/2012/02/04/streaming-data-with-rails-3-1-or-3-2/

Да, response_body — это способ Rails 3 сделать это на данный момент: https://rails.lighthouseapp.com/projects/8994/tickets/4554-render-text-proc-regression

Это также решило мою проблему - у меня есть CSV-файлы с gzip, которые я хочу отправить пользователю в виде разархивированного CSV, поэтому я читаю их построчно, используя GzipReader.

Эти строки также полезны, если вы пытаетесь загрузить большой файл:

self.response.headers["Content-Type"] = "application/octet-stream" self.response.headers["Content-Disposition"] = "attachment; filename=#{filename}"

Кроме того, вам придется самостоятельно установить заголовок 'Content-Length'.

Если нет, Rack придется ждать (буферизируя данные тела в память), чтобы определить длину. И это погубит ваши усилия, используя методы, описанные выше.

В моем случае я смог определить длину. В тех случаях, когда вы не можете этого сделать, вам нужно заставить Rack начать отправку тела без заголовка 'Content-Length'. Попробуйте добавить в config.ru "use Rack::Chunked" после "require" перед "run". (Спасибо Аркадий)

Я прокомментировал в билете маяка, просто хотел сказать, что подход self.response_body = proc работал для меня, хотя мне нужно было использовать Mongrel вместо WEBrick, чтобы добиться успеха.

Мартин

Применение решения Джона вместе с предложением Exequiel сработало для меня.

Заявление

self.response.headers['Last-Modified'] = Time.now.to_s

помечает ответ как некэшируемый в стойке.

После дальнейшего изучения я решил, что можно также использовать это:

headers['Cache-Control'] = 'no-cache'

Это, на мой взгляд, чуть более интуитивно понятно. Он передает сообщение всем, кто может читать мой код. Кроме того, в случае, если будущая версия стойки перестанет проверять Last-Modified , большая часть кода может сломаться, и людям может потребоваться некоторое время, чтобы понять, почему.