የሞቱ ግንኙነቶች ሳይኖሩ ውሂብ ጎታዎችን ማንቃት

በMythex ላይ የታተሙ መተግበሪያዎችና ውሂብ ጎታዎቻቸው ማንም ስለማይጠቀምባቸው ይተኛሉ። መተግበሪያው ሲነቃ የመጀመሪያ ጥያቄውን ለ10 እስከ 12 ሰከንድ ሊይዝ ይችል ነበር፤ ምክንያቱም በሁሉም ነገር መተኛት ጊዜ የሞቱ የውሂብ ጎታ ግንኙነቶችን እንደገና ለመጠቀም ይሞክር ነበር። አሁን ለSpring Boot መተግበሪያዎች በእንቅልፍ ጊዜ ደህና የሆኑ የውሂብ ጎታ ቅንብሮችን እንሰጣለን፤ እና ለማንኛውም ማዕቀፍ መተግበሪያዎችን በተመሳሳይ መንገድ እንዲገነባ ወኪሉን እንነግረዋለን። በማስተናገጃ መድረኩ ላይ፣ ከነቃ በኋላ የመጀመሪያው ጥያቄ ከ12.7 ሰከንድ ወደ 2.3 ሰከንድ ወረደ።

መተግበሪያዎችና ውሂብ ጎታዎች ለምን ይተኛሉ

የታተመ Mythex መተግበሪያ ጥቂት ስራ ፈት ደቂቃዎች በኋላ የሚቆም ማሽን ላይ ይሰራል፤ ውሂብ ጎታው ደግሞ ለአምስት ስራ ፈት ደቂቃዎች ከተኛ በኋላ በሚቀጥለው ጥያቄ የሚነቃ serverless Postgres ነው። ጸጥ ያለ መተግበሪያ ርካሽ እንዲሆን የሚያደርገው ይህ ነው፤ ውሂብ ጎታው በእውነት በተጠቀመው ይከፈላል፤ የተኛ መተግበሪያ ለኮምፒዩተር ምንም አያወጣም። የክፍያውን ጎን በውሂብ ጎታዎችን በእውነት በሚጠቀሙት መጠን መክፈል ጽፈናል።

ያሳዘነው ሁለቱ ራሳቸውን ለብቻ ስለሚተኙ፣ ስለ ግንኙነት ምን እንደሆነ አይስማሙም።

ምልክቱ፦ ቀርፋፋ የመጀመሪያ ጉብኝት

አብዛኛዎቹ የሰርቨር መተግበሪያዎች connection pool ይይዛሉ፤ ጥቂት ክፍት የውሂብ ጎታ ግንኙነቶች ዝግጁ ሆነው እንዲቆዩ፤ ስለዚህ እያንዳንዱ ጥያቄ አዲስ ለመክፈት ወጪ አይከፍልም። ለሁልጊዜ የሚነቃ መተግበሪያ ትክክለኛ ዲዛይን ነው።

በእንቅልፍ ግን የሚሆነው፦

1. መተግበሪያው እየሮጠ ነው፤ በpool ውስጥ ጥቂት ስራ ፈት ግንኙነቶች አሉት።
2. ማንም አይጎበኝም። የመተግበሪያው ማሽን ይቆማል፤ pool-ው ሳይበላሽ ይቀዘቅዛል።
3. ውሂብ ጎታው ይተኛል፤ የእያንዳንዱን ግንኙነት የራሱን ጫፍ ይጥላል።
4. ጎብኚ ይመጣል። መተግበሪያው ልክ እንደነበረው ይነቃል፤ አሁንም የውሂብ ጎታው ከእንግዲህ የማያውቃቸውን ግንኙነቶች ይዞ።
5. pool-ው ከእነዚህ ግንኙነቶች አንዱን ይሰጣል። ሞቶ መሆኑን ማወቅ አለበት፤ መሞከርና መጠበቅ — ከዚያ በፊት ተስፋ ከመቁረጥ።

