Uitstekende vraag. Ik worstel met deze vraag. Het meest voorkomende antwoord op stackoverflow is "Het hangt ervan af..." voor vrijwel elk probleem. Ik zeg het niet graag, maar nergens is dat relevanter dan het aanpassen van je verbindingspool. Het is echt een spel van vraag en aanbod, waarbij uw verbindingsverzoeken de vraag zijn en het aanbod het aantal verbindingen dat MySQL beschikbaar heeft. Het komt er echt op neer of uw primaire zorg is om te voorkomen dat verouderde verbindingen worden geretourneerd uit de pool, of dat uw zorg ervoor zorgt dat MySQL niet wordt overbelast met inactieve verbindingen omdat u ze niet snel genoeg doodt. De meeste mensen liggen ergens in het midden.
Als je echt begrijpt waarom iemand een configuratie voor een verbindingspool zou kiezen, geloof me dan dat je stopt met zoeken naar de "Rocket Solid"-instelling, omdat je weet dat dit hetzelfde is als googlen naar een businessplan voor je winkel; Het is volledig geworteld in hoeveel verbindingsverzoeken u krijgt en hoeveel permanente verbindingen u beschikbaar wilt stellen. Hieronder geef ik voorbeelden waarom je bepaalde instellingen zou gebruiken. Ik verwijs naar variabelen die u moet wijzigen in de "Resource" -tag van de "Context" -tag van uw Context.xml-bestand. Een volledige voorbeeldconfiguratie is helemaal onderaan te zien.
Weinig verkeer
In deze situatie heb je weinig verzoeken aan je applicatie, dus de kans is groot dat ALLE verbindingen in je verbindingspool oud worden en het eerste verzoek van je applicatie door een oude verbinding een fout zal veroorzaken. (Afhankelijk van het MySQL-stuurprogramma dat u gebruikt, kan de fout verklaren dat het laatst ontvangen succesvolle pakket de wait_timeout-instelling van de database heeft overschreden). Uw strategie voor de verbindingspool is dus om te voorkomen dat een dode verbinding wordt geretourneerd. De volgende twee opties hebben weinig neveneffect voor een site met weinig verkeer.
-
Wacht langer voordat je verbindingen verbreekt - U zou dit doen door de waarde van
wait_timeout. te wijzigen in uw MySQL-configuratie. In MYSQL workbench vind je die instelling eenvoudig onder Beheer> Configuratiebestand> Netwerken. Voor een site met veel verkeer wordt dit niet vaak aanbevolen omdat het ertoe kan leiden dat de pool altijd vol zit met veel inactieve verbindingen. Maar onthoud dat dit het scenario met weinig verkeer is. -
Test elke verbinding - U kunt dit doen door
testOnBorrow = truein te stellen envalidationQuery= "SELECT 1". Hoe zit het met de prestaties? U heeft in deze situatie weinig verkeer. Het testen van elke verbinding die door de pool wordt geretourneerd, is geen probleem. Het betekent alleen dat er een extra query wordt toegevoegd aan elke MySQL-transactie die u uitvoert op een enkele verbinding. Is dit op een site met weinig verkeer echt iets waar u zich zorgen over zult maken? Het probleem van uw verbindingen die in de pool dood gaan omdat ze niet worden gebruikt, is uw primaire focus.
Gemiddeld verkeer
- Controleer alle verbindingen regelmatig -Als u niet elke verbinding wilt testen telkens wanneer deze wordt gebruikt, of de wachttijd wilt verlengen, kunt u periodiek alle verbindingen testen met een standaard of aangepaste query naar keuze. Stel bijvoorbeeld
validationQuery = "SELECT 1". in ,testWhileIdle = "true", entimeBetweenEvictionRunsMillis = "3600"of welk interval je maar wilt. Voor zeer weinig verkeer zal dit absoluut meer werk vergen. Denk er over na. Als je 30 connecties in de pool hebt en in 1 uur worden er maar 4 gebeld, dan had je gemakkelijk alle 4 connecties op elk verzoek kunnen controleren met behulp van de vorigetestOnBorrowaanpak met weinig performance hit. Maar als u in plaats daarvan de "Controleer alles elk uur"-benadering uitvoert, doet u 30 verzoeken om alle verbindingen te controleren terwijl er slechts 4 werden gebruikt.
Veel verkeer
- Dood inactieve verbindingen eerder - Dit is de situatie waarin iedereen zegt dat je de wait_timeout niet moet verlengen en dat je niet elke verbinding moet testen. Het is niet een ideaal model voor elke situatie. Wanneer u veel verkeer heeft, wordt elke verbinding in de pool gebruikt en uw werkelijke probleem wordt het verhogen van het aantal beschikbare verbindingen, terwijl de lengte van uw
wait_timewordt verkort. zodat u geen uplots van inactieve verbindingen op de DB beëindigt. Hier is een voorbeeld van een kerel die vertelt dat hij tot 10.000 inactieve verbindingen per dag heeft voor een drukke site, dus hij wil de wait_timeout De wait_timeout voor drukke site verlagen
Voorbeeld Context.xml-configuratie
<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>
Voorbeeld web.xml-configuratie
<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>
Documentatie over Tomcat Pool-eigenschappen om Tomcat Pool aan te passen