Devo avere un dyno worker heroku per sondare un SQS AWS?

Question

Im confusione su dove dovrei avere uno script che esegue il polling di un Aws Sqs all'interno di un'applicazione Rails.

Se utilizzo un thread nell'app Web probabilmente utilizzerà i cicli cpu per ascoltare questa coda per sempre e quindi influire sulle prestazioni.

E se mi riservo un singolo banco di lavoro heroku costa $ 34,50 al mese. Ha senso pagare questo prezzo per un sondaggio a coda singola? O non è il caso di usare un lavoratore per questo?

Il codice di script:

Cosa fa: Ascoltate i PDF convertiti. Ottiene il responde e crea l'oggetto in un database postgres.

queue = AWS::SQS::Queue.new(SQSADDR['my_queue'])  
    queue.poll do |msg| 
    ... 
    id = received_message['document_id'] 
    @document = Document.find(id) 
    @document.converted_at = Time.now 
    ... 
    end 

ho bisogno di aiuto !! Grazie

Answer 1

Sono disponibili tre opzioni di base:

1. fare il lavoro di sfondo come parte di un banco di lavoro. Questa è l'opzione più semplice, più diretta perché è la cosa più appropriata. I tuoi processi Web gestiscono le richieste HTTP in arrivo e il tuo processo di lavoro gestisce i messaggi SQS. Fatto.
2. Lo sfondo funziona come parte della tua web dyno. Questo potrebbe significare girare un altro thread (e affrontare i problemi che possono causare in Rails), oppure potrebbe significare fork un sottoprocesso per eseguire l'elaborazione in background. Qualunque cosa accada, tieni a mente il limite di RAM di 512 MB consumato da un banco prova e poiché suppongo tu abbia un solo dyno web, tieni presente che dyno idling significa che la tua app probabilmente non è in esecuzione 24x7. Inoltre, questa opzione ha un cattivo odore perché è generalmente contro lo spirito di 12-factor app.
3. Lo sfondo funziona come una tantum. Fai ad es. Un'attività rake handle_sqs che elabora la coda ed esce quando è vuota. Heroku Scheduler è l'ideale: eseguirlo una volta ogni 20 minuti o qualcosa del genere. Pagherai per il dyno unico per tutto il tempo in cui viene eseguito, ma dal momento che sono solo pochi secondi se la coda è vuota, costa meno di un lavoratore sempre attivo. In alternativa, l'app Web potrebbe utilizzare l'API Heroku per avviare una procedura una tantum, eseguendo a livello di programmazione l'equivalente heroku run rake handle_sqs.