2010-05-10 10 views
10

Non sono uno sviluppatore web professionista, ma mi piace intrufolarsi sui siti web come hobby. Recentemente, ho giocato con lo sviluppo di un'app Rails come progetto per aiutarmi ad imparare il framework. L'obiettivo della mia app giocattolo è raccogliere i dati da un altro servizio tramite la loro API e renderli disponibili per la query utilizzando una funzione di ricerca.Limitazione delle chiamate API in uscita generate da un'app Rails

Tuttavia, il servizio da cui desidero estrarre dati impone un limite di velocità al numero di chiamate API che possono essere eseguite al minuto. Ho intenzione di far eseguire alla mia app un aggiornamento giornaliero che potrebbe generare una raffica di chiamate API che supera di gran lunga il limite fornito dal servizio esterno. Desidero rispettare le prestazioni del sito esterno e vorrei quindi limitare la velocità con cui la mia app esegue le chiamate.

Ho fatto un po 'di ricerca e la straordinaria quantità di materiale tutorial e librerie pre-costruiti ho trovato copertura strozzamento entrata chiamate API per una web app e posso trovare poco discussione di controllare il flusso di uscita chiamate.

Essendo sia uno sviluppatore web amatoriale che un principiante di rails, è del tutto possibile che abbia eseguito le ricerche sbagliate nei posti sbagliati. Quindi le mie domande sono:

  • C'è un bel sito web là fuori aggregazione Rotaie tutorial che ha il materiale relativi a strozzamento richieste API in uscita?

  • Ci sono gemme di rubini o altre librerie che potrebbero aiutarmi a limitare le richieste?

Ho alcune idee su come potrei andare a scrivere un sistema di limitazione utilizzando un lavoratore code-based come DelayedJob o Resque per gestire le chiamate API, ma io preferirei spendere i miei week-end costruire il resto del sito se c'è già una buona soluzione pre-costruita.

risposta

0

Il motivo per cui nessuno parla della limitazione in uscita è che di solito è piuttosto banale, dal momento che è controllarlo. Controllare la larghezza di banda può essere un po 'più difficile, ma controllare il numero di richieste?

ri Kernel#sleep 

Quindi, se si è permesso di 10 chiamate API al minuto è sufficiente dormire (6) dopo ogni chiamata

+0

Aye, sembra una soluzione ragionevole, tuttavia ho alcuni problemi con esso. 1) occorrerebbe un po 'di messa a punto per ottimizzare il tempo di sonno e 2) sembra che il thread di lavoro sia completamente bloccato durante la durata del sonno. Preferirei una soluzione che inducesse il lavoratore a rinviare l'esecuzione delle chiamate API e ad elaborare altre attività se il limite di chiamata viene superato anziché semplicemente sospeso. – Sharpie

+0

1) Cosa intendi con ottimizzazione? Non è possibile ottenere un utilizzo più efficiente dello 0% della CPU! 2) Sì, questo è il punto!Se vuoi che siano fatte altre azioni, consegnale ad un altro thread. Non capisco del tutto perché tu sembri così preoccupato per i perfs di un lavoro batch quotidiano. *) ha modificato la risposta sull'utilizzo – user336851

+0

Beh, immagino che la mia preoccupazione principale a questo punto sia che sto considerando di implementare l'app su una piattaforma come Heroku. In questo caso vorrei ottimizzare in modo che ogni thread lavori attraverso le attività nel modo più efficiente possibile. Dato che Heroku paga per lavoratore, vorrei usare il minor numero possibile di thread di lavoro. Forse sto cercando di complicare eccessivamente il problema ... le soluzioni semplici sono buone soluzioni. – Sharpie

2

Ora c'è una gemma per questo: throttle-queue. Richiede un blocco di codice e si assicura che venga eseguito solo x volte al secondo. Questo è un esempio tratto dal file Leggimi, che recupera solo tre file al secondo:

require 'throttle-queue' 

q = ThrottleQueue.new 3 
files.each {|file| 
    q.background(file) { 
     fetch file 
    } 
} 
Problemi correlati