Utilizzo della memoria lato server Meteor per migliaia di utenti simultanei

Question

In base a this answer, sembra che il server meteorologico mantenga una copia in memoria della cache per ciascun client connesso. La mia comprensione è che viene utilizzato al fine di evitare l'invio di più copie di dati quando si tratta di abbonamenti sovrapposti su un client.

La parte rilevante della risposta linked (corsivo è mio):

La scatola unione: Il lavoro della scatola di fusione è quello di combinare i risultati (aggiunti, chiamate modificati e rimossi) di tutto ad un le funzioni di pubblicazione attive del client in un singolo flusso di dati. C'è una casella di unione per ogni client connesso. Contiene una copia completa della cache del minimongo del client, .

Assumendo che la risposta è ancora preciso nella versione corrente di meteora, non poteva che creare un enorme spreco di memoria sul server come il numero di utenti aumenta?

Come calcolo immediato, se un'app aveva circa una cache da 100 kB per client, 10.000 utenti contemporanei consumerebbero 1 GB di memoria sul server e 100.000 utenti un enorme 10 GB! Questo sarebbe vero anche se ogni cliente stava guardando dati quasi identici. Sembra plausibile che un'applicazione utilizzi molti più dati di quella per cliente, il che aggraverebbe ulteriormente il problema.

Questo problema esiste nella versione corrente di Meteor? In tal caso, quali tecniche possono essere utilizzate per limitare la quantità di memoria che il server deve utilizzare per gestire tutte le sottoscrizioni dei clienti?

Answer 1

Date un'occhiata a questo post di Arunoda al suo meteorhacks.com blog:
http://meteorhacks.com/making-meteor-500-faster-with-smart-collections.html

che parla della sua pagina di collezioni intelligenti:
http://meteorhacks.com/introducing-smart-collections.html

Ha creato uno stack Collection alternativa che è riuscita nei suoi obiettivi di velocità, efficienza (memoria & cpu) e scalabilità (puoi vedere un confronto grafico nel post). Effettivamente nei suoi test l'utilizzo della RAM è stato negligente con entrambi i tipi di raccolta, anche se il modo in cui ha implementato le cose dovrebbe essere una differenza molto ovvia con il tipo di caso d'uso che hai citato.

Inoltre, si può vedere in questo post su meteoriti-core:
https://groups.google.com/d/msg/meteor-core/jG1KLObX1bM/39aP4kxqWZUJ
che gli sviluppatori meteorici sono a conoscenza del suo lavoro e cooperano nell'attuazione alcuni dei miglioramenti in Meteor stessa (ma fino ad allora il suo pacchetto intelligente funziona alla grande).

Nota importante! Le collezioni intelligenti si basano sull'accesso a Mongo Oplog. Questo è facile se stai utilizzando la tua macchina o l'infrastruttura ospitata. Se stai usando un database basato su cloud, questa opzione potrebbe non essere disponibile, o se lo è, costerà molto più dei pacchetti più piccoli.