Excelente pregunta. Solía luchar con esta pregunta. La respuesta más común en stackoverflow es "Depende..." para prácticamente todos los problemas. Odio decirlo, pero en ningún lugar es eso más relevante que ajustar su grupo de conexiones. Realmente es un juego de oferta y demanda, donde sus solicitudes de conexión son la demanda y la oferta es la cantidad de conexiones que MySQL tiene disponibles. Realmente se trata de si su principal preocupación es evitar que las conexiones obsoletas se devuelvan del grupo, o si su preocupación es asegurarse de que MySQL no se sobrecargue con conexiones inactivas porque no las elimina lo suficientemente rápido. La mayoría de la gente se acuesta en el medio en algún lugar.
Si realmente comprende por qué alguien elegiría cualquier configuración de grupo de conexiones, créame, dejará de buscar la configuración "Rocket Solid" porque sabrá que es como buscar en Google un plan de negocios para su tienda; Está completamente arraigado en cuántas solicitudes de conexión recibe y cuántas conexiones persistentes está dispuesto a poner a disposición. A continuación doy ejemplos de por qué usaría ciertas configuraciones. Hago referencia a las variables que tendrá que cambiar dentro de la etiqueta "Recurso" de la etiqueta "Contexto" de su archivo Context.xml. Se puede ver una configuración completa de muestra en la parte inferior.
Poco tráfico
En esta situación, tiene pocas solicitudes para su aplicación, por lo que es muy probable que TODAS las conexiones en su grupo de conexiones se vuelvan obsoletas y la primera solicitud de su aplicación por parte de una conexión obsoleta provoque un error. (Dependiendo del controlador MySQL que esté usando, el error puede explicar que el último paquete recibido con éxito excedió la configuración de espera_tiempo de espera de la base de datos). Entonces, su estrategia de grupo de conexiones es evitar que se devuelva una conexión inactiva. Las siguientes dos opciones tienen pocos efectos secundarios para un sitio de poco tráfico.
-
Espere más tiempo antes de eliminar las conexiones - Harías esto cambiando el valor de
wait_timeouten su configuración de MySQL. En el banco de trabajo MYSQL, puede encontrar esa configuración fácilmente en Adminin> Archivo de configuración> Redes. Para un sitio con mucho tráfico, esto no suele recomendarse porque puede hacer que el grupo siempre esté lleno de muchas conexiones inactivas. Pero recuerda que este es el escenario de poco tráfico. -
Probar cada conexión - Puede hacer esto configurando
testOnBorrow = trueyvalidationQuery= "SELECT 1". ¿Qué pasa con el rendimiento? Tiene poco tráfico en esta situación. Probar cada conexión devuelta desde el grupo no es un problema. Todo lo que significa es que se agregará una consulta adicional a cada transacción de MySQL que realice en una sola conexión. En un sitio de poco tráfico, ¿es esto realmente algo de lo que te preocuparás? El problema de que sus conexiones se interrumpan en el grupo porque no se utilizan es su enfoque principal.
Tráfico medio
- Comprobar todas las conexiones periódicamente -Si no desea probar cada conexión cada vez que se usa, o extender el tiempo de espera, puede probar periódicamente todas las conexiones con una consulta predeterminada o personalizada de su elección. Por ejemplo, establezca
validationQuery = "SELECT 1",testWhileIdle = "true"ytimeBetweenEvictionRunsMillis = "3600"o el intervalo que quieras. Para un tráfico muy bajo, esto definitivamente requerirá más trabajo. Piénsalo. Si tiene 30 conexiones en el grupo y en 1 hora solo se llama a 4, entonces podría haber verificado fácilmente las 4 conexiones en cada solicitud usando eltestOnBorrowanterior enfoque con poco impacto en el rendimiento. Pero si, en cambio, utiliza el enfoque "Verificar todo cada hora", entonces realiza 30 solicitudes para verificar todas las conexiones cuando solo se usaron 4.
Alto Tráfico
- Elimine antes las conexiones inactivas - Esta es la situación en la que todos dicen que no debe extender el tiempo de espera y que no debe probar todas las conexiones. No es un modelo ideal para cada situación. Cuando tenga un tráfico significativo, se utilizarán todas las conexiones en el grupo y su problema real será aumentar la cantidad de conexiones disponibles y, en realidad, acortar la duración de su
wait_timepara que no termine con muchas conexiones inactivas en la base de datos. Aquí hay un ejemplo de un tipo que habla sobre cómo tiene hasta 10,000 conexiones inactivas por día para un sitio ocupado, por lo que quiere reducir el tiempo de espera Reducir el tiempo de espera para sitios ocupados
Configuración de ejemplo de 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>
Configuración web.xml de muestra
<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>
Documentación sobre las propiedades de Tomcat Pool para modificar Tomcat Pool
