Open niranpr opened 13 years ago
Currently I would recommend a single Mongolian object per node instance. It can handle multiple simultaneous asynchronous requests. Creating a Mongolian object for every request would introduce unnecessary I/O overhead.
For high performance situations, and depending on your node and mongodb setup, a pool of multiple connections may give you a performance gain—but I wouldn't go that route until you've profiled your system and found it to be a bottleneck.
Eventually connection pooling will be integrated into the Mongolian core once I've had more chance to investigate its cost/benefits. Please feel free to test/benchmark different configurations yourself and report back!
I found out that, for some unknown situation when concurrency increased, mongolian couldn't communicate with mongodb (timeout occurred). mongodb's health was fine so do node's health was also fine. but after restarted node, it went back to work properly for some period of time, and the problem rose again. I do load balance for 4 node instances, when mongolian of one instance was dead, the rest 3 were still fine and work properly. I though middleware got a communication problem with mongodb for some reason.
Anyway to track how this problem came from? is that because of some strange requests cause the single/shared mongolian object of that node instance went dead without returning error.
Your analysis makes sense. I'm wondering if the server thread locked up from some request.
Mongolian DB doesn't have any request/connection timeout feature right now, but perhaps one is in order?
Is it a good way to share mongodb connection between users? Let's say 100 incoming requests come to node, those 100 requests share the same db connection or should we separate them to 100 db connections? And if we choose to separate connections, what if 2,000 incoming requests come to node? can mongodb handle 2,000 db connections in case we didn't do sharding.