Fremragende spørgsmål. Jeg plejede at kæmpe med dette spørgsmål. Det mest almindelige svar på stackoverflow er "Det afhænger..." for stort set alle problemer. Jeg hader at sige det, men nej hvor er det mere relevant end at justere din forbindelsespulje. Det er virkelig et spil med udbud og efterspørgsel, hvor dine forbindelsesanmodninger er efterspørgslen, og udbuddet er antallet af forbindelser, MySQL har til rådighed. Det kommer virkelig ned på, om din primære bekymring er at forhindre forældede forbindelser i at blive returneret fra poolen, eller om din bekymring er at sikre, at MySQL ikke bliver overbelastet med ledige forbindelser, fordi du ikke dræber dem hurtigt nok. De fleste ligger et eller andet sted i midten.
Hvis du virkelig forstår, hvorfor nogen ville vælge en hvilken som helst forbindelsespoolkonfiguration, så tro mig, du vil stoppe med at søge efter indstillingen "Rocket Solid", fordi du vil vide, at det er ligesom at google efter en forretningsplan for din butik; Det er helt rodfæstet i, hvor mange forbindelsesanmodninger du får, og hvor mange vedvarende forbindelser du er villig til at stille til rådighed. Nedenfor giver jeg eksempler på, hvorfor du ville bruge visse indstillinger. Jeg henviser til variabler, som du bliver nødt til at ændre i "Resource"-tagget i "Context"-tagget i din Context.xml-fil. Et eksempel på fuld konfiguration kan ses helt nederst.
Lav trafik
I denne situation har du få anmodninger til din applikation, så der er en god chance for, at ALLE forbindelser i din forbindelsespulje bliver forældede, og den første anmodning fra din applikation med en forældet forbindelse vil forårsage en fejl. (Afhængigt af den MySQL-driver du bruger, kan fejlen forklare, at den sidst modtagne pakke overskred databasens wait_timeout-indstilling). Så din forbindelsespuljestrategi er at forhindre en død forbindelse i at blive returneret. De følgende to muligheder har en lille bivirkning for et websted med lav trafik.
-
Vent længere, før du afbryder forbindelser - Du ville gøre dette ved at ændre værdien af
wait_timeouti din MySQL-konfiguration. I MYSQL workbench kan du nemt finde den indstilling under Admnin> Konfigurationsfil> Netværk. For et websted med masser af trafik anbefales dette ikke ofte, fordi det kan føre til, at poolen altid bliver fyldt med masser af ledige forbindelser. Men husk, at dette er scenariet med lav trafik. -
Test hver forbindelse - Du kan gøre dette ved at indstille
testOnBorrow = trueogvalidationQuery= "SELECT 1". Hvad med ydeevne? Du har lav trafik i denne situation. Det er ikke et problem at teste hver forbindelse, der returneres fra poolen. Alt det betyder er, at en ekstra forespørgsel vil blive tilføjet til hver MySQL-transaktion, du udfører på en enkelt forbindelse. På et websted med lav trafik er dette virkelig noget, du vil bekymre dig om? Problemet med, at dine forbindelser går døde i poolen, fordi de ikke bliver brugt, er dit primære fokus.
Middel trafik
- Tjek alle forbindelser med jævne mellemrum -Hvis du ikke vil teste hver forbindelse, hver gang den bruges, eller forlænge ventetiden, så kan du med jævne mellemrum teste alle forbindelser med en standard- eller brugerdefineret forespørgsel efter eget valg. Indstil f.eks.
validationQuery = "SELECT 1",testWhileIdle = "true", ogtimeBetweenEvictionRunsMillis = "3600"eller hvilket interval du ønsker. For meget lav trafik vil dette absolut kræve mere arbejde. Tænk over det. Hvis du har 30 forbindelser i puljen og i løbet af 1 time kun 4 bliver ringet op, så kunne du nemt have tjekket alle 4 forbindelser på hver anmodning ved at bruge den forrigetestOnBorrowtilgang med lille præstationshit. Men hvis du i stedet bruger "Check all every hour"-tilgangen, laver du 30 anmodninger om at kontrollere alle forbindelser, når kun 4 blev brugt.
Høj trafik
- Dræb inaktive forbindelser før - Dette er den situation, der får alle til at sige, at du ikke bør forlænge wait_timeout, og du bør ikke teste alle forbindelser. Det er ikke en model, der er ideel til enhver situation. Når du har betydelig trafik, vil hver forbindelse i puljen blive brugt, og dit faktiske problem vil blive at øge antallet af tilgængelige forbindelser, mens du faktisk forkorter længden af din
wait_timeså du ikke ender uplots af ledige forbindelser på DB. Her er et eksempel på en fyr, der taler om, hvordan han har op til 10.000 ledige forbindelser om dagen på et travlt websted, så han ønsker at sænke wait_timeout Sænkning af wait_timeout for travlt websted
Eksempel på Context.xml-konfiguration
<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>
Eksempel på web.xml-konfiguration
<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>
Dokumentation om Tomcat Pool-egenskaber til tweak Tomcat Pool