J'ai déjà écrit un article comme celui-ci.

** Prise en charge des échecs lors de l'utilisation du pool de connexions pour se connecter au cluster Amazon Aurora **

À ce moment-là, j'ai utilisé DBCP2 pour le pool de connexions car je migrais de l'environnement Tomcat 8 + MySQL 5.5 sur site vers le cluster Tomcat 8 + Aurora (compatible MySQL) sur AWS EC2, mais il y avait divers problèmes et l'ajustement était difficile.

Cette fois, je vais remplacer cela par HikariCP (2.7.6) et voir comment cela change.

Problèmes avec la connexion Apache DBCP2

En un mot, c'est ** "juste lent" **. En particulier, «le processus d'acquisition (d'emprunt) d'une connexion au pool est lent».

pour cette raison,

Aurora met beaucoup de temps à se reconnecter pendant le basculement
Afin de pouvoir se reconnecter à l'instance Writer après le basculement, il est nécessaire de définir les paramètres liés à l'expulsion des connexions anormales, mais cela devient une surcharge opérationnelle et ralentit encore l'ensemble du processus.
Sous une charge importante, le processus se bloque lorsqu'il est nécessaire d'augmenter le nombre de connexions dans le pool (par exemple lorsque du SQL lent occupe la connexion dans le pool pendant une longue période), et la connexion Le nombre n'augmente pas

Il est facile d'entrer dans une telle situation.

Qu'est-ce que Hikari CP

Il s'agit d'un pool de connexions à haut débit, simple et hautement fiable.

HikariCP. It's faster.
brettwooldridge/HikariCP（GitHub）

La page d'introduction montre comment intégrer dans Maven.

La version affichée peut être obsolète, veuillez donc vérifier README.md sur GitHub.

Je pense que beaucoup de gens l'utilisent en combinaison avec Hibernate, je vais donc omettre l'explication détaillée.

Remplacé de DBCP2 et testé

Dans une certaine application Web (exécutée sur Tomcat 8), utilisez JNDI DataSource Factory et essayez de l'incorporer au format basé sur le pilote.

Avant le remplacement (DBCP2)

`Connexion DBCP2`


<Context reloadable="true" crossContext="true">
        <Resource
                name="jdbc/[Nom du pool de connexions]"
                auth="Container"
                type="javax.sql.DataSource"
                driverClassName="com.mysql.jdbc.Driver"
                factory="org.apache.commons.dbcp.BasicDataSourceFactory"
                url="jdbc:mysql://[Point de terminaison du cluster]/[Nom de la base de données]?useUnicode=true&amp;characterEncoding=utf8&amp;connectTimeout=10000&amp;socketTimeout=180000&amp;alwaysSendSetIsolation=false&amp;cacheServerConfiguration=true&amp;elideSetAutoCommits=true&amp;useLocalSessionState=true"
                username="[Nom d'utilisateur connecté]"
                password="[Mot de passe de connexion]"
                maxTotal="300"
                maxIdle="150"
                minIdle="10"
                initialSize="10"
                testOnBorrow="true"
                validationQuery="select concheck.validation()"
                validationQueryTimeout="10"
                timeBetweenEvictionRunsMillis="60000"
                maxWait="10000" />
</Context>

Après remplacement (HikariCP)

`Connexion Hikari CP`


<Context reloadable="true" crossContext="true">
        <Resource
                name="jdbc/[Nom du pool de connexions]"
                auth="Container"
                type="javax.sql.DataSource"
                driverClassName="com.mysql.jdbc.Driver"
                factory="com.zaxxer.hikari.HikariJNDIFactory"
                jdbcUrl="jdbc:mysql://[Point de terminaison du cluster]/[Nom de la base de données]?useUnicode=true&amp;characterEncoding=utf8&amp;connectTimeout=10000&amp;socketTimeout=180000&amp;alwaysSendSetIsolation=false&amp;cacheServerConfiguration=true&amp;elideSetAutoCommits=true&amp;useLocalSessionState=true"
                dataSource.implicitCachingEnabled="true"
                dataSource.user="[Nom d'utilisateur connecté]"
                dataSource.password="[Mot de passe de connexion]"
                minimumIdle="10"
                maximumPoolSize="300"
                connectionTimeout="10000"
                idleTimeout="180000"
                maxLifetime="180000"
                connectionInitSql="select concheck.validation()"
                validationTimeout="9800" />
</Context>

Pour les requêtes de confirmation pour la prise en charge du basculement (voir Article ci-dessus pour plus de détails), ** connectionTestQuery ** n'est pas recommandé * Il est écrit dans * connectionInitSql **. Même si vous l'écrivez ici, si une erreur est renvoyée (= vous vous êtes connecté à l'instance Reader en mode lecture / écriture), il fermera la connexion et se reconnectera.

Comparaison

JMeter a envoyé 3 000 requêtes (750 threads) par minute à une application Web pendant 45 minutes. Ensuite, sur plusieurs requêtes d'écran dans l'application Web, j'ai extrait trois types de temps de traitement brut (lorsqu'ils sont exécutés indépendamment): court / moyen / long.

L'unité est la milliseconde. Notez que ** la quantité de données varie considérablement d'un thread à l'utilisateur, de sorte que le temps de traitement de SQL sur l'écran "long" varie même dans son état d'origine ** (jusqu'à 8,5 secondes). Les autres conditions sont les suivantes.
4 serveurs Web (EC2 r4.large / Amazon Linux 2017/09 version / 2 pour chaque AZ / Tomcat 8.0.47)
Aurora a db.r4.2xlarge comme base de données principale, 2 clusters / 1 chaque cluster Writer / Reader / Ver.1.16
Les résultats sont agrégés par JMeter (2 clients JMeter)

