Given that you're invoking the group
command instead of performing a basic read query, you may also be fighting against the JavaScript interpreter in MongoDB 2.2. It's not until 2.4 that the JavaScript interpreter was enhanced to support concurrent execution. If each of these group operations requires JS evaluation (at the very least for the reduce
function), you're looking at widespread resource starvation.
I don't have any explanation for the "too many connection" exceptions. Even 800 concurrent connections falls well below MongoDB's limit of 20,000 (note: this is being removed for 2.6 in SERVER-8943).
One idea to refactor you application and avoid the group
race condition would be to use a single document as a lock for a PHP process to recompute the result and refill the cache. Using findAndModify
, you could have a single document with some string _id
(e.g. "Order.History group") and another active
field. When a PHP process gets a cache miss and would need to recompute the result, it can first attempt to execute findAndModify
and find the appropriate _id
where active
is false
, updating active
to true
in the same, atomic operation. Only after getting this lock document back should it proceed with the group
command. Other PHP processes that can't find the lock document (because active
will not be false
) could be instructed to sleep for a bit, return stale data, or abort the web request.