Reset session when returning to pool

[MrSmoke]

I currently have a use case were I get far better performance setting ConnectionReset to false but I still want the connection reset for safety purposes.

I was thinking that when ReturnToPool is called the connection could be reset there (if the enabled) instead of when it's pulled out of the pool, leaving the reset to be done in the background (before being added back into the pool).

It would however mean that the pool is easier to deplete.

[bgrainger]

It seems like this should work; I've created #179 to investigate it.

In my current PR, the connection is reset synchronously when MySqlConnection.Dispose is called; since the caller is still blocked, it's possible that this is not enough to increase performance.

The final solution may need to queue the work of resetting the connection (or disposing it) to a threadpool thread so that the client is freed up immediately when closing the connection. Presumably in that implementation, any exceptions would simply be swallowed and just cause the connection to be dropped from the pool. The downside would be that any errors would be silently ignored and only manifest themselves as a performance problem (because the pool would never contain live connections).

This would also be a behavioural change from the official connector, although I'm not sure it's one that would affect anyone. However, I did have to turn ConnectionReset off for a test because it was causing a session variable to be reset immediately, rather than having the desired side-effect.

@caleblloyd Any thoughts on the suggestion or proposed implementation?

[caleblloyd]

@MrSmoke what is the Round-Trip time from your client to your server (ping your MySql Host from wherever your client code resides)

[MrSmoke]

Around 1-2ms.

[caleblloyd]

How big is the speedup when you turn off connection reset? 2-4ms or is it higher? I'm wondering if what you're seeing is environment specific.

[bgrainger]

Another benefit of resetting the connection (in the background) as soon as it's returned to the pool is that it would immediately free up any session-specific server variables (e.g., temp tables). Right now, I'm assuming that those persist in memory on the server until the connection is pulled from the pool and reset.

[caleblloyd]

Right now, I'm assuming that those persist in memory on the server until the connection is pulled from the pool and reset.

Or until the connection is reaped

I can see the benefits, my main concern is forcing the reset commands to run over Sync I/O for everyone. The concurrency tests have shown that even 1ms of synchronous execution can cause a huge difference in throughput.

What about adapting Close and CloseAsync to reset the session if they are called by the user. Dispose would still not reset the connection. This would give high latency clients the option to add a manual reset at the end of a connection, and it would even support async via CloseAsync

[bgrainger]

What about adapting Close and CloseAsync to reset the session if they are called by the user. Dispose would still not reset the connection. This would give high latency clients the option to add a manual reset at the end of a connection, and it would even support async via CloseAsync

I think one of the major benefits we can provide by doing it asynchronously is that Dispose can return immediately (while the connection is reset in the background before being returned to the pool). This allows application code to resume immediately (without waiting for the latency of resetting). If concurrent connection usage is less than maximum pool size, then opening a new connection doesn't have to block either, because there are sufficient idle (and reset) connections in the pool. So you might be able to have 90% connections in use, 5% idle and waiting, and 5% returned but being reset in the background. If the idle pool can be replenished from background-reset connections faster than it's being depleted, the client would get resetting for "free".

[caleblloyd]

I hadn't considered doing it this way, I like your approach!