Subscription to 500-1000 collections without blowing up client

performance
1

Hi everyone, what are your thoughts on how to do this?

Right now, I have a loop that fetches 10 at a time. After the first 10 come back, the next 10 go out.

I found by subscribing to ALL DATA, it crashed my browser.

Any tips or tricks on this?

2

Can you give me a usecase for needing live updates on 1000 records?

3

Yep, I know, weird right?

  1. I have FaverCRM.com which is a CRM, I don’t really like “pagination”, I mean I may have no choice but, when I am loading my customer service tickets, I want full access. The enterprise average is like 600 cases open, some times 1000. Now, these are grouped, but, some times they want to see ALL CASES. I think I will need to cap it at like 1000.

  2. StarLordsOnline.com which is an MMO (DEF CHECK IT OUT it’s a Meteor MMO Game!). Say there are 100 Starships, that seems to be OK in the browser once initial load is done. But a stress test had like 700 players online. Loading crashed the browser. But if they came gradually it worked.

So in general it seems like Meteor has an issue transferring chunks of data, hence my inquiry! :slight_smile:

4

Ah alright, turns out I’m doing more advanced stuff. For every sub that comes in, I fetch another sub.

I just fetched 5000 records in like, 1.5 seconds. No problem. Neato.

5

Why are they all separate subscriptions?
A single sub (or a few separate ones) can easily handle 1000+ documents.
Sounds like the overhead is in creating heaps of subs instead of in the data transfer?

6

I moved all list subscriptions to one document subscriptions and then use method to fetch items which changed, or just refresh the list. But you have to update the document when the item in the list changed.

7

Yeah I think I’m on the right path. I was able to load in “Contacts” which was like 1200 people. Almost instant on production. I think it’s suitable.

My issue again was loading in “Tickets”, and tickets can have data assigned, which is generated dynamically. So thus it is a separate collection with records. On each ticket loaded, it fetches the tags.

So I think I’m just doing it wrong, or rather, complexity, which makes sense. Perhaps a better schema is to attach this case data directly into the case collection.