tomcat 7.0.42 pooling, hibernate 4.2, mysql skálopevné řešení automatického znovupřipojení

Výborná otázka. S touto otázkou se potýkám. Nejčastější odpovědí na stackoverflow je "To závisí......" pro prakticky každý problém. Nerad to říkám, ale nikde to není důležitější než ladění vašeho fondu připojení. Je to skutečně hra nabídky a poptávky, kde vaše požadavky na připojení jsou poptávkou a nabídka je počet připojení, která má MySQL k dispozici. Skutečně záleží na tom, zda je vaším primárním zájmem zabránit návratu zastaralých připojení z fondu, nebo zda je vaším zájmem zajistit, aby MySQL nebylo přetíženo nečinnými připojeními, protože je nezabíjíte dostatečně rychle. Většina lidí leží někde uprostřed.

Pokud opravdu rozumíte tomu, proč by si někdo vybral libovolnou konfiguraci jednoho fondu připojení, pak věřte, že přestanete hledat nastavení „Rocket Solid“, protože budete vědět, že je to jako googlovat obchodní plán do vašeho obchodu; Je to zcela založeno na tom, kolik žádostí o připojení dostanete a kolik trvalých připojení jste ochotni zpřístupnit. Níže uvádím příklady, proč byste použili určitá nastavení. Odkazuji na proměnné, které budete muset změnit uvnitř tagu „Resource“ tagu „Context“ vašeho souboru Context.xml. Ukázková úplná konfigurace je vidět úplně dole.

Nízký provoz

V této situaci máte na vaši aplikaci málo požadavků, takže je velká šance, že VŠECHNA připojení ve vašem fondu připojení budou zastaralá a první požadavek vaší aplikace prostřednictvím zastaralého připojení způsobí chybu. (V závislosti na ovladači MySQL, který používáte, může chyba vysvětlit, že poslední přijatý úspěšný paket překročil nastavení wait_timeout databáze). Vaší strategií fondu připojení je tedy zabránit návratu mrtvého připojení. Následující dvě možnosti mají malý vedlejší účinek na web s nízkou návštěvností.

• Počkejte déle, než zabijete připojení - Provedete to změnou hodnoty wait_timeout ve vaší konfiguraci MySQL. V MYSQL workbench můžete toto nastavení snadno najít v Admnin> Configuration file> Networking. Pro web s velkým provozem se to často nedoporučuje, protože to může vést k tomu, že se fond vždy naplní spoustou nečinných připojení. Pamatujte však, že toto je scénář nízkého provozu.

• Otestovat každé připojení – Můžete to provést nastavením testOnBorrow = true a validationQuery= "SELECT 1" . Co výkon? V této situaci máte nízký provoz. Testování každého připojení vráceného z fondu není problém. Znamená to pouze, že ke každé transakci MySQL, kterou provádíte na jednom připojení, bude přidán další dotaz. Na webu s nízkou návštěvností je to opravdu něco, čeho se budete obávat? Problém toho, že vaše připojení ve fondu zaniknou, protože se nepoužívají, je vaším hlavním cílem.

Střední provoz

• Pravidelně kontrolujte všechna připojení -Pokud nechcete testovat každé připojení pokaždé, když je použito, nebo prodlužovat dobu čekání, pak můžete pravidelně testovat všechna připojení pomocí výchozího nebo vlastního dotazu dle vašeho výběru. Nastavte například validationQuery = "SELECT 1" , testWhileIdle = "true" a timeBetweenEvictionRunsMillis = "3600" nebo jaký interval chcete. Pro velmi nízký provoz to bude vyžadovat více práce. Přemýšlejte o tom. Pokud máte ve fondu 30 připojení a za 1 hodinu se vám zavolají pouze 4, pak jste mohli snadno zkontrolovat všechna 4 připojení u každého požadavku pomocí předchozího testOnBorrow přístup s malým zásahem do výkonu. Pokud však místo toho provedete přístup „Zkontrolovat vše každou hodinu“, provedete 30 požadavků na kontrolu všech připojení, když byly použity pouze 4.

Vysoká návštěvnost

• Ukončení nečinných připojení dříve - Toto je situace, kdy všichni říkají, že byste neměli prodlužovat wait_timeout a neměli byste testovat každé připojení. Není to model ideální pro každou situaci. Když máte značný provoz, bude využito každé připojení ve fondu a váš skutečný problém se stane zvýšením počtu dostupných připojení a současně zkrácením délky vašeho wait_time takže neukončíte množství nečinných připojení na DB. Zde je příklad chlapa, který mluví o tom, že má až 10 000 nečinných připojení denně na vytíženém webu, takže chce snížit wait_timeout Snížení doby čekání pro zaneprázdněný web

Ukázka konfigurace 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>

Ukázka konfigurace 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>

Dokumentace o vlastnostech Tomcat Pool k úpravě Tomcat Pool