From 342bb03144b1c08dfb7127d91522457f1c086b6d Mon Sep 17 00:00:00 2001 From: en-jin19 Date: Tue, 10 Aug 2021 19:25:22 +0200 Subject: [PATCH 1/2] best practices: add timeout options --- best-practices/java-app-best-practices.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/best-practices/java-app-best-practices.md b/best-practices/java-app-best-practices.md index fc30f91aaa334..b7097491e352f 100644 --- a/best-practices/java-app-best-practices.md +++ b/best-practices/java-app-best-practices.md @@ -189,7 +189,7 @@ update t set a = 10 where id = 1; update t set a = 11 where id = 2; update t set In addition, because of a [client bug](https://bugs.mysql.com/bug.php?id=96623), if you want to configure `rewriteBatchedStatements=true` and `useServerPrepStmts=true` during batch update, it is recommended that you also configure the `allowMultiQueries=true` parameter to avoid this bug. -#### Check parameters before execution +#### Integrate parameters Through monitoring, you might notice that although the application only performs `INSERT` operations to the TiDB cluster, there are a lot of redundant `SELECT` statements. Usually this happens because JDBC sends some SQL statements to query the settings, for example, `select @@session.transaction_read_only`. These SQL statements are useless for TiDB, so it is recommended that you configure `useConfigs=maxPerformance` to avoid extra overhead. @@ -205,6 +205,12 @@ enableQueryTimeouts=false After it is configured, you can check the monitoring to see a decreased number of `SELECT` statements. +#### Timeout-related parameters + +TiDB provides two timeout control parameters that are compatible with MySQL: `wait_timeout` and `max_execution_time`. These two parameters respectively control the connection idle timeout of the Java application and the timeout of the SQL execution in the connection; that is to say, the parameters control the longest idle time and the longest busy time for controlling the connection between TiDB and the Java application. The default value of both parameters is `0`, which by default allows the connection to be infinitely idle and infinitely busy (an infinite duration for one SQL statement to execute). + +However, in an actual production environment, idle connections and SQL that executes indefinitely negatively impact databases and applications. To avoid idle connections and SQL statements that execute for too much time, you can configure these two parameters in your application's connection string. For example, set `sessionVariables=wait_timeout=3600` (1 hour) and `sessionVariables=max_execution_time=300000` (5 minutes). + ## Connection pool Building TiDB (MySQL) connections is relatively expensive (for OLTP scenarios at least), because in addition to building a TCP connection, connection authentication is also required. Therefore, the client usually saves the TiDB (MySQL) connections to the connection pool for reuse. From d13273edcf1d3cb1759217288c3cfd1b95edc87a Mon Sep 17 00:00:00 2001 From: Enwei Date: Wed, 11 Aug 2021 09:25:31 +0200 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> --- best-practices/java-app-best-practices.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/best-practices/java-app-best-practices.md b/best-practices/java-app-best-practices.md index b7097491e352f..627e3f8bc22ab 100644 --- a/best-practices/java-app-best-practices.md +++ b/best-practices/java-app-best-practices.md @@ -207,9 +207,9 @@ After it is configured, you can check the monitoring to see a decreased number o #### Timeout-related parameters -TiDB provides two timeout control parameters that are compatible with MySQL: `wait_timeout` and `max_execution_time`. These two parameters respectively control the connection idle timeout of the Java application and the timeout of the SQL execution in the connection; that is to say, the parameters control the longest idle time and the longest busy time for controlling the connection between TiDB and the Java application. The default value of both parameters is `0`, which by default allows the connection to be infinitely idle and infinitely busy (an infinite duration for one SQL statement to execute). +TiDB provides two MySQL-compatible parameters that controls the timeout: `wait_timeout` and `max_execution_time`. These two parameters respectively control the connection idle timeout with the Java application and the timeout of the SQL execution in the connection; that is to say, these parameters control the longest idle time and the longest busy time for the connection between TiDB and the Java application. The default value of both parameters is `0`, which by default allows the connection to be infinitely idle and infinitely busy (an infinite duration for one SQL statement to execute). -However, in an actual production environment, idle connections and SQL that executes indefinitely negatively impact databases and applications. To avoid idle connections and SQL statements that execute for too much time, you can configure these two parameters in your application's connection string. For example, set `sessionVariables=wait_timeout=3600` (1 hour) and `sessionVariables=max_execution_time=300000` (5 minutes). +However, in an actual production environment, idle connections and SQL statements with excessively long execution time negatively affect databases and applications. To avoid idle connections and SQL statements that are executed for too long, you can configure these two parameters in your application's connection string. For example, set `sessionVariables=wait_timeout=3600` (1 hour) and `sessionVariables=max_execution_time=300000` (5 minutes). ## Connection pool