बेहतरीन सवाल। मैं इस सवाल से जूझता था। स्टैक ओवरफ्लो पर सबसे आम उत्तर लगभग हर समस्या के लिए "यह निर्भर करता है ..." है। मुझे यह कहने से नफरत है लेकिन आपके कनेक्शन पूल को ट्विक करने से कहीं ज्यादा प्रासंगिक नहीं है। यह वास्तव में आपूर्ति और मांग का खेल है, जहां आपके कनेक्शन अनुरोध मांग हैं और आपूर्ति MySQL के उपलब्ध कनेक्शनों की संख्या है। यह वास्तव में नीचे आता है कि क्या आपकी प्राथमिक चिंता पुराने कनेक्शन को पूल से वापस आने से रोक रही है, या क्या आपकी चिंता यह सुनिश्चित कर रही है कि MySQL निष्क्रिय कनेक्शन के साथ अतिभारित नहीं हो रहा है क्योंकि आप उन्हें तेजी से नहीं मार रहे हैं। ज्यादातर लोग बीच में कहीं लेटे हैं।
यदि आप वास्तव में समझते हैं कि कोई एक कनेक्शन पूल कॉन्फ़िगरेशन क्यों चुनता है तो मेरा विश्वास करें कि आप "रॉकेट सॉलिड" सेटिंग की खोज करना बंद कर देंगे क्योंकि आपको पता चल जाएगा कि यह आपकी दुकान के लिए व्यवसाय योजना के लिए गुगल करने जैसा है; यह पूरी तरह से इस बात पर निर्भर करता है कि आपको कितने कनेक्शन अनुरोध मिलते हैं और आप कितने लगातार कनेक्शन उपलब्ध कराने के इच्छुक हैं। नीचे मैं उदाहरण देता हूं कि आप कुछ सेटिंग्स का उपयोग क्यों करेंगे। मैं उन चरों का संदर्भ देता हूं जिन्हें आपको अपनी Context.xml फ़ाइल के "संदर्भ" टैग के "संसाधन" टैग के अंदर बदलना होगा। एक नमूना पूर्ण कॉन्फ़िगरेशन सबसे नीचे देखा जा सकता है।
कम ट्रैफ़िक
इस स्थिति में आपके आवेदन के लिए आपके पास कुछ अनुरोध हैं, इसलिए एक अच्छा मौका है कि आपके कनेक्शन पूल में सभी कनेक्शन पुराने हो जाएंगे और आपके आवेदन द्वारा पुराने कनेक्शन द्वारा पहला अनुरोध एक त्रुटि का कारण बन जाएगा। (MySQL ड्राइवर के आधार पर आप त्रुटि का उपयोग कर रहे हैं, यह समझा सकता है कि प्राप्त अंतिम सफल पैकेट डेटाबेस की प्रतीक्षा_टाइमआउट सेटिंग से अधिक हो गया है)। तो आपकी कनेक्शन पूल रणनीति एक मृत कनेक्शन को वापस आने से रोकने के लिए है। निम्न दो विकल्पों का निम्न ट्रैफ़िक साइट के लिए बहुत कम दुष्प्रभाव है।
-
कनेक्शन खत्म करने से पहले और प्रतीक्षा करें - आप
wait_timeout. के मान को बदलकर ऐसा करेंगे आपके MySQL कॉन्फ़िगरेशन में। MYSQL कार्यक्षेत्र में आप उस सेटिंग को आसानी से व्यवस्थापक> कॉन्फ़िगरेशन फ़ाइल> नेटवर्किंग के अंतर्गत पा सकते हैं। बहुत अधिक ट्रैफ़िक वाली साइट के लिए अक्सर इसकी अनुशंसा नहीं की जाती है क्योंकि इससे पूल हमेशा बहुत सारे निष्क्रिय कनेक्शनों से भरा रहता है। लेकिन याद रखें कि यह निम्न ट्रैफ़िक परिदृश्य है। -
हर कनेक्शन का परीक्षण करें - आप इसे
testOnBorrow = true. सेट करके कर सकते हैं औरvalidationQuery= "SELECT 1". प्रदर्शन के बारे में क्या? इस स्थिति में आपके पास कम ट्रैफ़िक है। पूल से लौटाए गए प्रत्येक कनेक्शन का परीक्षण करना कोई समस्या नहीं है। इसका मतलब यह है कि एक ही कनेक्शन पर आपके द्वारा किए जा रहे प्रत्येक MySQL लेनदेन में एक अतिरिक्त क्वेरी जोड़ दी जाएगी। कम ट्रैफिक वाली साइट पर क्या यह वास्तव में ऐसी चीज है जिसके बारे में आप चिंतित होंगे? पूल में आपके कनेक्शन के मृत होने की समस्या क्योंकि उनका उपयोग नहीं किया जा रहा है, आपका प्राथमिक ध्यान है।
मध्यम ट्रैफ़िक
- सभी कनेक्शनों की समय-समय पर जांच करें -यदि आप हर बार उपयोग किए जाने पर प्रत्येक कनेक्शन का परीक्षण नहीं करना चाहते हैं, या प्रतीक्षा समय समाप्त नहीं करना चाहते हैं, तो आप समय-समय पर अपने चयन के डिफ़ॉल्ट या कस्टम क्वेरी के साथ सभी कनेक्शनों का परीक्षण कर सकते हैं। उदाहरण के लिए सेट करें
validationQuery = "SELECT 1",testWhileIdle = "true", औरtimeBetweenEvictionRunsMillis = "3600"या जो भी अंतराल आप चाहते हैं। बहुत कम यातायात के लिए इसमें बिल्कुल अधिक काम करने की आवश्यकता है। इसके बारे में सोचो। यदि आपके पास पूल में 30 कनेक्शन हैं और 1 घंटे में केवल 4 को कॉल किया जाता है, तो आप पिछलेtestOnBorrowका उपयोग करके प्रत्येक अनुरोध पर सभी 4 कनेक्शनों की आसानी से जांच कर सकते थे। थोड़ा प्रदर्शन हिट के साथ दृष्टिकोण। लेकिन अगर इसके बजाय आप "हर घंटे जांचें" दृष्टिकोण करते हैं तो आप केवल 4 का उपयोग किए जाने पर सभी कनेक्शनों की जांच करने के लिए 30 अनुरोध करते हैं।
उच्च ट्रैफ़िक
- निष्क्रिय कनेक्शनों को जल्द खत्म करें - यह वह स्थिति है जिसमें हर कोई कह रहा है कि आपको प्रतीक्षा_समय समाप्त नहीं करना चाहिए और आपको प्रत्येक कनेक्शन का परीक्षण नहीं करना चाहिए। यह हर स्थिति के लिए आदर्श आदर्श नहीं है। जब आपके पास महत्वपूर्ण ट्रैफ़िक होगा, तो पूल में हर कनेक्शन का उपयोग किया जाएगा और आपकी वास्तविक समस्या उपलब्ध कनेक्शनों की संख्या में वृद्धि होगी, जबकि वास्तव में आपके
wait_timeकी लंबाई कम हो जाएगी। इसलिए आप डीबी पर निष्क्रिय कनेक्शन के अपलॉट को समाप्त नहीं करते हैं। यहां एक ऐसे व्यक्ति का उदाहरण दिया गया है जो इस बारे में बात कर रहा है कि कैसे एक व्यस्त साइट के लिए उसके पास एक दिन में 10,000 निष्क्रिय कनेक्शन हैं, इसलिए वह Wait_timeout व्यस्त साइट के लिए wait_timeout को कम करना
नमूना 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>
नमूना 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>
Tomcat Pool में बदलाव करने के लिए टॉमकैट पूल की संपत्तियों पर दस्तावेज़ीकरण
