Faster loading a big set of data


#22

No speed up for me (


#23

You could monitor your subscription to see if the most of waiting time is actually from fetching the subscription server side or from sending the data over to the client… For the latter, there’s a couple work around you could use.

First try to see if you can use the fields option to limit the number of document information you send. Try to send the strict minimum. You could also have two subs, one for the very minimum and another, sent after for extra “goodies” info like the read/unread status and so one.

Second, you can cut your subscription using the limit, as @vigorwebsolutions pointed out. You can receive a small amount of messages so your template draws itself and the user can start reading, and then either load the rest in one bunch (this will actually certainly hang when the HTML is drawn anyways…) or load the next 10 and so on just like pagination, but without scroll events.

Note that I did not use publishWithRelations and didn’t take time to read about it…


#24

Great movie! Thank you, Josh
And now I have many-many questions…

  1. Do you have any articles about this?

  2. And now I can’t understand, what kind of indexes I need…
    For example:

    db.getCollection('items').find({
     	isActive: true,
     	till: {	$gte: new Date() },
             coords: { $geoWithin: { $box: [ [ 30,46], [ 31, 47] ] }  }
    }).sort({createdAt: -1})
    

I have index for isActive, till, createdAt and 2dsphere for coords…But looks like I need complex index…Am I right?


#25

You are correct. Indexing also gets complex when you add things like $gte, so till should always go last in the ordering that you list the complex index. Not sure how that combines with ordering for a 2d index, you may have to do further reading.

Either way, a complex index should have all the keys needed (from the selectors) to find the data you want, if you want the query to be fast.