Amazon SQS è la scelta giusta qui? Rails performance issue

Question

Sono vicino a rilasciare un'app per rotaie con le funzionalità di rete comuni (messaggistica, muro, ecc.). Voglio utilizzare una sorta di elaborazione in background (molto probabilmente Bj) per le attività di scarico dal ciclo richiesta/risposta.

Ciò accadrebbe quando gli utenti invitano gli amici via e-mail per partecipare e per le notifiche via e-mail.

Non sono sicuro di dover eliminare questi inviti e notifiche nel mio database, utilizzando un modello e quindi elaborarlo con un processo di lavoro ogni x minuti o se dovrei andare per Amazon SQS, archiviare i messaggi e invita lì e consente al mio operatore di recuperarlo da Amazon SQS per l'elaborazione (invio di inviti/notifiche).

L'approccio Amazon si scaricava dal mio database ma immagino che sia più lento recuperare i messaggi da lì.

Cosa ne pensi?

Answer 1

Il tuo titolo indica che hai un problema di prestazioni di Rails, ma lo sai per certo? Dal resto della tua domanda sembra che tu stia cercando di anticipare un possibile problema di prestazioni future. L'unico modo per gestire in modo ragionevole i problemi di prestazioni è quello di ottenere la tua applicazione e di tracciarla. In questo modo fornirai dati empirici su quali siano i veri problemi di prestazioni.

Dato che Amazon SQS non è gratuito e il fatto che l'uso sarà quasi certamente aggiungere complessità alla vostra applicazione, vorrei migrare ad esso se e quando carico del database diventa un problema. Non cercare di indovinare i problemi prima che si verifichino, perché scoprirai che probabilmente incontrerai diversi problemi quando la tua app sarà attiva, alcuni dei quali probabilmente non hai preso in considerazione.

Il punto principale è che hai già deciso di utilizzare l'elaborazione in background, che è la decisione corretta, dato che qualsiasi tipo di elaborazione non istantanea non appartiene al ciclo di richiesta/risposta di Rails, come blocca quel processo di Rails. Puoi sempre scalare con Amazon in seguito, se necessario.

Answer 2

Sono d'accordo con John Topley sul fatto che non si desideri complicare eccessivamente l'applicazione se non è necessario. Detto questo, ci sono dei momenti in cui è opportuno prendere questo tipo di decisione in anticipo, prevedi un carico elevato sin dall'inizio? Stai trasmettendo questo a una base di utenti esistente o è un sito pubblico che può o meno decollare?

Se si sa che sarà necessario gestire una grande quantità di traffico dall'inizio, questo potrebbe essere un buon passo. Se non vuoi spendere i soldi per usare SQS dai uno sguardo ad alcune delle soluzioni di coda gratuite là fuori come RabbitMQ.

Attualmente spingo un paio di milioni di messaggi al mese tramite SQS e funziona piuttosto bene. Assicurati di pianificare di rallentare o rallentare di tanto in tanto, quindi dovresti lavorare in alcune strutture di riprova e backoff esponenziale. Una delle cose buone è che puoi ottenere 10 messaggi alla volta che accelera la possibilità di lavorare attraverso la coda, puoi usare una richiesta per ottenere i 10 messaggi ed elaborarli 1 per 1.

Answer 3

La tua app già ospitato su Amazon EC2? Probabilmente non avrei spostato un'app esistente su AWS solo per poter utilizzare SQS, ma se stai già utilizzando l'infrastruttura di Amazon, SQS è una grande scelta. Potresti sicuramente impostare il tuo sistema di messaggistica (come RabbitMQ), ma andando con SQS è una cosa in meno di cui ti devi preoccupare.

Ci sono un sacco di opzioni per aggiungere l'elaborazione in background per applicazioni Rails, come ad esempio delayed_job o background_job, ma il mio preferito è Workling. Ti offre un gradevole livello di astrazione che ti consente di collegare diversi corridori in background senza dover cambiare l'effettiva implementazione dei tuoi lavori.

Mantengo un Workling fork that adds an SQS client. Ci sono alcune carenze (leggi i commenti o my blog post per maggiori dettagli), ma nel complesso ha funzionato bene per noi al mio ultimo avvio.

Ho anche utilizzato SQS per un progetto Ruby (non-Rails) separato e in genere lo ho trovato affidabile e abbastanza veloce. Come già detto in precedenza da James, puoi leggere fino a 10 messaggi contemporaneamente, quindi ti consigliamo di farlo (il mio client SQS di Workling fa questo e memorizza i messaggi localmente).

Answer 4

In caso di problemi con lo spostamento in EC2, è possibile utilizzare altri servizi come onlinemq.com.

Answer 5

Amazon SQS è un ottimo servizio, a meno che le seguenti cose diventano importanti:

• prestazioni
• legali
• Riconoscimenti e operazioni
• messaggistica Idiomi Proprietà messaggio
• sicurezza, autenticità e Coda
• Autorizzazioni

Se una di queste cose è importante, è necessario consultare un vero servizio MQ aziendale come StormMQ, RabbitMQ o anche onlinemq.com.

Ho trovato questa serie di blog interessante in quanto mette a confronto Amazon SQS per StormMQ senza tenere pugni indietro: http://blog.stormmq.com/2011/01/06/apples-and-oranges-performance/