2010-05-10 4 views
10

Я не профессиональный веб-разработчик, но мне нравится галстук на сайтах как хобби. Недавно я играл с разработкой приложения Rails в качестве проекта, чтобы помочь мне изучить структуру. Цель моего игрушечного приложения - собрать данные из другой службы через их API и сделать ее доступной для меня, чтобы запросить функцию поиска.Дросселирование исходящих вызовов API, созданных приложением Rails

Однако служба, которую я хочу извлечь данные, налагает ограничение скорости на количество вызовов API, которые могут выполняться в минуту. Я планирую, что мое приложение запускает ежедневное обновление, которое может генерировать пакет вызовов API, который намного превышает лимит, предоставляемый внешней службой. Я хочу уважать производительность внешнего сайта и поэтому хотел бы снизить скорость, с которой мое приложение выполняет вызовы.

Я сделал немного поиска и подавляющее количество учебника материалов и готовых библиотек я нашел крышку дросселирования входящие API вызовы в веб-приложение, и я могу найти небольшое обсуждение управления потоком исходящих звонки.

Будучи и любительским веб-разработчиком, и новичком-рельсами, вполне возможно, что я выполнял неправильные запросы в неправильных местах. Поэтому мои вопросы:

  • Есть хороший сайт там агрегирование Rails учебников, которые материалы, связанные с дросселированием исходящих запросов API?

  • Есть ли какие-либо рубиновые камни или другие библиотеки, которые помогут мне разобраться в запросах?

У меня есть некоторые идеи о том, как я мог бы идти о написании системы дросселирования с помощью работнику на основе очередей, как DelayedJob или Resque для управления вызовами API, но я предпочел бы провести свои выходные строительства остальной части сайта если там уже есть готовое решение.

ответ

0

Причина, по которой никто не говорит об исходящем дросселировании, состоит в том, что это обычно довольно тривиально, так как вы управляете им. Управление пропускной способностью может быть немного сложнее, но контроль количества запросов?

ri Kernel#sleep 

Так что, если вы позволили 10 API вызовов в минуту вы просто спать (6) после каждого вызова

+0

Да, это похоже на разумное решение, однако у меня есть некоторые проблемы с ним. 1) потребовалось бы тонкую настройку, чтобы оптимизировать время сна и 2) похоже, что рабочий поток полностью застопорился во время сна. Я предпочел бы решение, которое заставило бы работника отложить выполнение вызовов API и обработать другие задачи, если превысит лимит звонков, а не просто висит. – Sharpie

+0

1) Что вы подразумеваете под оптимизацией? Вы не можете получить более эффективное, чем 0% использования процессора! 2) Да, вот в чем смысл!Если вы хотите, чтобы другие действия выполнялись, дайте им другой поток. Я не совсем понимаю, почему вы так беспокоитесь о функциях ежедневной пакетной работы. *) отредактировал ответ об использовании – user336851

+0

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

2

На данный момент есть драгоценный камень: throttle-queue. Он берет блок кода и гарантирует, что он будет выполняться только x раз в секунду. Это пример, взятый из Readme, который будет извлекать только три файла в секунду:

require 'throttle-queue' 

q = ThrottleQueue.new 3 
files.each {|file| 
    q.background(file) { 
     fetch file 
    } 
} 
Смежные вопросы