** Résultats DBCP2 **

Demande (écran)	Valeur moyenne	Médian	90%valeur	最小valeur	最大valeur
Écran de traitement à court terme	60	49	78	24	22,832
Écran moyen	234	177	332	86	21,607
Écran de traitement de longue durée	728	171	1,827	45	24,557

** Résultats Hikari CP **

Demande (écran)	Valeur moyenne	Médian	90%valeur	最小valeur	最大valeur
Écran de traitement à court terme	46	45	57	22	347
Écran moyen	172	158	242	83	3,087
Écran de traitement de longue durée	676	146	1,703	41	9,524

Hikari CP est globalement rapide, mais ** le maximum est remarquable **.

Dans le cas du DBCP2, court / moyen / long sont tous dans la plage de 20 secondes. Ce n'est pas parce que le traitement du serveur de base de données (Aurora) ralentit lorsque SQL circule en parallèle, mais il y a un temps d'attente (affecté par le traitement d'autres threads) pour acquérir (emprunter) une connexion du pool. Indique que vous faites.

En revanche, dans le cas de HikariCP, si le nombre de requêtes est à peu près à ce niveau, une réponse est renvoyée dans la plage ** "temps de traitement SQL brut + α" **.

Opération de basculement

Avec DBCP2, lorsque la charge de fonctionnement d'une application devient élevée, cela tend à devenir une situation où la reconnexion après le basculement est immédiatement bloquée. Lorsque j'ai exécuté le basculement avec HikariCP sous la charge ci-dessus, il était dans un état où la reconnexion a été effectuée en peu de temps, comme indiqué dans la figure ci-dessous.

Résumé

La différence n'est pas si perceptible lorsque la charge est faible, mais dans le cas d'un système avec une certaine charge, les performances changent considérablement en fonction du pool de connexions, ce qui augmente également la capacité du nombre de connexions (plage évolutive) et la stabilité de l'opération de basculement. Il s'avère que cela changera beaucoup.

En particulier, lors de la migration de l'environnement sur site vers un environnement AWS ou de la migration uniquement de la base de données vers Aurora, le délai de communication (latence) du serveur Web et du client qui émet SQL devient important ** "Quel était le problème avec DBCP2 auparavant? Je n'en avais pas, mais dès que j'ai migré, le nombre de connexions n'a pas bien évolué et s'est obstrué. »** et d'autres événements ont tendance à se produire, donc je pense qu'il est nécessaire de vérifier soigneusement lors de la migration.

** Article lié à Amazon Aurora publié sur Qiita **

Utilisez Hikari CP pour regrouper la connexion au cluster Amazon Aurora