That is exciting to hear @Geordie_J! Please keep us posted on how it goes and let us know if you run into any questions or issues.
Our ConnectionPool
is not quite an accurate mapping to a traditional connection pool, due to the way libmongoc designed pooling - each mongoc_client_t
actually maintains one connection per host specified in the connection string. So in a standalone configuration, one of our Connection
s is truly one connection, but if you were connected to e.g. a 3-node replica set each Connection
would be in actuality 3 connections.
Since the number of concurrent operations happening is capped by the number of threads in the NIOThreadPool
, we should expect the number of Connection
s to max out around the number of threads in the NIOThreadPool
. Though due to some libmongoc quirks types such as MongoCursor
and ClientSession
also hold onto their own Connection
s until they are killed/ended.
Yes, I definitely expect the performance to improve in a pure Swift implementation. The NIOThreadPool
usage means we have to cross threads, which could have impact on performance. As I mentioned in the "alternatives considered" section above, we went with this approach so we could make sure we had a solid API before making structural changes to our existing work.
I don't really have a good sense of how our eventual perf will compare to the Node.js driver (which my co-author @mbroadst works on in addition to this driver ) but when the time comes we do have an official benchmarks spec that will come in handy.