Slow working subreports (mongodb) - mongodb

Question

The report to which I asked this question has grown to an additional three subreports.
Each of them counts a number of documents.
Main report:
{
runCommand : {
aggregate : 'Collection',
pipeline : [
{ $match : { time : { '$gte' : '$P!{sttime}', '$lt' : '$P!{edtime}' }}},
{ $match : { owner_id : $P{id} } },
{ $match : { status : 0 } },
{ $group : { _id : { StatusID : '$status', SID : '$sid', UserID : '$owner_id', GroupID : '$group_id' }, count : { $sum : 1} } }
]
}
}
User must set a timeframe (Timestamp type of date) and provide the user, for which the report will be filled.
Then selected timeframe, owner_id and sid transmitted in each subreport as parameters.
Subreport:
{
runCommand : {
aggregate : 'Collection',
pipeline : [
{ $match : { update_time : { '$gte' : '$P!{sttime}', '$lt' : '$P!{edtime}' }}},
{ $match : { sid : $P{sid} } },
{ $match : { owner_id : $P{id} } },
{ $match : { status : 1 } },
{ $group : { _id : { StatusID : '$status' }, count : { $sum : 1} } }
]
}
}
The other subreports same as above, except { $match : { status : 1 } }, where is like:
{ $match : { status : 2 } }
and
{ $match : { status : 3 } }
respectively.
I'm working with a large collection, where in 2 hour timeframe about 400.000 documents.
The maximum timframe where the report showed results is 8 hours.
Anything more than this period of time falls on timeout.
Filling the "2 hour timeframe" takes about 10 minutes.
Tried to use {explain : true} to each request individually. Speed results were the fastest in the form in which they are written.
"cursor" : {
"cursor" : "BtreeCursor update_time_1_owner_id_1_status_1_group_id_1",
"isMultiKey" : false,
"n" : 379843,
"nscannedObjects" : 379843,
"nscanned" : 379843,
"nscannedObjectsAllPlans" : 379843,
"nscannedAllPlans" : 379843,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 13,
"nChunkSkips" : 0,
"millis" : 694,
This example on 2 hour timeframe.
Is there any way to speed up filling the report? Somehow to unite the queries? Or something else?
Goal is to increase possible period of month to report (If this possible)

Answer 1

MongoDB 2.4 and earlier do not merge consecutive calls to $match, so your first $match will use an index and subsequent matches will be done in memory on the ~400k documents fetched for your aggregation pipeline. Given you have two or three subsequent $match operations, this processing isn't going to be overly efficient.
FYI, the issue of coalescing consecutive $match calls been addressed in MongoDB 2.6 (see SERVER-11184), but for clarity I think you would still be best combining the $match statements before doing an $explain.
Also, since you are doing range queries on update_time, you probably want to move that later in your compound index so the equality checks on owner, status, and group_id can be used to filter results before range comparisons. The blog post Optimizing MongoDB Compound Indexes has some relevant explanation for this approach.