Summary

Streaming SDAM mode requires 2 extra connections per server: one for streaming hello, one for RTT measurements.
Polling SDAM mode requires 1 extra connection per server.

We could get Polling SDAM to be zero connection overhead (in the best case assuming no pool contention) if SDAM and application operations would share a single pooled connection. The initial connection sequence would be:

• Monitor creates unauthenticated connection, runs hello handshake, discovers server, checks connection back into the pool.
• Application thread checks connection out of the pool, runs auth handshake, executes operation, checks connection back into the pool.
• Monitor wakes for next check and reuses the pooled connection.

In scenarios where the application uses a single thread with many processes (eg AWS Lambda) this change would allow 200% more MongoClients vs Streaming SDAM and 100% more MongoClients vs Polling SDAM.

Motivation

Who is the affected end user?

Who are the stakeholders?

How does this affect the end user?

Are they blocked? Are they annoyed? Are they confused?

How likely is it that this problem or use case will occur?

Main path? Edge case?

If the problem does occur, what are the consequences and how severe are they?

Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?

Is this issue urgent?

Does this ticket have a required timeline? What is it?

Is this ticket required by a downstream team?

Needed by e.g. Atlas, Shell, Compass?

Is this ticket only for tests?

Does this ticket have any functional impact, or is it just test improvements?