በSpring Boot መተግበሪያ፣ እነዚያን የሞቱ ግንኙነቶች ማረጋገጥ የመጀመሪያውን ጥያቄ ለ10 ሰከንድ ገደማ ያግድ ነበር፤ ከዚያም “Connection is not available” በሚል ይወድቅ ነበር። ለጎብኚው ድረ-ገጹ በቀላሉ ይሰቀል ነበር፤ ከዚያ ምናልባት ስህተት ያሳይ ነበር።

Spring መተግበሪያዎች ለምን በጣም ተጎድተው ነበር

Spring Boot ታዋቂ Java ማዕቀፍ ነው፤ በነባሪነት HikariCP የሚባል connection pool ይጠቀማል። Spring ያንን pool ከቅንብሮች ማዋቀር ይችላል፤ ስራ ፈት ግንኙነቶችን ስንት እንደሚይዝ ጨምሮ።

ግን Mythex እያንዳንዱን መተግበሪያ የውሂብ ጎታውን እንደ አንድ DATABASE_URL በpostgresql://user:pass@host/db ቅርጽ ይሰጠዋል። Spring ያንን ቅርጽ በቀጥታ ማንበብ አይችልም። ስለዚህ በMythex ላይ የተገነቡ Spring መተግበሪያዎች ያንን URL በመተንተን በኮድ ውስጥ የራሳቸውን pool ይፈጥሩ ነበር፤ በእጅ የተሰራ pool ደግሞ የSpring spring.datasource.* ቅንብሮችን ሁሉ ችላ ይላል። ትክክለኛዎቹን pool ቅንብሮች ማንም ቢያውቅም፣ የሚሰሩበት ቦታ አልነበረም።

መፍትሄ 1፦ Spring ሊጠቀምባቸው የሚችላቸው ቅንብሮች

ፕሮጀክት የውሂብ ጎታ ሲኖረው፣ አሁን Spring በቀጥታ የሚያነባቸውን የአካባቢ ተለዋዋጮች እንሰጠዋለን፦

• SPRING_DATASOURCE_URL፣ SPRING_DATASOURCE_USERNAME እና SPRING_DATASOURCE_PASSWORD፣ ከDATABASE_URL የተቀየሩ (URL ሌላ ካላለ SSL ይጠየቃል)።
• ከእንቅልፍ የሚተርፉ የpool ቅንብሮች፦

ምንም ስራ ፈት ግንኙነት ሳይያዝ፣ የነቃው መተግበሪያ አዲስ አንድ ግንኙነት ይከፍታል፤ የሞቱትን ከማለፍ ይልቅ።

እነዚህ ተለዋዋጮች ሲገኙ Spring pool-ውን ራሱ ያዋቅራል፤ ቅንብሮቹም ይተገበራሉ። ፕሮጀክቱ ራሱ ያዘጋጀው ማንኛውም ነገር ሁልጊዜ ያሸንፋል፤ እኛ የሚጎድለውን ብቻ እንሞላለን። Spring ያልሆኑ መተግበሪያዎች እነዚህን ተለዋዋጮች ችላ ይላሉ።

ሊያፈርስ የተቃረበ ዝርዝር

Spring ተለዋዋጮችን ወደ ቅንብሮቹ የሚያዛምደው ለመሳት ቀላል በሆነ ህግ ነው። minimum-idle የሚለው ቅንብር SPRING_DATASOURCE_HIKARI_MINIMUMIDLE ተብሎ መጻፍ አለበት፤ ሰረዞቹ ይጠፋሉ፤ ቃላቱ ይጣመራሉ። SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE ብሎ መጻፍ፣ ይበልጥ ተፈጥሯዊ የሚመስለው፣ ሌላ፣ የሌለ ቅንብር (minimum.idle) ላይ ይደርሳል፤ በጸጥታ ይታለፋል።

