Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

best practices: add timeout options for Java best practices #6136

Merged
merged 2 commits into from
Aug 25, 2021
Merged

best practices: add timeout options for Java best practices #6136

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
342bb03
best practices: add timeout options
en-jin19 Aug 10, 2021
d13273e
Apply suggestions from code review
en-jin19 Aug 11, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion best-practices/java-app-best-practices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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).
en-jin19 marked this conversation as resolved.
Show resolved Hide resolved

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).
en-jin19 marked this conversation as resolved.
Show resolved Hide resolved

## 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.
Expand Down