Yes, but while connections are persistent there will be reconnections. I currently have the MySQLConnectionLifetimeSeconds set at 240.  This ensures that orchestrator will reconnect to the backend after a period of time. Context: firewall changes to the MySQL hosts may stop allowing new connections from orchestrator. Orchestrator will be unaware of this and if it wants to relocate or handle failover scenarios then a new connection sent to orchestrator may not work and this will cause problems. So the connections to the servers monitored by MySQL are not permanent but are only persisted for a short period of time.

So this request was making it possible to configure the max_allowed_packet setting when talking to MySQL backends as currently the value is determined exclusively by the go driver. I stand by my request that for some commands sent by orchestrator this setting may be too small and it would be good to be able to provide an appropriate setting.

Hi Simon,

   You seem to assume that the variable is queried every time there is a poll. Orchestrator uses persistent connections, this will be done only when connecting for the first time, not for every poll.

For context on 2 clusters I manage (in active/active mode):

• I see their individual 95 percentile poll latency metrics at 360ms for one cluster and 620ms for the other one, so poll latency is important as with this sort of latency orchestrator can be busy doing a large number of polls in parallel.  Doing extra queries which increase this by 10-30 ms for no good reason is not helpful I believe.

Hi Yves,

My reasoning is the following:

• I know some people using orchestrator with the poll period set at 1 second.

• I know some people using orchestrator polling thousands of servers in the poll period so orchestrator is pretty busy

• so on heavily used systems adding extra queries and extra round trips is really not a good idea, this makes the poll period last longer

• remember the query time consists of 2 parts and if you monitor multi AZ/DC systems then even if the query latency on the MySQL server in question is short the latency to send the query and get back a response may be much longer.

So on quiet systems letting orchestrator do an extra query to figure out the appropriate max_allowed_packet setting, and then setting it on the server with a session based variable change may be fine, for busy systems this extra overhead is unnecessary especially if you know what the value is anyway and can thus configure it in the connect DSN.

That seems to lead to an optional setting in orchestrator for such connections to allow for 0 (do an extra query to figure out the server's value) or 999 (an explicit value to use as the XXXMaxAllowedPacket setting.  By all means make the default 0, but provide a way for the user to be able to overwrite this with a specific setting which reduces the extra latency for each polled connection.

Hi,

   regarding this:

Why do you think it is not really desirable?  It is just at most a network round-trip and a very simple query.