Slow dispatching in big pools

In really huge connection pool (500) emongo process blocks all the requests because of linear selection of next worker.

For 500 queries which should fill whole pool it takes (501*500/2)=125000 iterations!

Original idea with pid queue seems (and works too) much better.

I'm not sure why you'd want such a large connection pool for a single app instance, but you're right that lists:nth on the supervisor children is too inefficient. The problem with the pid queue is that it has to be synchronized with the aliveness of emongo_server instances. And since those can be restarted due to the accumulation of junk data, it can get tricky to keep the queue up to date. The solution may very well be to go back to the pid queue, but with aliveness checking & updating as necessary. There's been some recent updates to the original emongo driver that I've been meaning to pull in, but I'm not sure if this case is handled at the moment.

I think emongo_server_sup must be the gen_server (not gen_supervisor) who should track children in a queue. This way we could get rid of emongo process.

Now, when we have 10 different pools emongo process has to determine proper pid for all pools alone. We see huge message queue for emongo process and mongodb instances show little load.

Yeah, that makes a lot of sense, and removes the single emongo process bottleneck. It'd be great if emongo_server_sup could be a simple_one_for_one supervisor and keep a queue of child pids, but that might require 2 separate processes. Probably better to do light supervision in a single gen_server, maybe trapping exits or monitoring pids.

resolved in revision 55: 0a8765432756