Connection handshakes - Amazon Aurora MySQL Database Administrator’s Handbook

Connection handshakes

A lot of work can happen behind the scenes when an application connector or a graphical user interface (GUI) tool opens a new database session. Drivers and client tools commonly run series of statements to set up session configuration (for example, SET SESSION variable = value). This increases the cost of creating new connections and delays when your application can start issuing queries.

The cost of connection handshakes becomes even more important if your applications are very sensitive to latency. OLTP or key-value workloads that expect single-digit millisecond latency can be visibly impacted if each connection is expensive to open. For example, if the driver runs six statements to set up a connection and each statement takes just one millisecond to run, your application will be delayed by six milliseconds before it issues its first query.

Recommendations:

  • Use the Aurora MySQL Advanced Audit, the General Query Log, or network-level packet traces (for example, with tcpdump) to obtain a record of statements executed during a connection handshake. Whether or not you’re experiencing connection or latency issues, you should be familiar with the internal operations of your database driver.

  • For each handshake statement, you should be able to explain its purpose and describe its impact on queries you'll subsequently run on that connection.

  • Each handshake statement requires at least one network roundtrip and will contribute to higher overall session latency. If the number of handshake statements appears to be significant relative to the number of statements doing actual work, determine if you can disable any of the handshake statements. Consider using connection pooling to reduce the number of connection handshakes.