ይህ በእያንዳንዱ ግምገማ የሚያልፍ፣ ግን በምርት ውስጥ ምንም የማይሰራ ስህተት ዓይነት ነው። ስለዚህ ፈተና ሁለቱንም ይፈትሻል፦ እሴቶቹ መዋቀራቸውን፣ እና ምንም ተለዋዋጭ በሰረዝ-ለያይ ቅርጽ አለመሆኑን።

መፍትሄ 2፦ ሌሎች ቁልል ሁሉ

Spring ብቻ pool ያለው ማዕቀፍ አይደለም፤ እያንዳንዱን ላይብረሪ በእያንዳንዱ ቋንቋ ቀድሞ ማዋቀር አንችልም። ስለዚህ የMythex ወኪል — መተግበሪያችሁን የሚጽፍ AI — አሁን ለማንኛውም ቁልል ቋሚ መመሪያ ይዞ ነው፦ የታተሙ መተግበሪያዎችና ውሂብ ጎታዎቻቸው ሲሰነፉ ይተኛሉ፤ ስለዚህ ክፍት የተቀመጠ የውሂብ ጎታ ግንኙነት በሚቀጥለው ጥያቄ ሊሞት ይችላል። እንዲህ ማድረግ አለበት፦

• ምንም ስራ ፈት የውሂብ ጎታ ግንኙነት ክፍት አያስቀምጥ፣ ወይም ከመጠቀሙ በፊት እያንዳንዳቸውን ይፈትሽ፣
• በግንኙነት ስህተት ላይ አንድ ጊዜ ዳግም ይሞክር፣ እና
• በአካባቢው የቀረበውን የውሂብ ጎታ ቅንብር ይጠቀም፤ DATABASE_URLን በመተንተን የራሱን pool ከመገንባት ይልቅ።

የመጨረሻው ነጥብ ከመጀመሪያው ክፍል ጋር ይዘጋል፦ በቀረበው ቅንብር የተገነባ መተግበሪያ ለእንቅልፍ ደህና ውቅሩን በራስ-ሰር ያገኛል።

ውጤቱ

በምንጠቀምበት የታተሙ መተግበሪያዎች ማስተናገጃ መድረክ ላይ እንደሚለካው፣ ከነቃ በኋላ የመጀመሪያው ጥያቄ ከ12.7 ሰከንድ ወደ 2.3 ሰከንድ ወረደ።

ከዚህ የወሰድነው

• የሚተኛ እያንዳንዱ ንብርብር ምን እንደሚተርፍ መስማማት አለበት። የቀዘቀዘ መተግበሪያና የተኛ ውሂብ ጎታ እያንዳንዳቸው ምክንያታዊ ምርጫ አደረጉ። አብረው ግን መተግበሪያው ከእንግዲህ እውነት ያልሆነ ሁኔታ ይዞ ነቃ።
• ለሁልጊዜ-ለሚነቁ ሰርቨሮች የተዘጋጁ ነባሪዎች ዜሮ ለሚመዘኑ መተግበሪያዎች አይስማሙም። ግንኙነቶችን ሞቅ አድርጎ ማቆየት ጥሩ ሀሳብ ነው፤ ዙሪያው ሁሉ እስኪቀዘቅዝ ድረስ።
• ማዕቀፎች ውሂባቸውን በራሳቸው ቅርጽ ይስጧቸው። አንድ URL ለእኛ ቀላል ነበር፤ ግን እያንዳንዱ Spring መተግበሪያ የራሱን ውቅር የሚንቀው pool በእጅ እንዲያበጅ አስገድዶት ነበር።
• ቅንብሩ በማዕቀፉ በሚነበበው መንገድ መጻፉን ፈትሹ። ትክክለኛ እሴት በስህተት ስም ምንም አያደርግም፤ በጸጥታ።

የውሂብ ጎታዎች በMythex ላይ እንዴት እንደሚሰሩ አዲስ ከሆናችሁ፣ የውሂብ ጎታ ሰነዶቹን እና Postgres ምንድን ነው የሚለውን ማብራሪያችንን ተመልከቱ።