Excellente question. J'utilise pour lutter avec cette question. La réponse la plus courante sur stackoverflow est "Cela dépend...." pour pratiquement tous les problèmes. Je déteste le dire, mais ce n'est pas plus pertinent que de peaufiner votre pool de connexions. C'est vraiment un jeu d'offre et de demande, où vos demandes de connexion sont la demande et l'offre est le nombre de connexions dont MySQL dispose. Cela revient vraiment à savoir si votre principale préoccupation est d'empêcher le retour des connexions obsolètes du pool, ou si votre préoccupation est de vous assurer que MySQL n'est pas surchargé de connexions inactives parce que vous ne les tuez pas assez rapidement. La plupart des gens se trouvent au milieu quelque part.
Si vous comprenez vraiment pourquoi quelqu'un choisirait une configuration de pool de connexions, alors croyez-moi, vous arrêterez de rechercher le paramètre "Rocket Solid" car vous saurez que c'est comme rechercher un plan d'affaires sur Google ; Cela dépend entièrement du nombre de demandes de connexion que vous recevez et du nombre de connexions persistantes que vous êtes prêt à rendre disponibles. Ci-dessous, je donne des exemples de la raison pour laquelle vous utiliseriez certains paramètres. Je référence les variables que vous devrez modifier à l'intérieur de la balise "Resource" de la balise "Context" de votre fichier Context.xml. Un exemple de configuration complète peut être vu tout en bas.
Faible trafic
Dans cette situation, vous avez peu de demandes adressées à votre application, il y a donc de fortes chances que TOUTES les connexions de votre pool de connexions deviennent obsolètes et la première demande de votre application par une connexion obsolète provoquera une erreur. (Selon le pilote MySQL que vous utilisez, l'erreur peut expliquer que le dernier paquet réussi reçu ait dépassé le paramètre wait_timeout de la base de données). Votre stratégie de pool de connexions consiste donc à empêcher le retour d'une connexion morte. Les deux options suivantes ont peu d'effets secondaires pour un site à faible trafic.
-
Attendre plus longtemps avant de tuer les connexions - Vous feriez cela en changeant la valeur de
wait_timeoutdans votre configuration MySQL. Dans MYSQL Workbench, vous pouvez facilement trouver ce paramètre sous Admnin> Fichier de configuration> Mise en réseau. Pour un site avec beaucoup de trafic, cela n'est pas souvent recommandé car cela peut conduire à ce que le pool soit toujours rempli de nombreuses connexions inactives. Mais n'oubliez pas qu'il s'agit d'un scénario à faible trafic. -
Tester chaque connexion - Vous pouvez le faire en définissant
testOnBorrow = trueetvalidationQuery= "SELECT 1". Qu'en est-il des performances ? Vous avez un faible trafic dans cette situation. Tester chaque connexion renvoyée par le pool n'est pas un problème. Cela signifie simplement qu'une requête supplémentaire sera ajoutée à chaque transaction MySQL que vous effectuez sur une seule connexion. Sur un site à faible trafic, est-ce vraiment quelque chose qui vous préoccupera ? Le problème de vos connexions mortes dans le pool parce qu'elles ne sont pas utilisées est votre objectif principal.
Trafic moyen
- Vérifiez périodiquement toutes les connexions - Si vous ne voulez pas tester chaque connexion à chaque fois qu'elle est utilisée ou prolonger le délai d'attente, vous pouvez tester périodiquement toutes les connexions avec une requête par défaut ou personnalisée de votre choix. Par exemple, définissez
validationQuery = "SELECT 1",testWhileIdle = "true", ettimeBetweenEvictionRunsMillis = "3600"ou n'importe quel intervalle que vous voulez. Pour un trafic très faible, cela nécessitera absolument plus de travail. Pensez-y. Si vous avez 30 connexions dans le pool et qu'en 1 heure seulement 4 sont appelées, vous auriez pu facilement vérifier les 4 connexions sur chaque demande en utilisant le précédenttestOnBorrowapproche avec peu d'impact sur les performances. Mais si à la place vous utilisez l'approche "Vérifier toutes les heures", vous effectuez 30 requêtes pour vérifier toutes les connexions lorsque seulement 4 ont été utilisées.
Trafic élevé
- Éliminer les connexions inactives plus tôt - C'est la situation dans laquelle tout le monde dit que vous ne devriez pas prolonger le délai d'attente et que vous ne devriez pas tester chaque connexion. Ce n'est pas un modèle idéal pour toutes les situations. Lorsque vous avez un trafic important, chaque connexion du pool sera utilisée et votre problème réel augmentera le nombre de connexions disponibles tout en raccourcissant la durée de votre
wait_timeafin de ne pas mettre fin à des lots de connexions inactives sur la base de données. Voici un exemple d'un gars qui parle de la façon dont il a jusqu'à 10 000 connexions inactives par jour pour un site occupé, il veut donc réduire le délai d'attente Réduire le délai d'attente pour les sites occupés
Exemple de configuration Context.xml
<Context>
<Resource name="jdbc/TestDB"
auth="Container"
type="javax.sql.DataSource"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
testWhileIdle="true"
testOnBorrow="true"
testOnReturn="false"
validationQuery="SELECT 1"
validationInterval="30000"
timeBetweenEvictionRunsMillis="30000"
maxActive="100"
minIdle="10"
maxWait="10000"
initialSize="10"
removeAbandonedTimeout="60"
removeAbandoned="true"
logAbandoned="true"
minEvictableIdleTimeMillis="30000"
jmxEnabled="true"
jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;
org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer"
username="root"
password="password"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/mysql"/>
</Context>
Exemple de configuration web.xml
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<description>MySQL Test App</description>
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/TestDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</web-app>
Documentation sur les propriétés du pool Tomcat pour modifier Tomcat Pool
