Perché l'osservazione dell'oplog richiede così tanto tempo in meteor/mongo?

Question

Possiedo un cluster MongoLab, che consente di utilizzare Oplog Tailing per migliorare le prestazioni, la disponibilità e la ridondanza nell'app Meteor.js.

Il problema è: da quando lo utilizzo, tutte le mie pubblicazioni richiedono più tempo per terminare. Quando richiede solo 200ms, non è un problema, ma spesso richiede molto di più, come qui, dove mi iscrivo alla pubblicazione che ho descritto here.

Questa pubblicazione ha già un tempo di risposta troppo lungo e anche le osservazioni sull'oplog la stanno rallentando, sebbene sia lontana dall'essere l'unica pubblicazione in cui l'oplog di osservazione impiega molto tempo.

Qualcuno potrebbe spiegarmi cosa sta succedendo? In nessun posto dove cerco sul web trovo spiegazioni sul perché osservare l'oplog abbia rallentato così tanto la mia pubblicazione.

Ecco alcuni screenshot da Kadira per illustrare quello che sto dicendo:

Ecco uno screenshot da un altro pub/sub:

E, infine, un dove gli oplogs di osservazione richiedono un tempo ragionevole (ma rallentano ancora il mio pub/sub un po '):

Answer 1

La coda di Oplog è molto veloce. Oplog tailing non è il problema qui.

Probabilmente stai facendo un sacco di cose che non ti rendi conto fare le pubblicazioni lento:

• One-by-one documento seguito dal aggiornamento loop: Probabilmente stai facendo un aggiornamento del documento all'interno del corpo di una chiamata Collection.forEach. Questo è incredibilmente lento e l'origine delle tue scarse prestazioni nei corpi dei metodi. Ogni volta che esegui un singolo aggiornamento del documento che viene ascoltato da centinaia di connessioni simultanee, ognuna di queste deve essere aggiornata; eseguendo una query seguita da un aggiornamento uno alla volta, né Mongo né Meteor possono ottimizzare e devono attendere che ogni singolo utente venga aggiornato ad ogni modifica. È un aumento doppiamente asintotico delle tue prestazioni. Soluzione: pensa a come eseguire l'aggiornamento utilizzando {multi:true}.
• Interrogazioni univoche per ogni utente: Se si effettua una singola modifica a un documento utente che ha detto, 100 abbonamenti unici simultanei collegati ad esso, le connessioni verranno notificate in modo seriale. Ciò significa che la prima connessione verrà notificata in 90 ms, mentre l'ultima connessione verrà notificata dopo 90 ms * 100 utenti successivamente. Questo è l'altro motivo per cui il tuo observeChanges è lento. Soluzione: Pensa se hai davvero bisogno di un abbonamento univoco per ogni documento degli utenti. Meteor ha ottimizzazioni per sottoscrizioni identiche condivise tra più raccolte simultanee.
• Un sacco di documenti: probabilmente stai codificando ogni commento di thread, post, messaggio di chat, ecc. Come proprio documento. Ogni documento deve essere inviato individualmente a ciascun cliente, introducendo alcune spese generali correlate. Questo è lo schema giusto per un database relazionale e quello sbagliato per un database basato su documenti.Soluzione: cerca di contenere ogni singola cosa necessaria per eseguire il rendering di una pagina a un utente in un singolo documento (de-normalizzazione). Per quanto riguarda la chat, dovresti avere un singolo documento di "conversazione" che contiene tutti i messaggi tra due + utenti.
• Il database non è associato all'host: Se si utilizza MongoLab, il database potrebbe non essere nello stesso datacenter del proprio host Web (che presumo sia Galaxy o Modulus). Le latenze di intra-datacenter possono essere molto, molto alte, e questa è probabilmente la spiegazione per le letture della tua povera collezione. Gli indici, come hanno notato altri commentatori, potrebbero avere un ruolo, ma la mia scommessa è che hai meno di un centinaio di dischi in ognuna di queste raccolte, quindi non avrà molta importanza.