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.
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
Connections 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
Connections to max out around the number of threads in the
NIOThreadPool. Though due to some libmongoc quirks types such as
ClientSession also hold onto their own
Connections 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.