Classic question I guess, but I am at a loss here. I have a subscription with a response time of around 2000 miliseconds. I am using publish composite, and the collections I am using are looking like this:
parentCollection: 2500 documents total, 1 returned
childCollection1: 33194 documents total, 14 returned
childCollection2: 4600 documents total, 14 returned
childCollection3: 250000 documents total, 14 returned
All the queries are made on indexed fields, and I don’t see any latencies on the db side in compose.
Are you using meteorhacks:kadira? That should give you a great insight of whats going on during the publish time (not sure if it works with composite).
Yes, I am, but not having the paid plan at the moment, so all I get for free is the response time of the subscription. I guess I should put some logging inside that publication and check the bottleneck. But still, even if I pinpoint, I’m still at a loss on what can be improved. But I’ll post more updates as I progress
@davethe0nly@arunoda Great! I guess DDP timeline would be of great use on the local version, as it seems to provide more info.
Right now, what I see in the trace, on the production version is
"observe on publicationName 2125ms".
If I don’t care about reactivity on this publication, is there a way to avoid the observer part? I know one way would be to use methods, but, please correct me if I’m wrong, if I use a method instead I wouldn’t have the data available in minimongo on client anymore.
You could do a client side only collection with collName = new Mongo.Collection(null) and insert the data. I don’t think it is a good idea, I think using {reactive: false} should give u an unobserved publication.
Probably methods are the way to go.
Can you point me to any article/package that makes this a bit easier to manage. Giving up the client side collections seem to be a big cost and I’m wondering if that can be avoided