[MXS-4046] Connection recycling is unnecessarily slow Created: 2022-03-14  Updated: 2022-03-18  Resolved: 2022-03-18

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: None
Fix Version/s: 22.08.0

Type: Bug Priority: Major
Reporter: markus makela Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by MDEV-28059 COM_CHANGE_USER always responds with ... Open
Sprint: MXS-SPRINT-153

 Description   

Using COM_RESET_CONNECTION is faster than using COM_CHANGE_USER if the user is the same. In certain cases the whole connection reset can be avoided if both the connection and the client reusing it have no history and the users match.

For connection sharing, this can also be extended to allow the connections to be shared as-is if both the user and the history state are an exact match. This should improve the latency but the effectiveness of this in practice needs to be measured.

Once the COM_RESET_CONNECTION part is implemented, further optimizations can be done. If there are no connection initialization queries, the pending session command history can be sent at the same time that the COM_RESET_CONNECTION is sent. This eliminates one roundtrip that is normally taken when COM_CHANGE_USER is used. This could also be done even if there are connection initialization queries but this requires some work.



 Comments   
Comment by markus makela [ 2022-03-14 ]

Initial testing shows that with MariaDB 10.4 and newer, the old COM_CHANGE_USER fast-path of sending an OK packet as the first response is no longer taken. Instead, an AuthSwitchRequest packet is sent which causes an extra roundtrip to take place. Turns out this might be a bug (MDEV-28059).

Generated at Thu Feb 08 04:25:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.