Rails 3.2 streaming

Question

Estoy trabajando en una descarga de streaming (CSV) de Rails 3.2 y estoy enfrentando un problema con la solicitud inicial de la página que lleva mucho tiempo. El siguiente código ilustra controlador de mi problema:

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

Con lo anterior, la respuesta parece como su transmisión en (desde un servidor que puede apoyarla ... Unicorn, en mi caso). Dicho esto, antes de que comience a transmitirse, se cuelga por mucho más tiempo del que me gustaría. Si lo cambio a la siguiente, se inicia mucho más rápido:

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

Mi entendimiento es que la respuesta debe comenzar con la primera iteración del bucle, pero parece que los bucles más grandes están causando que el tiempo de carga inicial para alargar . Si cada iteración se envía como sucede, ¿no debería tomarse la misma cantidad de tiempo para iniciar el proceso de transmisión, independientemente de cuántas iteraciones totales habrá?

¡Gracias por cualquier idea que pueda tener!

EDIT:

He aquí una explicación de la técnica que estoy tratando. Tal vez estoy malinterpretando o perder el paso ?: http://facebook.stackoverflow.com/questions/3507594/ruby-on-rails-3-streaming-data-through-rails-to-client/4320399#4320399

EDIT:

Yo creo en rack de caché podría ser la causa de mi problema ... puedo apagarlo para una consulta individual?

EDIT y resuelto:

estaba equivocada en rack de caché. solo necesitaba agregar self.response.headers['Last-Modified'] = Time.now.ctime.to_s a mi respuesta.

Answer 1

La pregunta editada resultó contener exactamente la respuesta que necesitaba. Publicarlo aquí como una respuesta.

La respuesta a conseguir el controlador de estante para transmitir adecuadamente es al parecer para añadir una cabecera Last-Modified a la respuesta:

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