Rails 3.2 流式传输答案

【问题标题】：Rails 3.2 streamingRails 3.2 流式传输
【发布时间】：2012-03-28 21:10:58
【问题描述】：

我正在处理 Rails 3.2 的流式下载 (CSV)，并且遇到了初始页面请求需要很长时间的问题。以下控制器代码说明了我的问题：

      self.response_body = Enumerator.new do |y|
        10_000_000.times do
          y << "Hello World"
        end
      end

通过上述内容，响应看起来确实像它的流式传输（来自无法支持它的服务器......在我的情况下是独角兽）。也就是说，在它开始流式传输之前，它挂起的时间比我想要的要长得多。如果我将其更改为以下内容，它会启动得更快：

      self.response_body = Enumerator.new do |y|
        1000.times do
          y << "Hello World"
        end
      end

我的理解是响应应该从循环的第一次迭代开始，但似乎较大的循环导致初始加载时间延长。如果每次迭代都是在发生时输出，那么不管总迭代次数是多少，启动流式处理过程不应该花费相同的时间吗？

感谢您提供的任何见解！

编辑：

编辑：

我认为机架缓存可能会导致我的问题...我可以为单个请求关闭它吗？

编辑并解决：

我对 Rack-Cache 的看法是错误的。我只需要在我的回复中添加self.response.headers['Last-Modified'] = Time.now.ctime.to_s。

【问题讨论】：

我不明白。该代码从另一个枚举器创建一个枚举器并分配 response_body 变量。右边的东西将首先执行（除非你有一些神奇的元数据），并且你输入的数字越大，需要的时间就越长。你需要更多的东西来做流媒体，但我自己没有建议。
您可能已经签出api.rubyonrails.org/classes/ActionController/Streaming.html
查看我上面添加的链接以了解该技术的说明。
你没有屈服。 Yield 每次调用时都会返回执行流程，因此流媒体可以发送该位。在您的技术中，您没有屈服，因此它会在流式传输之前评估整个块（100000 次位）。
@JoePym：“y ruby-doc.org/core-1.9.3/Enumerator.html#method-c-new

【解决方案1】：

编辑后的问题竟然包含我需要的答案。在这里发布它作为答案。

让 Rack 处理程序正确流式传输的答案显然是在响应中添加 Last-Modified 标头：

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

【讨论】：