2010-11-03 20 views
7

Estoy construyendo una aplicación Ruby on Rails que accede a entre 6 y 7 API, toma información de ellos en función de la entrada del usuario, compara y muestra los resultados a los usuarios (la información no se guarda en la base de datos). Utilizaré Heroku para implementar la aplicación. Me gustaría que esas solicitudes HTTP para acceder a las API se hagan en paralelo, por lo que el tiempo de respuesta es mejor en lugar de hacerlo de forma secuencial. ¿Cuál crees que es la mejor manera de lograr esto en Heroku?¿Cómo hacer solicitudes HTTP paralelas en Heroku?

¡Muchas gracias por cualquier sugerencia!

Respuesta

6

Si desea hacer realidad las peticiones en el lado del servidor (TFE es javascript solución es una buena idea), la mejor opción sería utilizar EventMachine. El uso de EventMachine proporciona una forma simple de hacer IO sin bloqueo.

También consulte EM-Synchrony para un conjunto de clientes de fibra sensible Ruby 1.9 (incluido HTTP).

Todo lo que necesita hacer para una solicitud HTTP no bloqueo es algo así como:

require "em-synchrony" 
require "em-synchrony/em-http" 
EM.synchrony do 
    concurrency = 2 
    urls = ['http://url.1.com', 'http://url2.com'] 

    # iterator will execute async blocks until completion, .each, .inject also work! 
    results = EM::Synchrony::Iterator.new(urls, concurrency).map do |url, iter| 

     # fire async requests, on completion advance the iterator 
     http = EventMachine::HttpRequest.new(url).aget 
     http.callback { iter.return(http) } 
     http.errback { iter.return(http) } 
    end 

    p results # all completed requests 
    EventMachine.stop 
end 

Goodluck!

0

Tenga una mirada en la creación de cada solicitud como un trabajo en segundo plano: http://blog.heroku.com/archives/2009/7/15/background_jobs_with_dj_on_heroku/

Cuanto más 'Trabajadores usted compra a Heroku, más puestos de trabajo en segundo plano pueden ser procesados ​​simultáneamente, dejando su 'Dynos' para servir a sus usuarios .

+0

El problema al hacerlo como trabajo en segundo plano es que dj guarda los trabajos pendientes en la base de datos, entonces, los procesos se agregan a la cola, luego el usuario tiene que esperar hasta que uno de los trabajadores consulte la base de datos para ver qué trabajo está esperando y luego se ejecuta. Entonces, además del tiempo de espera para consultar las API, estoy agregando tiempo de espera hasta que los trabajadores comiencen el trabajo. Por eso creo que esta no es la mejor opción ... pero podría estar equivocado. – acadavid

+0

Como alternativa, puede usar typhoeus (https://github.com/pauldix/typhoeus) para ejecutar las solicitudes en paralelo. – gjb

2

Siempre puede realizar las solicitudes del lado del cliente utilizando Javascript. Entonces no solo podrás ejecutarlos en paralelo, sino que ni siquiera necesitarás el viaje de ida y vuelta a tu propio servidor.

+0

Solo podemos omitir el viaje de ida y vuelta si no necesitamos algún tipo de clave de API, ¿correcto? De lo contrario, primero debemos ir al servidor porque no podemos almacenar la clave API en el cliente. –

Cuestiones relacionadas