2010-11-03 3 views
7

Я создаю приложение Ruby on Rails, которое получает около 6-7 API-интерфейсов, захватывает информацию от них на основе ввода пользователя, сравнивает и отображает результаты для пользователей (информация не сохраняется в базе данных). Я буду использовать Heroku для развертывания приложения. Я хотел бы, чтобы эти HTTP-запросы обращались к API-интерфейсам параллельно, чтобы время ответа было лучше, а не выполнялось последовательно. Как вы думаете, лучший способ добиться этого в Героку?Как выполнять параллельные HTTP-запросы в Heroku?

Благодарим вас за любые предложения!

ответ

6

Если вы действительно хотите делать запросы на стороне сервера (т.у.т. это решение Javascript является хорошей идеей), лучше всего будет использовать EventMachine. Использование EventMachine дает простой способ сделать неблокирующий IO.

Также проверьте EM-Synchrony на набор клиентов с поддержкой волокон Ruby 1.9 (включая HTTP).

Все, что вам нужно сделать для запроса неблокируемой HTTP-то вроде:

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

Посмотрите на создание каждого запроса в качестве фонового задания: http://blog.heroku.com/archives/2009/7/15/background_jobs_with_dj_on_heroku/

Чем больше «рабочие вы покупаете от Heroku, тем больше фоновых заданий могут быть обработаны одновременно, оставляя«динамометрические стенды»для обслуживания пользователей ,

+0

Проблема с выполнением его как фонового задания заключается в том, что dj сохраняет ожидающие задания в базе данных, поэтому процессы добавляются в очередь, тогда пользователю приходится ждать, пока один из рабочих запросит базу данных, чтобы увидеть, какая работа ждет, а затем выполняется. Поэтому в дополнение к времени ожидания запроса API, я добавляю время ожидания, пока рабочие не начнут работу. Вот почему я думаю, что это не лучший вариант. Но я могу ошибаться. – acadavid

+0

В качестве альтернативы вы можете использовать typhoeus (https://github.com/pauldix/typhoeus) для параллельного запуска запросов. – gjb

2

Вы всегда можете делать запросы на стороне клиента, используя Javascript. Тогда вы можете не только запустить их параллельно, но вам даже не понадобится кругосветное путешествие на ваш собственный сервер.

+0

Мы можем пропустить поездку туда и обратно, если нам не нужен какой-то ключ API, правильно? В противном случае нам нужно сначала перейти на сервер, потому что мы не можем хранить ключ API на клиенте. –

Смежные вопросы